Экспорт (0) Печать
Развернуть все

Включение обмена данными для экземпляров роли в Azure

Обновлено: Август 2014 г.

Экземпляры ролей, выполняемые в облачной службе Azure, взаимодействуют через внутренние и внешние соединения, которые зависят от необходимого типа связи. Внешнее соединение, используемое для связи с внешними клиентами, называется входной конечной точкой. Внутреннее соединение, используемое для связи с другими экземплярами ролей в облачной службе, называется внутренней конечной точкой. Конечная точка ввода может подключаться с использованием протоколов HTTP, HTTPS или TCP. Внутренняя конечная точка может подключаться с использованием протоколов HTTP или TCP. Конечные точки связываются с IP-адресами и портами, при этом конечная точка ввода связывается с портом, который определяется разработчиком, а внутренние конечные точки — с портами, которые динамически назначаются Azure. При задании конечных точек в определении службы можно статически назначить внутренний порт на тот же используемый внешний порт, указав атрибут localPort.

Облачная служба, создаваемая в Azure, может быть развернута в одной из двух сред: рабочей среде или промежуточной среде. Служба, развернутая в одной из этой сред, получает DNS-имя и IP-адрес. DNS-имя, связанное с рабочей средой, назначается во время выполнения и фиксируется на все время существования службы. DNS-имя для промежуточной среды формируется динамически при каждом развертывании службы. Каждый раз при развертывании службы в среду DNS-имя службы получает IP-адрес из пула доступных адресов. IP-адрес сохраняется до тех пор, пока не будет удалено развертывание службы. Обновление приложения, изменение конфигурации, смена рабочей среды на промежуточную и обратно не приведут к изменению IP-адреса.

noteПримечание
Диапазон IP-адресов, которые используются в Azure, может изменяться. При настройке политики брандмауэра или других мерах безопасности не используйте фильтрацию на основе IP-адресов. Необходимо использовать другие механизмы обеспечения безопасности, которые не зависят от диапазонов IP-адресов.

Конечные точки ввода используются для взаимодействия с экземплярами ролей вне пределов Azure. Внутренние конечные точки для внутренней связи между ролями. Каждая конечная точка роли должна прослушивать уникальный порт. Порт, который определен для входной конечной точки, используется подсистемой балансировки нагрузки Azure для предоставления доступа к облачной службе через Интернет. Если атрибут localPort в определении службы не указан, то внутренние порты назначает контроллер фабрики Azure. Если внутренний номер порта назначил контроллер фабрики Azure, его можно узнать используя следующий пример кода.

int port = RoleEnvironment.CurrentRoleInstance.InstanceEndpoints["EndPointName"].IPEndpoint.Port;

В облачной службе может быть развернуто максимум 25 экземпляров веб-ролей или рабочих ролей, среди которых может быть распределено самое большее 25 входных конечных точек. Например, в облачной службе может быть один экземпляр веб-роли или рабочей роли, для которого будет определено 25 входных конечных точек, или же в ней может быть 25 экземпляров веб-ролей или рабочих ролей, каждый из которых будет использовать одну конечную точку. В облачной службе может быть развернуто не более 50 виртуальных машин, которым можно задать не более 150 конечных точек.

Можно определить входные конечные точки для ролей, добавив элемент Endpoints, содержащий элементы InputEndpoint, к элементам WebRole и WorkerRole в файле определения службы. Элемент InputEndpoint определяет имя, протокол и порт для конечной точки. Дополнительные сведения об этих элементах см. в разделе Схема определения службы Windows Azure (файл CSDEF). Дополнительные сведения о настройке связи в развертываниях виртуальных машин см. в разделе Настройка конечных точек в виртуальной машине.

  1. Откройте файл ServiceDefinition.csdef для своей службы в текстовом редакторе.

  2. Добавьте элемент Endpoints, содержащий элемент InputEndpoint, к элементу роли. В следующем примере показано, как добавить конечную точку ввода HTTP для веб-роли, которая прослушивает порт 80 и также определяет внутренний порт 80.

    
    <ServiceDefinition name="MyService" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition">
      <WebRole name="WebRole1">
        <Endpoints>
          <InputEndpoint name="HttpIn" protocol="http" port="80" localPort="80" />
        </Endpoints>
      </WebRole>
    </ServiceDefinition>
    
    
    noteПримечание
    Атрибут localPort является необязательным. Если этот атрибут не определен, фабрика назначает внутренний номер порта во время выполнения.

    В следующем примере показано добавление конечной точки ввода TCP для рабочей роли, прослушивающей порт 10000.

     
    <ServiceDefinition name="MyService" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition">
      <WorkerRole name="WorkerRole1">    
        <Endpoints>
          <InputEndpoint name="Endpoint1" protocol="tcp" port="10000" />
        </Endpoints>
      </WorkerRole>
    </ServiceDefinition>
    
  3. Задайте имя конечной точки согласно имени, которое необходимо использовать.

  4. Установите протокол согласно типу обмена данными, который необходимо использовать. Возможные варианты — HTTP, HTTPS и TCP.

  5. Укажите номер порта, который следует использовать для обмена данными с ролью.

  6. Сохраните файл.

