VIP交换和持久性 - 当VIP真正得到回收利用时？ [英] VIP Swaps and Persistence - when exactly do VIPs get recycled?
问题描述
作为从上述的延续 - 我非常接近回到由于我遇到的问题的记录Azure中的CNAME
As a continuation from the above - I'm very close to reverting back to A records due to issues I'm having with CNAMEs in Azure.
从 Azure文档，这说明：
但是，由于IP地址的生命周期是关联
与部署，重要的是不要删除您的部署如果
您需要IP地址来持久化。方便地，在Windows Azure中使用
两个升级机制时，给予部署槽（生产或分期）的
的IP地址将保持不变：VIP交换和就地
升级。
Note, however, because the lifetime of the IP address is associated with a deployment, it is important not to delete your deployment if you need the IP address to persist. Conveniently, the IP address of a given deployment slot (production or staging) is persisted when using the two upgrade mechanisms in Windows Azure: VIP swaps and in-place upgrades.
我有 myapp.cloudapp.net ，目前指向$ $ c的VIP $ C> 1.1.1.1 。如果我想将我的应用程序的一个版本部署到Staging，我将使用我的应用程序来旋转Staging插槽，进行一些测试，然后通过VIP交换进行无缝升级。该应用程序现在将使用 2.2.2.2 - 虽然此时再次进行DNS查找，但是 myapp.cloudapp.net的A记录仍然会指向 1.1.1.1 ，因为VIP交换对DNS没有影响，对吗？
I have myapp.cloudapp.net, currently pointing to a VIP of 1.1.1.1. If I want to deploy a version of my application to Staging, I'll spin the Staging slot up with my application, do some testing, and then do a seamless upgrade via VIP swap. The application will now be using 2.2.2.2 - though if I do a DNS lookup again at this point, the A record for myapp.cloudapp.net will still point to 1.1.1.1, since VIP swaps have no impact on DNS, right?
如果是这样，那么当我杀死我的分期部署以节省成本时会发生什么？将为我的服务保留 1.1.1.1 和 2.2.2.2 我希望如此，因为这意味着我可以让我的A记录点到1.1.1.1所有的时间，依靠它通过分段部署，而不用担心CNAME麻烦。但这意味着此答案不正确
If so, then what happens when I kill my staging deployment to save cost? Will both 1.1.1.1 and 2.2.2.2 be reserved for my service? I hope so, because that means I can have my A record point to 1.1.1.1 all the time, depend on it through staging deployments, and not worry about CNAME hassles. But that means that this answer is incorrect.
如果没有，那意味着VIP交换对DNS记录有影响，对吧？否则，我可以这样做：
If not, then this means that VIP swaps do have effects on DNS records, right? Otherwise, I would be able to do this:
- 1.1.1.1> 2.2.2.2，分段，1.1.1.1被回收
-
- 再次启动升级，2.2.2.2> 3.3.3.3，但是，对于myapp.cloudapp.net，DNS A记录仍然指向1.1.1.1。
最后一点没有任何意义，所以DNS记录更新，或3.3 .3.3永远不会进入图片，1.1.1.1和2.2.2.2总是在一起，只要我的云服务不被删除。
That last bit wouldn't make any sense, so either DNS records do get updated, or 3.3.3.3 never enters the picture, and 1.1.1.1 and 2.2.2.2 are always together, as long as my cloud service doesn't get deleted.
我很困惑这个问题 - 任何指导都会很棒。
I'm very confused with this matter - any guidance would be great.
更新 - 我只是使用以下内容进行了测试：
UPDATE - I just tested this with the following:
CHECK DNS - get 1.1.1.1
READ PROD - get 1.1.1.1
DEPLOY STAGING
READ STAGING - get 2.2.2.2
VIP SWAP
READ PROD - get 1.1.1.1
READ STAGING - get 2.2.2.2
CHECK DNS - get 1.1.1.1
KILL STAGING DEPLOYMENT
READ PROD - get 1.1.1.1
所以看来，可以使用 A记录 - 即使在分段/制作之间切换，PROD VIP仍然保持相同，但部署被交换。放弃分期和重新部署分段获得新的次要VIP，但主要VIP确实保持不变。我会等到有一个比我更可靠的人可以在这里发短信，作为答案。
So it appears that A records CAN be used - even when switching between staging / production, the PROD VIP stays the same, but the deployments get swapped. Dropping staging and re-deploying staging gets a new secondary VIP, but the primary VIP does stay constant. I'll wait until someone more reliable than me can chime in here before posting this as an answer.
推荐答案
VIP交换不会改变你的公共IP这就是说，如果您的应用程序部署在具有1.1.1.1的beta插槽和beta部署在2.2.2.2的分段时隙中，即使在VIP交换之后，您的公共IP仍将是1.1.1.1。这是因为VIP只是负载平衡配置的变化。您可以从IP为2.2.2.2的分段插槽（原始插槽）安全地删除原始应用程序。
VIP swap will not change your public IP. That's saying, if you have your application deployed in prod slot with 1.1.1.1 and beta deployed in staging slot with 2.2.2.2, your public IP will still be 1.1.1.1 even after VIP swapped. This is because VIP is just a load balance configuration changing. You can safely delete your original application from the staging slot (originally prod slot) which the IP was 2.2.2.2.
希望这有助于，
这篇关于VIP交换和持久性 - 当VIP真正得到回收利用时？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
