Azure 角色终结点和网络流量规则

Anitesh Kumar

5.00/5 (6投票s)

2012 年 2 月 16 日

CPOL

7分钟阅读

59089

Azure 角色终结点和网络流量规则

引言

Azure 是 Microsoft 的云计算操作系统，它支持在云中托管和运行应用程序。云本质上就是 Microsoft 的数据中心。应用程序以角色的形式托管在云中。角色主要有两种：Web 角色和工作角色。这两种角色都有不同的目的。

在云中托管时，我们要在 IIS 上托管的任何应用程序的一部分创建为 Web 角色。Web 角色充当应用程序用户和工作角色之间的桥梁。

顾名思义，工作角色会完成 Web 角色分配的任务。它在云中持续运行，异步处理任务。

在此基本知识的基础上，我们开始讨论该主题。每个服务都向外部世界或该服务的客户端公开一组终结点。服务的使用者通过这些终结点了解服务的元数据或功能。在云中，每个托管的角色（Web 或工作）都是一个服务，可以从本地应用程序或浏览器使用，并为此定义终结点。

在本文中，我们将重点关注终结点和设置网络规则，而不是其他配置架构成员。

角色终结点

Azure 角色终结点在角色的服务定义文件（.csdef）的“Endpoints”架构节点下定义。

<Endpoints>
      <. . .  />
</Endpoints>

我们可以在相应的项目文件夹中找到定义文件。以下是一个名为“DicomConvert”的应用程序的快照，以及在文件夹和解决方案资源管理器中找到定义文件所在的位置。

图 1

每个终结点定义都有三个基本属性：“Name”、“Protocol”和“Port”。以下是一个输入 `endpoint` 定义的示例：

<Endpoints>
      <InputEndpoint name="Endpoint1" protocol="http" port="80" />
</Endpoints>

可以使用 HTTP 协议在端口 80 访问此 `endpoint`。

注意：如果我们在定义文件中进行任何更改，都必须重新部署（“发布”或“打包并上传”）应用程序到云中。在 Azure 管理门户中，无法实时更改定义（.csdef）文件，但可以通过门户更改配置（.cscfg）文件，即使应用程序已部署，也可以实时看到更改。

我们可以使用 Visual Studio 文本编辑器打开定义文件来配置终结点，也可以使用 Visual Studio 提供的用户界面来完成。

双击解决方案资源管理器中创建的角色，即可获得配置 UI。我们可以选择添加、删除终结点。此外，在左侧窗格中，还可以找到其他配置选项。

图 2

完成后，保存设置（“Ctrl+S”），它将自动反映在定义文件中。

只有当我们显式指定服务定义中的终结点时，Windows Azure 才能访问您的角色。通过定义终结点，我们指示 Fabric Controller 使用负载均衡器将 Web 流量路由到特定角色。最初，Windows Azure 不允许直接连接工作角色，即，到工作角色的每个请求都必须经过负载均衡器；包括来自同一虚拟网络中同一应用程序的角色实例的请求。这种设计会导致响应延迟。当 Azure 平台通过引入两种类型的终结点（一种用于处理防火墙外部的外部请求，另一种用于处理防火墙内部应用程序角色实例之间的请求）投入生产时，该限制被取消了。

请参考以下快照，其中包含完整的定义文件和终结点定义。请注意先前快照中的终结点设置。

图 3

终结点类型

Azure 有两种终结点：输入和内部。

输入终结点 - 输入终结点是可通过 Internet 访问的（面向外部）终结点。最初，这是 Azure 唯一可用的终结点定义。它支持 HTTP 和 HTTPS 协议。这种 `endpoint` 负责处理来自负载均衡器的 Internet 流量。以下是可用的配置属性：

Attribute	描述
`名称`	必需。外部终结点的唯一名称。
`协议`	必需。外部终结点传输协议。对于 Web 角色，可能的值为 HTTP、HTTPS 或 TCP。请注意，只有当输入终结点定义为 `Endpoints` 元素的子元素时，才支持 TCP。
`port`	必需。外部终结点的端口。您可以指定任意端口号，但服务中每个角色指定的端口号必须是唯一的。 HTTPS 终结点所需的证书。证书的名称由证书元素定义。
`localPort`	可选。指定终结点上用于内部连接的端口。`localPort` 属性将终结点上的外部端口映射到角色上的内部端口。这在角色必须通过与外部公开的端口不同的端口与内部组件通信的场景中很有用。如果未指定，`localPort` 的值与端口属性中设置的值相同。将 `localPort` 设置为“*”以允许 Windows Azure 平台分配一个未分配的端口，该端口可以使用运行时 API 进行发现。注意：`localPort` 属性仅在 Windows Azure SDK 版本 1.3 或更高版本中可用。
`ignoreRoleInstanceStatus`	可选。当此属性的值设置为 `true` 时，将忽略服务状态，负载均衡器不会删除终结点。默认值为 `false`。将此值设置为 true 有助于调试繁忙的服务实例。注意：即使角色状态不是“就绪”，终结点仍然可以接收流量。

