区域虚拟网络中的关联组还有性能优势吗？

Question

现在有一个跨越某个区域的新Azure Regional Virtual Networks feature，是否有使用关联组的性能优势？在链接的博客文章的FAQ部分中，有

  

在区域虚拟网络中运行的服务是否会导致性能下降？

     

虚拟网络只是一个逻辑边界，它并没有规定在哪里   VNet中的部署实际上是这样的。如果由于某种原因，你   需要服务在同一个Affinity小组中，你仍然可以做到这一点   在区域虚拟网络中。在部署期间，您必须这样做   指定托管服务应绑定到的Affinity组   至。唯一的限制是，亲和团体应该   与区域虚拟网络属于同一区域。

     

如果您未将托管服务绑定到Affinity组，并且   将服务直接部署到区域虚拟网络，您的   部署将放置在区域内的比例单位中   虚拟网络必然会。

我觉得建议不再使用亲和力组（基于这个和其他一些帖子，也许这是我的Azure和/或英语理解），但服务和数据是否位于同一位置那么在数据中心呢？

＆lt;编辑：当然在写完这篇文章之后我发现了一篇MSDN文章About Regional VNets and Affinity Groups for Virtual Network，其中说明了

  

以前，在创建虚拟网络（VNet）时，您需要   将VNet与一个关联组相关联，   与地区相关联。这个要求已经改变。现在VNets是   与管理门户中的区域（位置）直接关联。   这使您在创建VNet时更加自由。你还可以   在适当的时候将您的云服务与关联组关联，   但你不需要这样做。

     

Region 表示虚拟网络覆盖的位置。   您部署到虚拟网络的任何内容都将位于物理位置   在该区域。如果你想进一步指定你想要的   在相同的物理上彼此非常接近的资源   在region中，您可以为这些特定的组指定一个关联组   资源。这意味着不仅是那些资源   相同的物理位置，它们彼此非常接近   数据中心。

因此，我认为使用关联组时可以获得性能优势。

＆lt;编辑：Convective blog post Affinity Groups in Azure可以找到我能找到的关联群组的性能优势和用例的最明确来源。

  

亲和力组有两个目的：

     

  
1. 云服务和存储帐户的托管
  
2. 主机关系组VNET
        

其中第二项现已弃用。第一个仍然可能但是   没有像以前那样强调延迟优化   2012年Azure网络的升级。实际上是标准的方式   在Azure门户中部署VM不支持同时进行   在关联组和区域VNET中创建云服务。   这使那些试图满足现代最佳实践的人感到困惑   使用区域VNET进行部署和历史最佳实践   在关联组中创建云服务。

     

此时似乎没有理由部署云   服务到亲和团体。但是，与其他部署一样   人们可以选择对他们进行测试   具体的工作量。

Answer 1

从未明确证明使用关联性组会带来性能/延迟优势。关于这些利益（或缺乏利益）的报告差异很大，而且主要是轶事。

Answer 2

另见原始问题。我能找到的关联性小组的性能优势和用例的最明确来源可以在Convective blog post Affinity Groups in Azure找到。

  

亲和力组有两个目的：

     

  
1. 云服务和存储帐户的托管
  
2. 主机关系组VNET
        

其中第二项现已弃用。第一个仍然可能但是   没有像以前那样强调延迟优化   2012年Azure网络的升级。实际上是标准的方式   在Azure门户中部署VM不支持同时进行   在关联组和区域VNET中创建云服务。   这使那些试图满足现代最佳实践的人感到困惑   使用区域VNET进行部署和历史最佳实践   在关联组中创建云服务。

     

此时似乎没有理由部署云   服务到亲和团体。但是，与其他部署一样   人们可以选择对他们进行测试   具体的工作量。