为了节省成本，我想将我的 Web 角色移动到更小的 VM 大小。
我相应地更改了vmsize属性。在发布时，我收到以下错误：WebRoleServiceDefinition.csdef
对于指定的 VM 大小，请求的总资源太大
于是我又减小了ServiceDefinition.csdef. 然后我在发布时遇到错误：
本地资源的大小无法减少。受影响的本地资源是角色网站中的数据文件。
根据我在网上阅读的内容，我需要删除部署并重新发布它。但这将为我的云服务分配一个新 IP。我不能让这种事情发生。
我的问题还有其他解决方案吗？
补充一下sharptooth所说的......
在您的特定情况下，您应该部署到暂存槽，然后执行 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 地址不在白名单中。