我希望将我的网络角色移动到较小的虚拟机大小，以节省成本。
我相应更改了vmsize中WebRole中的ServiceDefinition.csdef属性。在发布时，我收到以下错误：
指定的VM大小所请求的资源总量太大
然后我减少了ServiceDefinition.csdef中本地存储资源的大小。然后我在发布时遇到错误：
无法减少本地资源的规模。受影响的本地资源 是角色网站中的DataFiles。
根据我在线阅读的内容，我需要删除部署并重新发布。但这会为我的云服务分配一个新的IP。我不可能发生这种情况。
我的问题还有其他解决办法吗？
答案 0 :(得分：2)
加上尖锐的说法......
在特定情况下，您应该部署到暂存插槽，然后执行VIP交换。这将为您提供原始IP地址，并将您的新托管服务（具有较小的VM大小）放入生产槽中。然后，您可以删除临时插槽（具有较大VM大小的旧服务）。
如果您无法进行VIP交换，则可以将更新的应用程序部署到新的托管服务，从而生成新的IP地址。然后，您可以将依赖于IP地址（防火墙，白名单等）的任何内容更新到新托管服务的IP地址，然后一切正常后，您可以将cname / arecord更新为新托管服务，然后删除旧托管服务服务。
但是，虽然您无法为您的方案执行此操作，但就地升级是一种比VIP交换更好的升级选项。通过VIP交换，您可能会暂时失去与依赖公共IP地址的外部资源的连接。问题是，如果连接到执行IP地址白名单的资源，出站流量可能会失败，这对于大多数服务来说实际上意味着它们已关闭。
通常，出站流量（即对SQL Azure的调用）是从DIP到VIP的SNAT。如果被调用的资源（即SQL Azure）执行IP白名单，那么这不是问题，因为流量将来自VIP，这是一个已知的良好IP地址。在VIP交换期间，有一段很短的时间，通常只有几秒钟，但在某些情况下可能需要几分钟或更长时间，其中SNAT不会发生并且不会发生。这意味着来自Azure VM的流量似乎来自DIP，这将导致连接被阻止，因为DIP IP地址不在白名单中。