Можно определить не более 25 внутренних конечных точек для ролей, добавив элемент Endpoints, содержащий элементы InternalEndpoints, к элементам WebRole и WorkerRole в файле определения службы. Для одного экземпляра роли можно задать не более пяти внутренних конечных точек. Дополнительные сведения об этих элементах см. в разделе Схема определения службы Windows Azure (файл CSDEF).

  1. Откройте файл ServiceDefinition.csdef для своей службы в текстовом редакторе.

  2. Для веб-роли или рабочей роли добавьте элемент Endpoints, содержащий элементы InternalEndpoint, для элемента WebRole или WorkerRole. В следующем примере показано, как добавить внутреннюю конечную точку HTTP для веб-роли с указанным номером порта.

    
    <ServiceDefinition name="MyService" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition">
      <WebRole name="WebRole1">
        <Endpoints>
          <InternalEndpoint name="InternalHttpIn" protocol="http" port="1000"/>
        </Endpoints>
      </WebRole>
    </ServiceDefinition>
    
    noteПримечание
    Порт является необязательным. Можно предоставить назначение порта Azure.

    В следующем примере показано добавление внутренней конечной точки TCP для рабочей роли.

    
    <ServiceDefinition name="MyService" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition">
      <WorkerRole name="WorkerRole1">
        <Endpoints>
          <InternalEndpoint name="Endpoint1" protocol="tcp" />
        </Endpoints>
      </WorkerRole>
    </ServiceDefinition>
    

    При необходимости можно также определить диапазон номеров порта.

    
    <InternalEndpoint name="InternalPoint1" protocol="tcp">
      <FixedPortRange min="1000" max="2000" />
    </InternalEndpoint>
    
  3. Задайте имя конечной точки согласно имени, которое необходимо использовать.

  4. Установите протокол согласно типу обмена данными, который необходимо использовать.

  5. Сохраните файл.

Прямые порты (входные конечные точки) для роли можно определить путем добавления элемента Endpoints, содержащего элементы InstanceInputEndpoints, в элементы WebRole или WorkerRole в файле определения службы. Дополнительные сведения об этих элементах см. в разделе Схема определения службы Windows Azure (файл CSDEF). Конечная точка прямого порта используется для взаимодействия с экземплярами роли с балансировкой нагрузки.

  1. Откройте файл ServiceDefinition.csdef для своей службы в текстовом редакторе.

  2. Для веб-роли или рабочей роли добавьте элемент Endpoints, содержащий элементы InstanceInputEndpoint, в элемент роли. В следующем примере показано, как добавить веб-роли конечную точку в виде прямого TCP-порта с указанным локальным номером порта и диапазоном общедоступных прямых портов:

    
    <ServiceDefinition name="MyService" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition">
      <WebRole name="WebRole1">
        <Endpoints>
          <InputEndpoint name=”Endpoint1” protocol=”http” port=”10101” localPort=”80” />
          <InstanceInputEndpoint name="Endpoint2" localPort="1000" protocol="tcp">
            <AllocatePublicPortFrom>
              <FixedPortRange min="10016" max="10020"/>
            </AllocatePublicPortFrom>
          </InstanceInputEndpoint>
        </Endpoints>
      </WebRole>
    </ServiceDefinition>
    
    ImportantВажно!
    В XML-коде из предыдущего примера элемент InputEndpoint определен до элемента InstanceInputEndpoint. Если его не указать, будет сформирована ошибка конфигурации схемы, при этом развернуть приложение не удастся. Все службы веб-роли должны иметь конечную точку HTTP/HTTPS, определенную как первую конечную точку. Если таковой нет, фабрика Azure создаст ее автоматически и спровоцирует ошибку из-за того, что InstanceInputEndpoint будет первой конечной точкой в определении службы. Элемент пользовательского интерфейса Visual Studio, который позволяет добавлять конечные точки без изменения XML-файла определения службы, не требует выполнения этого условия.

    В следующем примере показано добавление внутренней конечной точки TCP рабочей роли с общим доступом к прямому порту.

    
    <ServiceDefinition name="MyService" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition">
      <WorkerRole name="WorkerRole1">
        <Endpoints>
          <InstanceInputEndpoint name="InstanceInputEndpoint1" localPort="1000" protocol="tcp">
            <AllocatePublicPortFrom>
              <FixedPortRange min="10016" max="10020"/>
            </AllocatePublicPortFrom>
          </InstanceInputEndpoint>
        </Endpoints>
      </WorkerRole>
    </ServiceDefinition>
    
  3. Задайте имя конечной точки согласно имени, которое необходимо использовать.

  4. Установите протокол согласно типу обмена данными, который необходимо использовать.

  5. Сохраните файл.

