出于节省成本的目的，我想将我的 Web 角色移至较小的虚拟机大小。
我相应地更改了 ServiceDefinition.csdef 中 WebRole 中的 vmsize 属性。发布时我收到以下错误:
Total requested resources are too large for the specified VM size
因此，我减少了 ServiceDefinition.csdef 中本地存储资源的大小。然后我在发布时遇到错误:
The size of local resources cannot be reduced. Affected local resource is DataFiles in role Website.
根据我在线阅读的内容，我需要删除部署并重新发布。但这将为我的云服务分配一个新的IP。我不能让这种事发生。
还有其他方法可以解决我的问题吗？
最佳答案
补充一下 Sharptooth 所说的内容......
根据您的具体情况，您应该部署到暂存槽，然后执行 VIP 交换。这将为您留下原始 IP 地址，并将新的托管服务(具有较小的 VM 大小)放入生产槽中。然后，您可以删除暂存槽(具有较大 VM 大小的旧服务)。
如果您无法进行 VIP 交换，则可以将更新的应用程序部署到新的托管服务，这将产生新的 IP 地址。然后，您可以将依赖于 IP 地址的任何内容(防火墙、白名单等)更新为新托管服务的 IP 地址，一旦一切正常，您可以将您的 cname/arecord 更新为新托管服务，然后删除旧托管服务服务。
但是，虽然您无法针对您的场景执行此操作，但只要有可能，就地升级都是比 VIP 交换更好的升级选项。通过 VIP 交换，您可能会暂时失去与依赖您的公共(public) IP 地址的外部资源的连接。问题是，如果连接到执行 IP 地址白名单的资源，出站流量可能会失败，这对于大多数服务来说实际上意味着它们已关闭。
通常，出站流量(即对 SQL Azure 的调用)从 DIP 到 VIP 进行 SNAT。如果被调用的资源(即 SQL Azure)执行 IP 白名单，那么这没有问题，因为流量将来自 VIP，这是一个已知的良好 IP 地址。在 VIP 交换期间，会有很短的一段时间，通常只有几秒钟，但在某些情况下可能会持续几分钟或更长时间，此时 SNAT 不断变化并且不会发生。这意味着来自 Azure VM 的流量似乎来自 DIP，这将导致连接被阻止，因为 DIP IP 地址不在白名单中。
关于azure - 努力将 Web 角色移动到更小的虚拟机大小，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/18331838/