努力将 Web 角色移动到更小的 vmsize

Question

为了节省成本，我想将我的 Web 角色移动到更小的 VM 大小。

我相应地更改了ServiceDefinition.csdef 中WebRole 中的vmsize 属性。在发布时，我收到以下错误：

请求的总资源对于指定的 VM 大小来说太大了

于是我随后减小了ServiceDefinition.csdef 中本地存储资源的大小。然后我在发布时遇到错误：

无法减少本地资源的大小。受影响的本地资源 是角色网站中的数据文件。

根据我在网上阅读的内容，我需要删除部署并重新发布。但这将为我的云服务分配一个新 IP。我不能让这种事情发生。

我的问题还有其他解决方案吗？

Answer 1

补充一下尖牙所说的......

在您的特定情况下，您应该部署到暂存槽，然后执行 VIP 交换。这将为您保留原始 IP 地址，并将您的新托管服务（具有较小的 VM 大小）放入生产槽。然后，您可以删除您的暂存槽（您的旧服务具有较大的 VM 大小）。

如果您无法进行 VIP 交换，那么您可以将更新后的应用程序部署到新的托管服务，这将产生一个新的 IP 地址。然后，您可以将依赖于 IP 地址（防火墙、白名单等）的任何内容更新为新托管服务的 IP 地址，然后一旦一切正常，您可以将 cname/arecord 更新为新托管服务，然后删除旧托管服务。

但是，尽管您无法针对您的场景执行此操作，但只要有可能，就地升级是比 VIP 交换更好的升级选项。通过 VIP 交换，您可能会暂时失去与依赖公共 IP 地址的外部资源的连接。问题是，如果连接到执行 IP 地址白名单的资源，出站流量可能会失败，这对于大多数服务实际上意味着它们已关闭。

通常，出站流量（即对 SQL Azure 的调用）是从 DIP 到 VIP 的 SNAT。如果被调用的资源（即 SQL Azure）执行 IP 白名单，那么这没有问题，因为流量将来自已知良好 IP 地址的 VIP。在 VIP 交换期间，有一段很短的时间，通常只有几秒钟，但在某些情况下可能是几分钟或更长时间，此时 SNAT 不断变化并且不会发生。这意味着来自 Azure VM 的流量似乎来自 DIP，这将导致连接被阻止，因为 DIP IP 地址不在白名单中。