В приведенном далее образце кода показано, как создать сокет и как в рабочей роли прослушивать запросы к конечным точкам прямого порта.

WarningПредупреждение
Этот код будет работать только в развернутой службе. При запуске в эмуляторе вычислений Azure элементы конфигурации службы, которые создают конечные точки прямого порта (элементы InstanceInputEndpoint), не учитываются.


using System;
using System.Diagnostics;
using System.Linq;
using System.Net;
using System.Net.Sockets;
using System.Threading;
using Microsoft.WindowsAzure;
using Microsoft.WindowsAzure.Diagnostics;
using Microsoft.WindowsAzure.ServiceRuntime;
using Microsoft.WindowsAzure.StorageClient;
 
namespace WorkerRole1
{
  public class WorkerRole : RoleEntryPoint
  {
    public override void Run()
    {
      try
      {
        // Initialize method-wide variables
        var epName = "Endpoint1";
        var roleInstance = RoleEnvironment.CurrentRoleInstance;
        
        // Identify direct communication port
        var myPublicEp = roleInstance.InstanceEndpoints[epName].PublicIPEndpoint;
        Trace.TraceInformation("IP:{0}, Port:{1}", myPublicEp.Address, myPublicEp.Port);
 
        // Identify public endpoint
        var myInternalEp = roleInstance.InstanceEndpoints[epName].IPEndpoint;
                
        // Create socket listener
        var listener = new Socket(
          myInternalEp.AddressFamily, SocketType.Stream, ProtocolType.Tcp);
                
        // Bind socket listener to internal endpoint and listen
        listener.Bind(myInternalEp);
        listener.Listen(10);
        Trace.TraceInformation("Listening on IP:{0},Port: {1}",
          myInternalEp.Address, myInternalEp.Port);
 
        while (true)
        {
          // Block the thread and wait for a client request
          Socket handler = listener.Accept();
          Trace.TraceInformation("Client request received.");
 
          // Define body of socket handler
          var handlerThread = new Thread(
            new ParameterizedThreadStart(h =>
            {
              var socket = h as Socket;
              Trace.TraceInformation("Local:{0} Remote{1}",
                socket.LocalEndPoint, socket.RemoteEndPoint);
 
              // Shut down and close socket
              socket.Shutdown(SocketShutdown.Both);
              socket.Close();
            }
          ));
 
          // Start socket handler on new thread
          handlerThread.Start(handler);
        }
      }
      catch (Exception e)
      {
        Trace.TraceError("Caught exception in run. Details: {0}", e);
      }
    }
 
    public override bool OnStart()
    {
      // Set the maximum number of concurrent connections 
      ServicePointManager.DefaultConnectionLimit = 12;
 
      // For information on handling configuration changes
      // see the MSDN topic at http://go.microsoft.com/fwlink/?LinkId=166357.
      return base.OnStart();
    }
  }
}

После задания внутренних конечных точек можно добавить правила сетевого трафика для управления взаимодействием между экземплярами ролей. На следующей диаграмме показаны некоторые общие сценарии по управлению взаимодействием ролей.

