我在 Azure 中设置了一个现有的虚拟网络 (VN)。上面有一个 VM。VN 是一个使用 Azure DNS 的基本网络,是使用默认设置创建的(如果我没记错的话)。
我能够配置云服务并通过 Cloud.cscfg 文件将其添加到 VN,例如通过添加:
<NetworkConfiguration>
<VirtualNetworkSite name="Group Group-n xxxxxx" />
<AddressAssignments>
<InstanceAddress roleName="yyyyy.API">
<Subnets>
<Subnet name="Subnet-42" />
</Subnets>
</InstanceAddress>
<InstanceAddress roleName="yyyyy.WorkerRole">
<Subnets>
<Subnet name="Subnet-42" />
</Subnets>
</InstanceAddress>
</AddressAssignments>
</NetworkConfiguration>
为保护无辜者,名字已被更改。请注意,未提供区域名称和亲和团体 - 我不确定这是否相关。
我对我们在部署后上传的 cscfg 文件做了类似的调整,并且能够更新配置而不会引起问题。
该设置有效(对于某些有效定义),并且当使用 IP 号码寻址时,我们云服务中的 Web 角色和工作角色能够通过 TCP 向同一 VN 上的 VM 发送消息(使用 VM 的 FQDN 时有时也能正常工作,但这是另一个问题,可能会导致另一个问题)。
该云服务是一个开发堆栈。为了测试我们的部署过程是否有效,我重新部署了没有网络配置的云服务,并确认角色不再列在 VN 的子网上。
然后,我尝试使用相同的配置将同一区域中的不同云服务添加到虚拟网络。
部署失败,并显示消息“部署不能使用属于区域 Azure 的 VNNAME”。
描述了一个类似的问题,但并没有得到太多有用的建议。
因此,问题是,在向现有虚拟网络添加和删除 Azure 云服务时应采取哪些正确的步骤,以及是否有人知道与虚拟网络配置相关的 Azure 问题可能会导致上述行为?
谢谢
PS 我记起了一些可能相关的信息。当原始云服务添加到 VN 时,它处于云服务的暂存槽中,而该云服务尚未部署到生产槽中。在第二种情况下,该服务被部署到具有已占用的生产槽且正在运行 Web 和工作角色的服务的暂存槽中。
答案1
这个问题太老了,我忘记了很多细节。尽管如此,我们办公室里有人调查过这个问题。他们没有遇到同样的问题。我想这是因为 Azure 坏了,现在他们已经修复了,但这可能是错误的。
这可能不是我的特定问题的正确解决方案,但它至少对我们来说是一个合适的解决方法,我想我会分享它。
在使用预定义的虚拟网络并尝试在 Azure 门户上创建新实体(例如虚拟机)时,我的同事注意到,除了被要求为新实体提供区域外,他还可以提供一个虚拟网络名称。他这样做了。他没有遇到我注意到的任何问题。