内部终结点 - 内部终结点在 Azure 节点内（虚拟网络内部）可供同一应用程序的角色实例访问。一个应用程序的角色无法访问其他应用程序角色的内部终结点。这种通信直接发生，无需负载均衡器参与。因此，仅由 Web 角色使用的 Worker 角色，并且这两个角色都托管在云中，则无需定义输入终结点。在这种情况下，Worker 角色可以拥有一组公开给托管 Web 角色的内部终结点，而 Web 角色又可以拥有一组公开给 Internet 的输入终结点。它支持 HTTP、HTTPS 和 TCP 协议。

<Endpoints>
      <InputEndpoint name="HttpIn" protocol="http" port="80" />
<InternalEndpoint name="HttpInternal" protocol="http" port="8000"></InternalEndpoint>
</Endpoints>

上面的配置片段是一个 Web 角色，它有一个用于出站通信的输入终结点和一个用于跨角色通信的内部终结点。因此，现在可以理解，在 Azure 中创建终结点是基于托管应用程序的架构进行决策的。

设置网络流量规则

使用内部终结点，我们可以设置角色实例之间的通信规则。在违规情况下，Azure 会引发异常。这些规则还可以设计为实现安全功能，以防我们不希望其他 Web 角色或工作角色访问某个角色。

在众多可能的情况下，我们将选取几个场景来设置网络流量规则。假设我们有一个 Web 角色“WB1”和一组工作角色“WR1”、“WR2”。根据应用程序的要求，我们需要设置如下网络规则：

WB1 WR1 WR2

Web 角色实例只能访问 `WR1`，而 `WR1` 只能访问 `WR2`。`WR2` 不能直接从 Web 角色访问。
`WB1` 可以访问两个工作角色实例。

当我们配置一个包含一个 Web 角色和两个工作角色的应用程序时，会创建以下配置定义文件：

<ServiceDefinition name="MyService" 
xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition">
  <WebRole name="WebRole1" vmsize="Small"> 
    <Sites>
      <Site name="WB1">
        <Bindings>
          <Binding name="HttpIn" endpointName="HttpIn" />
        </Bindings>
      </Site>
    </Sites>
    <Endpoints>
      <InputEndpoint name="HttpIn" protocol="http" port="80" />
      <InternalEndpoint name="Internal1" protocol="tcp" port=”5000” />
    </Endpoints>
  </WebRole>
  <WorkerRole name="WR1">
    <Endpoints>
      <InternalEndpoint name="Internal2" protocol="tcp" port=”5001” />
    </Endpoints>
  </WorkerRole> 
  <WorkerRole name="WR2">
    <Endpoints>
      <InternalEndpoint name="Internal2" protocol="tcp" port=”5001” />
    </Endpoints>
      </Endpoints>
  </WorkerRole>
</ServiceDefinition>

要定义网络流量规则，请在 Visual Studio 文本编辑器中打开“.csdef”文件。这里所有内部终结点都配置为使用 TCP 协议，也可以是 HTTP。请注意，网络流量规则节点应该是服务定义文件中定义的最后一个节点。否则，当应用程序托管在云中时，有时会引发异常。

规则是基于流量源和目标角色设置的，并且几乎是不言自明的。

场景 1

<NetworkTrafficRules>
  <OnlyAllowTrafficTo>

    <Destinations>
      <RoleEndpoint endpointName="Internal2" roleName="WR1"/>
    </Destinations>

    <WhenSource matches="AnyRule">
      <FromRole roleName="WB1"/>
    </WhenSource>

  </OnlyAllowTrafficTo>
</NetworkTrafficRules>

<NetworkTrafficRules>
  <OnlyAllowTrafficTo>
    
    <Destinations>
      <RoleEndpoint endpointName="Internal3" roleName="WR2"/>
    </Destinations>

    <WhenSource matches="AnyRule">
      <FromRole roleName="WR1"/>
    </WhenSource>

  </OnlyAllowTrafficTo>
</NetworkTrafficRules>

场景 2

<NetworkTrafficRules>
  <OnlyAllowTrafficTo>

    <Destinations>
      <RoleEndpoint endpointName="Internal2" roleName="WR1"/>
      <RoleEndpoint endpointName="Internal3" roleName="WR2"/>
    </Destinations>

    <WhenSource matches="AnyRule">
      <FromRole roleName="WB1"/>
    </WhenSource>

  </OnlyAllowTrafficTo>
</NetworkTrafficRules>

同样，我们可以考虑任意通信组合并为其设置相应的规则。

允许的终结点数量限制

对于 Azure 中的任何托管服务，允许的角色数量已从 5 个增加到 25 个（Web 角色和工作角色）。一个托管服务总共可以拥有 25 个输入终结点和 25 个内部终结点。终结点可以在角色之间任意分配。因此，每个角色允许的内部或输入终结点数量为 25。我尝试为工作角色创建 26 个内部终结点并尝试将其发布到 Azure。以下是部署失败通知的快照，其中红色圈出的错误消息明确提到了限制。

图：4

结论

Azure 终结点和相关的网络流量规则使角色只能访问其他相关的角色或服务。这有助于实现安全且版本化的访问（例如，同一工作角色的两个版本）。这些规则对于正在不断改进的大型应用程序可能非常有用。

Azure 角色终结点和网络流量规则

引言

角色终结点

终结点类型

设置网络流量规则

场景 1

场景 2

允许的终结点数量限制

结论

参考文献