Сценарии правил сетевого трафика
  • Сценарий 1 — разрешен только сетевой трафик от WebRole1 к WorkerRole1.

  • Сценарий 2 — разрешен только сетевой трафик от WebRole1 к WorkerRole1 и WorkerRole2.

  • Сценарий 3 — разрешен только сетевой трафик от WebRole1 к WorkerRole1 и от WorkerRole1 к WorkerRole2.

  • Сценарий 4 — разрешен только сетевой трафик от WebRole1 к WorkerRole1, от WebRole1 к WorkerRole2 и от WorkerRole1 к WorkerRole2.

В следующем примере кода показаны определения ролей из предыдущей диаграммы. Каждое определение роли содержит как минимум одну внутреннюю конечную точку.


<ServiceDefinition name="MyService" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition">
  <WebRole name="WebRole1" vmsize="Medium"> 
    <Sites>
      <Site name="Web">
        <Bindings>
          <Binding name="HttpIn" endpointName="HttpIn" />
        </Bindings>
      </Site>
    </Sites>
    <Endpoints>
      <InputEndpoint name="HttpIn" protocol="http" port="80" />
      <InternalEndpoint name="InternalTCP1" protocol="tcp" />
    </Endpoints>
  </WebRole>
  <WorkerRole name="WorkerRole1">
    <Endpoints>
      <InternalEndpoint name="InternalTCP2" protocol="tcp" />
    </Endpoints>
  </WorkerRole> 
  <WorkerRole name="WorkerRole2">
    <Endpoints>
      <InternalEndpoint name="InternalTCP3" protocol="tcp" />
      <InternalEndpoint name="InternalTCP4" protocol="tcp" />
    </Endpoints>
  </WorkerRole>
</ServiceDefinition>
noteПримечание
Может иметь место ограничение взаимодействия между ролями для внутренних конечных точек с фиксированными и автоматически назначенными портами.

По умолчанию после задания внутренней конечной точки данные от любой роли могут передаваться к внутренней конечной точке другой роли без каких-либо ограничений. Чтобы ограничить взаимодействие, необходимо добавить элемент NetworkTrafficRules к элементу ServiceDefinition в файле определения службы.

  1. Откройте файл ServiceDefinition.csdef для своей службы в текстовом редакторе.

  2. Добавьте XML-код, чтобы определить правила сетевого трафика.

    • При использовании Сценария 1 добавьте следующий код к элементу ServiceDefinition:

      
      <NetworkTrafficRules>
        <OnlyAllowTrafficTo>
          <Destinations>
            <RoleEndpoint endpointName="InternalTCP2" roleName="WorkerRole1"/>
          </Destinations>
          <AllowAllTraffic/>
          <WhenSource matches="AnyRule">
            <FromRole roleName="WebRole1"/>
          </WhenSource>
        </OnlyAllowTrafficTo>
      </NetworkTrafficRules>
      
    • При использовании Сценария 2 добавьте следующий код к элементу ServiceDefinition:

      
      <NetworkTrafficRules>
        <OnlyAllowTrafficTo>
          <Destinations>
            <RoleEndpoint endpointName="InternalTCP2" roleName="WorkerRole1"/>
            <RoleEndpoint endpointName="InternalTCP3" roleName="WorkerRole2"/>
          </Destinations>
          <WhenSource matches="AnyRule">
            <FromRole roleName="WebRole1"/>
          </WhenSource>
        </OnlyAllowTrafficTo>
      </NetworkTrafficRules>
      
      
    • При использовании Сценария 3 добавьте следующий код к элементу ServiceDefinition:

      
      <NetworkTrafficRules>
        <OnlyAllowTrafficTo>
          <Destinations>
            <RoleEndpoint endpointName="InternalTCP2" roleName="WorkerRole1"/>
          </Destinations>
          <AllowAllTraffic/>
          <WhenSource matches="AnyRule">
            <FromRole roleName="WebRole1"/>
          </WhenSource>
        </OnlyAllowTrafficTo>
      </NetworkTrafficRules>
      <NetworkTrafficRules>
        <OnlyAllowTrafficTo>
          <Destinations>
            <RoleEndpoint endpointName="InternalTCP3" roleName="WorkerRole2"/>
          </Destinations>
          <WhenSource matches="AnyRule">
            <FromRole roleName="WorkerRole1"/>
          </WhenSource>
        </OnlyAllowTrafficTo>
      </NetworkTrafficRules>
      
      
    • При использовании Сценария 4 добавьте следующий код к элементу ServiceDefinition:

      
      <NetworkTrafficRules>
        <OnlyAllowTrafficTo>
          <Destinations>
            <RoleEndpoint endpointName="InternalTCP2" roleName="WorkerRole1"/>
          </Destinations>
          <AllowAllTraffic/>
          <WhenSource matches="AnyRule">
            <FromRole roleName="WebRole1"/>
          </WhenSource>
        </OnlyAllowTrafficTo>
      </NetworkTrafficRules>
      <NetworkTrafficRules>
        <OnlyAllowTrafficTo >
          <Destinations>
            <RoleEndpoint endpointName="InternalTCP3" roleName="WorkerRole2"/>
          </Destinations>
          <AllowAllTraffic/>
          <WhenSource matches="AnyRule">
            <FromRole roleName="WorkerRole1"/>
          </WhenSource>
        </OnlyAllowTrafficTo>
      </NetworkTrafficRules> 
      <NetworkTrafficRules>
        <OnlyAllowTrafficTo >
          <Destinations>
            <RoleEndpoint endpointName="InternalTCP4" roleName="WorkerRole2"/>
          </Destinations>
          <AllowAllTraffic/>
          <WhenSource matches="AnyRule">
            <FromRole roleName="WebRole1"/>
          </WhenSource>
        </OnlyAllowTrafficTo>
      </NetworkTrafficRules>
      
      
  3. Сохраните файл.

Дополнительные сведения об элементах, используемых в этих примерах, см. в разделе Схема NetworkTrafficRules.

Управляемая библиотека Azure предоставляет методы для осуществления взаимодействия между ролями во время выполнения. Из кода, выполняемого в рамках экземпляра роли, можно получить сведения о наличии других ролей, их конечных точках, а также информацию о текущем экземпляре роли.

noteПримечание
Сведения можно получать только о тех экземплярах, что выполняются в облачной службе, для которых определена по крайней мере одна внутренняя конечная точка. Нельзя получить данные об экземплярах ролей из другой службы.

Для получения экземпляров роли можно использовать свойство Instances. Сначала используйте CurrentRoleInstance для получения ссылки на текущий экземпляр роли, а затем воспользуйтесь свойством Role, чтобы получить ссылку на саму роль.

Свойство Instances возвращает коллекцию объектов RoleInstance. Данная коллекция всегда содержит текущий экземпляр. Если роль не имеет внутреннюю конечную точку, коллекция содержит текущий экземпляр, но не другие экземпляры. Число экземпляров роли в коллекции будет всегда равно 1 в тех случаях, когда для роли не задана внутренняя конечная точка. Если роль имеет внутреннюю конечную точку, то ее экземпляры можно получить во время выполнения, и количество экземпляров в коллекции будет равно количеству экземпляров, указанному для роли в файле конфигурации службы.

noteПримечание
Управляемая библиотека Azure не предоставляет средства определения работоспособности других экземпляров роли, но их можно реализовать самостоятельно, если службе нужна подобная функциональность. Для получения информации о выполнении экземпляров роли можно использовать средства Azure Diagnostics. Дополнительные сведения о сборе данных диагностики см. в разделе Сбор данных журналов с помощью средств диагностики Azure.

Чтобы определить номер порта для внутренней конечной точки в экземпляре роли, можно использовать свойство InstanceEndpoints для возвращения объекта Dictionary, содержащего имена конечных точек и их соответствующие IP-адреса и порты. Свойство IPEndpoint возвращает IP-адрес и порт для указанной конечной точки. Свойство PublicIPEndpoint возвращает порт для конечной точки со сбалансированной нагрузкой. Часть IP-адреса свойства PublicIPEndpoint не используется.

  1. Откройте файл источника, который нужно использовать для получения данных об экземпляре роли.

  2. Добавьте код для перебора экземпляров роли. В следующем примере кода показано, как записать идентификатор, порт и IP-адрес для экземпляров роли.

    
    foreach (RoleInstance roleInst in RoleEnvironment.CurrentRoleInstance.Role.Instances)
    {
       Trace.WriteLine("Instance ID: " + roleInst.Id);
       foreach (RoleInstanceEndpoint roleInstEndpoint in roleInst.InstanceEndpoints.Values)
       {
          Trace.WriteLine("Instance endpoint IP address and port: " + roleInstEndpoint.IPEndpoint);
       }
    }
    
  3. Сохраните файл.

Показ:
© 2015 Microsoft