Настройка параметров сети для управляемых кластеров Service Fabric

Управляемые кластеры Service Fabric создаются с конфигурацией сети по умолчанию. Эта конфигурация состоит из Azure Load Balancer с общедоступным IP-адресом, виртуальной сетью с выделенной подсетью и NSG, настроенной для основных функций кластера. Кроме того, применяются необязательные правила NSG, такие как разрешение всего исходящего трафика по умолчанию. Эти правила предназначены для упрощения настройки у клиентов. В настоящем документе рассматривается изменение следующих параметров конфигурации сети и многое другое:

• Управление правилами NSG
• Управление доступом по RDP
• Управление конфигурацией Load Balancer
• Включение общедоступного IP-адреса
• Включение IPv6
• Использование собственной виртуальной сети
• Использование собственной подсистемы балансировки нагрузки
• Включение ускорения работы в сети
• Настройка вспомогательных подсетей

Управление правилами NSG

Руководство по правилам NSG

Учитывайте приведенные ниже моменты при создании правил NSG для управляемого кластера.

• Управляемые кластеры Service Fabric резервируют диапазон приоритетов правил NSG от 0 до 999 для важных функциональных возможностей. Нельзя создавать пользовательские правила NSG со значением приоритета менее 1000.
• Управляемые кластеры Service Fabric резервируют диапазон приоритетов 3001—4000 для создания дополнительных правил NSG. Эти правила добавляются автоматически, чтобы ускорить и упросить настройку. Эти правила можно переопределить, добавив настраиваемые правила NSG с приоритетом в диапазоне от 1000 до 3000.
• Настраиваемые правила NSG должны иметь приоритет в диапазоне от 1000 до 3000.

Применение правил NSG

Управляемые кластеры Service Fabric позволяют назначать правила NSG непосредственно в кластерном ресурсе шаблона развертывания.

Чтобы назначить правила NSG, используйте свойство networkSecurityRules ресурса microsoft.servicefabric/managedclusters (версии 2021-05-01 или более поздней версии). Например:

{
  "apiVersion": "2021-05-01",
  "type": "Microsoft.ServiceFabric/managedclusters",
  "properties": {
    "networkSecurityRules": [
      {
        "name": "AllowCustomers",
        "protocol": "*",
        "sourcePortRange": "*",
        "sourceAddressPrefix": "Internet",
        "destinationAddressPrefix": "*",
        "destinationPortRange": "33000-33499",
        "access": "Allow",
        "priority": 2001,
        "direction": "Inbound"
      },
      {
        "name": "AllowARM",
        "protocol": "*",
        "sourcePortRange": "*",
        "sourceAddressPrefix": "AzureResourceManager",
        "destinationAddressPrefix": "*",
        "destinationPortRange": "33500-33699",
        "access": "Allow",
        "priority": 2002,
        "direction": "Inbound"
      },
      {
        "name": "DenyCustomers",
        "protocol": "*",
        "sourcePortRange": "*",
        "sourceAddressPrefix": "Internet",
        "destinationAddressPrefix": "*",
        "destinationPortRange": "33700-33799",
        "access": "Deny",
        "priority": 2003,
        "direction": "Outbound"
      },
      {
        "name": "DenyRDP",
        "protocol": "*",
        "sourcePortRange": "*",
        "sourceAddressPrefix": "*",
        "destinationAddressPrefix": "VirtualNetwork",
        "destinationPortRange": "3389",
        "access": "Deny",
        "priority": 2004,
        "direction": "Inbound",
        "description": "Override for optional SFMC_AllowRdpPort rule. This is required in tests to avoid Sev2 incident for security policy violation."
      }
    ],
    "fabricSettings": [
      "..."
    ]
  }
}

ClientConnection и HttpGatewayConnection по умолчанию и необязательные правила

Правило NSG: SFMC_AllowServiceFabricGatewayToSFRP

Добавляется правило NSG по умолчанию, разрешающее поставщику ресурсов Service Fabric доступ к портам clientConnectionPort и httpGatewayConnectionPort кластера. Это правило разрешает доступ к портам по тегу службы ServiceFabric.

Примечание.

Это правило всегда добавляется и не может быть переопределено.

{
    "name": "SFMC_AllowServiceFabricGatewayToSFRP",
    "type": "Microsoft.Network/networkSecurityGroups/securityRules",
    "properties": {
        "description": "This is required rule to allow SFRP to connect to the cluster. This rule can't be overridden.",
        "protocol": "TCP",
        "sourcePortRange": "*",
        "sourceAddressPrefix": "ServiceFabric",
        "destinationAddressPrefix": "VirtualNetwork",
        "access": "Allow",
        "priority": 500,
        "direction": "Inbound",
        "sourcePortRanges": [],
        "destinationPortRanges": [
            "19000",
            "19080"
        ]
    }
}

Правило NSG: SFMC_AllowServiceFabricGatewayPorts

Это дополнительное правило позволяет клиентам получить доступ к SFX, подключиться к кластеру с помощью PowerShell и использовать конечные точки API кластера Service Fabric из Интернета, так как оно открывает порты подсистемы балансировки нагрузки clientConnectionPort и httpGatewayPort.

Примечание.

Это правило не будет добавлено, если для одного и того же порта используется настраиваемое правило с одинаковыми значениями доступа, направления и протокола. Это правило можно переопределить с помощью настраиваемых правил NSG.

{
    "name": "SFMC_AllowServiceFabricGatewayPorts",
    "type": "Microsoft.Network/networkSecurityGroups/securityRules",
    "properties": {
        "description": "Optional rule to open SF cluster gateway ports. To override add a custom NSG rule for gateway ports in priority range 1000-3000.",
        "protocol": "tcp",
        "sourcePortRange": "*",
        "sourceAddressPrefix": "*",
        "destinationAddressPrefix": "VirtualNetwork",
        "access": "Allow",
        "priority": 3001,
        "direction": "Inbound",
        "sourcePortRanges": [],
        "destinationPortRanges": [
            "19000",
            "19080"
        ]
    }
}

Разрешение доступа к портам RDP из Интернета

Управляемые кластеры Service Fabric по умолчанию не обеспечивают входящий доступ к портам RDP из Интернета. Вы можете открыть входящий доступ к портам RDP из Интернета, задав приведенное ниже свойство для ресурса управляемого кластера Service Fabric.

"allowRDPAccess": true

Если свойство allowRDPAccess имеет значение true, в развертывание кластера будет добавлено приведенное ниже правило NSG.

{
    "name": "SFMC_AllowRdpPort",
    "type": "Microsoft.Network/networkSecurityGroups/securityRules",
    "properties": {
        "description": "Optional rule to open RDP ports.",
        "protocol": "tcp",
        "sourcePortRange": "*",
        "sourceAddressPrefix": "*",
        "destinationAddressPrefix": "VirtualNetwork",
        "access": "Allow",
        "priority": 3002,
        "direction": "Inbound",
        "sourcePortRanges": [],
        "destinationPortRange": "3389"
    }
}

Управляемые кластеры Service Fabric автоматически создают правила NAT для входящего трафика для каждого экземпляра в типе узла. Чтобы определить сопоставления портов для доступа к конкретным экземплярам (узлам кластера), выполните следующие действия.

На портале Azure найдите правила NAT для входящего трафика, созданные управляемым кластером для протокола удаленного рабочего стола (RDP).

1. Перейдите к группе ресурсов управляемого кластера в подписке с именем в следующем формате: SFC_ {ИД_кластера}.

2. Выберите подсистему балансировки нагрузки для кластера с именем в следующем формате: LB-{имя_кластера}.

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

   На следующем снимке экрана показаны правила NAT для входящего трафика для трех разных типов узла.

   

   По умолчанию для кластеров Windows внешний порт находится в диапазоне от 50000 и выше, а целевой порт — это порт 3389, который сопоставляется со службой RDP на целевом узле.

   Примечание.

   Если вы используете функцию BYOLB и хотите настроить RDP, для этого необходимо отдельно настроить пул NAT. При этом правила NAT для этих типов узлов не будут созданы автоматически.

4. Установите удаленное подключение к определенному узлу (экземпляр масштабируемого набора). Можно использовать имя пользователя и пароль, заданные при создании кластера, или любые другие настроенные учетные данные.

На следующем снимке экрана показано подключение по протоколу удаленного рабочего стола к узлу приложений (Instance 0) в кластере Windows.

Изменение конфигурации подсистемы балансировки нагрузки по умолчанию

Порты подсистемы балансировки нагрузки

Управляемые кластеры Service Fabric создают правило NSG в диапазоне приоритетов по умолчанию для всех портов подсистемы балансировки нагрузки, настроенных в разделе loadBalancingRules для свойств ManagedCluster. Это правило открывает порты подсистемы балансировки нагрузки для входящего трафика из Интернета.

Примечание.

Это правило добавляется с приоритетом из дополнительного диапазона приоритетов и может быть переопределено путем добавления настраиваемых правил NSG.

{
    "name": "SFMC_AllowLoadBalancedPorts",
    "type": "Microsoft.Network/networkSecurityGroups/securityRules",
    "properties": {
        "description": "Optional rule to open LB ports",
        "protocol": "*",
        "sourcePortRange": "*",
        "sourceAddressPrefix": "*",
        "destinationAddressPrefix": "VirtualNetwork",
        "access": "Allow",
        "priority": 3003,
        "direction": "Inbound",
        "sourcePortRanges": [],
        "destinationPortRanges": [
        "80", "8080", "4343"
        ]
    }
}

Пробы подсистемы балансировки нагрузки

Управляемые кластеры Service Fabric автоматически создают пробы подсистемы балансировки нагрузки для портов шлюза структуры, а также для всех портов, настроенных в разделе loadBalancingRules свойств управляемого кластера.

{
  "value": [
    {
        "name": "FabricTcpGateway",
        "properties": {
            "provisioningState": "Succeeded",
            "protocol": "Tcp",
            "port": 19000,
            "intervalInSeconds": 5,
            "numberOfProbes": 2,
            "loadBalancingRules": [
                {
                    "id": "<>"
                }
            ]
        },
        "type": "Microsoft.Network/loadBalancers/probes"
    },
    {
        "name": "FabricHttpGateway",
        "properties": {
            "provisioningState": "Succeeded",
            "protocol": "Tcp",
            "port": 19080,
            "intervalInSeconds": 5,
            "numberOfProbes": 2,
            "loadBalancingRules": [
                {
                    "id": "<>"
                }
            ]
        },
        "type": "Microsoft.Network/loadBalancers/probes"
    },
    {
        "name": "probe1_tcp_8080",
        "properties": {
            "provisioningState": "Succeeded",
            "protocol": "Tcp",
            "port": 8080,
            "intervalInSeconds": 5,
            "numberOfProbes": 2,
            "loadBalancingRules": [
            {
                "id": "<>"
            }
        ]
      },
      "type": "Microsoft.Network/loadBalancers/probes"
    }
  ]
}

Включение общедоступного IP-адреса

Примечание.

В настоящее время поддерживается только общедоступный IPv4.

Для обмена данными узлы управляемого кластера Service Fabric не требуют собственных общедоступных IP-адресов. Однако в некоторых сценариях может потребоваться, чтобы узел мог иметь собственный общедоступный IP-адрес для взаимодействия с Интернетом и общедоступными службами Azure. Например:

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

Дополнительные сведения об исходящих подключениях в Azure см. в этой статье.

Общедоступный IP-адрес можно включить только в дополнительных типах узлов, так как типы основных узлов зарезервированы для системных служб Service Fabric. Выполните действия, описанные в разделе "Перенос собственной подсистемы балансировки нагрузки" этой статьи , чтобы создать дополнительный тип узла для управляемого кластера.

Azure динамически назначает доступные IP-адреса.

Примечание.

Включение общедоступного IP-адреса поддерживается только с помощью шаблона ARM.

Ниже описано включение общедоступного IP-адреса на узле.

1. Скачайте шаблон ARM.

2. Для каждого типа узла в шаблоне добавьте enableNodePublicIP в шаблон ARM:

   {
       "name": "<secondary_node_type_name>", 
       "apiVersion": "2023-02-01-preview", 
       "properties": { 
           "isPrimary" : false, 
           "vmImageResourceId": "/subscriptions/<your_subscription_id>/resourceGroups/<your_resource_group>/providers/Microsoft.Compute/images/<your_custom_image>", 
           "vmSize": "Standard_D2", 
           "vmInstanceCount": 5, 
           "dataDiskSizeGB": 100, 
           "enableNodePublicIP": true 
       }
   } 
   

3. Делой шаблон ARM.

4. Убедитесь, что на узлах есть общедоступный IP-адрес, выполнив следующую команду PowerShell:

   az vmss list-instance-public-ips -g MC_MyResourceGroup2_MyManagedCluster_eastus -n YourVirtualMachineScaleSetName
   

   Команда выводит данные в формате JSON.

   [
     {
       "etag": "etag_0",
       "id": "<id_0/name>",
       "idleTimeoutInMinutes": 15,
       "ipAddress": "<ip_address_0>",
       "ipConfiguration": {
         "id": "<configuration_id_0>",
         "resourceGroup": "<your_resource_group>"
       },
       "ipTags": [],
       "name": "<name>",
       "provisioningState": "Succeeded",
       "publicIPAddressVersion": "IPv4",
       "publicIPAllocationMethod": "Static",
       "resourceGroup": "<your_resource_group>",
       "resourceGuid": "resource_guid_0",
       "sku": {
         "name": "Standard"
       }
     },
     {
       "etag": "etag_1",
       "id": "/<id_1/name>",
       "idleTimeoutInMinutes": 15,
       "ipAddress": "<ip_address_1>",
       "ipConfiguration": {
         "id": "<configuration_id_1>",
         "resourceGroup": "<your_resource_group>"
       },
       "ipTags": [],
       "name": "<name>",
       "provisioningState": "Succeeded",
       "publicIPAddressVersion": "IPv4",
       "publicIPAllocationMethod": "Static",
       "resourceGroup": "<your_resource_group>",
       "resourceGuid": "resource_guid_1",
       "sku": {
         "name": "Standard"
       }
     },
     {
       "etag": "etag_2",
       "id": "<id_2/name>",
       "idleTimeoutInMinutes": 15,
       "ipAddress": "<ip_address_2>",
       "ipConfiguration": {
         "id": "<configuration_id_2>",
         "resourceGroup": "<your_resource_group>"
       },
       "ipTags": [],
       "name": "<name>",
       "provisioningState": "Succeeded",
       "publicIPAddressVersion": "IPv4",
       "publicIPAllocationMethod": "Static",
       "resourceGroup": "<your_resource_group>",
       "resourceGuid": "resource_guid_2",
       "sku": {
         "name": "Standard"
       }
     }
   ]
   

Включение IPv6

Управляемые кластеры по умолчанию не поддерживают IPv6. Эта функция включит полный стек протоколов IPv4/IPv6 из внешнего интерфейса Load Balancer в серверные ресурсы. Любые изменения, внесенные в правила конфигурации или NSG для подсистемы балансировки нагрузки управляемого кластера, повлияют на маршрутизацию IPv4 и IPv6.

Примечание.

Этот параметр недоступен на портале и не может быть изменен после создания кластера.

• Для ресурса управляемого кластера Service Fabric параметр apiVersion должен иметь значение 2022-01-01 или выше.

1. Установите следующее свойство на ресурсе управляемого кластера Service Fabric.

       "resources": [
            {
            "apiVersion": "[variables('sfApiVersion')]",
            "type": "Microsoft.ServiceFabric/managedclusters",
            ...
            "properties": {
                "enableIpv6": true
                },
            }
       ]
   

2. Разверните управляемый кластер с поддержкой IPv6. Настройте шаблон выборки по мере необходимости или создайте свой собственный. В следующем примере мы создадим группу ресурсов с именем MyResourceGroup в westus и развернем кластер с включенной функцией.

    New-AzResourceGroup -Name MyResourceGroup -Location westus
    New-AzResourceGroupDeployment -Name deployment -ResourceGroupName MyResourceGroup -TemplateFile AzureDeploy.json
   

   После развертывания виртуальная сеть и ресурсы кластера будут содержать двойной стек. В результате в подсистеме балансировки нагрузки внешнего интерфейса кластера будет создан уникальный адрес dns, например, mycluster-ipv6.southcentralus.cloudapp.azure.com, связанный с общедоступным ipv6-адресом на Azure Load Balancer и частными ipv6-адресами на виртуальных машинах.

Использование собственной виртуальной сети

Эта функция позволяет клиентам использовать существующую виртуальную сеть, указывая выделенную подсеть, в которую управляемый кластер будет развертывать свои ресурсы. Это может быть полезно, если у вас уже есть настроенная виртуальная сеть и подсеть со связанными политиками безопасности и маршрутизацией трафика, которые необходимо использовать. После развертывания в существующей виртуальной сети легко использовать или внедрить другие сетевые компоненты, такие как Azure ExpressRoute, VPN-шлюз Azure, группа безопасности сети и пиринг между виртуальными сетями. Кроме того, можно использовать свою собственную подсистему балансировки нагрузки Azure, если необходимо.

Примечание.

При использовании BYOVNET управляемые кластерные ресурсы развертываются в одной подсети.

Примечание.

Этот параметр нельзя изменить после создания кластера, и управляемый кластер назначит группе безопасности сети предоставленную подсеть. Не переопределите назначение группы безопасности сети или трафик может нарушиться.

Использование собственной виртуальной сети:

1. Получите службу Id из подписки для приложения поставщика ресурсов Service Fabric.

   Login-AzAccount
   Select-AzSubscription -SubscriptionId <SubId>
   Get-AzADServicePrincipal -DisplayName "Azure Service Fabric Resource Provider"
   

   Примечание.

   Убедитесь, что используется правильная подписка, идентификатор субъекта изменится, если подписка принадлежит другому клиенту.

   ServicePrincipalNames : {74cb6831-0dbb-4be1-8206-fd4df301cdc2}
   ApplicationId         : 74cb6831-0dbb-4be1-8206-fd4df301cdc2
   ObjectType            : ServicePrincipal
   DisplayName           : Azure Service Fabric Resource Provider
   Id                    : 00000000-0000-0000-0000-000000000000
   

   Обратите внимание на Id предыдущего вывода как на principalId для использования на более позднем этапе

   Имя определения роли	Идентификатор определения роли
   Участник сети	4d97b98b-1d4f-4787-a291-c67834d212e7

   Обратите внимание на значения свойства Role definition name и Role definition ID для использования на более позднем этапе

2. Добавьте назначение роли для приложения поставщика ресурсов Service Fabric. Добавление назначения роли выполняется один раз. Чтобы добавить роль, необходимо выполнить следующие команды PowerShell или настроить шаблон Azure Resource Manager (ARM), как описано ниже.

   В приведенном ниже примере мы начнем с существующей виртуальной сети ExistingRG-vnet в группе ресурсов ExistingRG. В ней есть подсеть default.

   Получите необходимые сведения из существующей виртуальной сети.

   Login-AzAccount
   Select-AzSubscription -SubscriptionId <SubId>
   Get-AzVirtualNetwork -Name ExistingRG-vnet -ResourceGroupName ExistingRG
   

   Обратите внимание на следующее имя подсети и значение свойства Id, которое возвращается из раздела Subnets в ответе, который будет использоваться на последующих этапах.

   Subnets:[
   {
   ...
   "Id": "/subscriptions/<subscriptionId>/resourceGroups/Existing-RG/providers/Microsoft.Network/virtualNetworks/ExistingRG-vnet/subnets/default"
   }]
   

   Выполните следующую команду PowerShell, используя идентификатор субъекта, имя определения роли из шага 2 и область назначения Id, полученную выше:

   New-AzRoleAssignment -PrincipalId 00000000-0000-0000-0000-000000000000 -RoleDefinitionName "Network Contributor" -Scope "/subscriptions/<subscriptionId>/resourceGroups/<resourceGroupName>/providers/Microsoft.Network/virtualNetworks/<vnetName>/subnets/<subnetName>"
   

   Или можно добавить назначение роли с помощью шаблона Azure Resource Manager (ARM), настроенного с правильными значениями для principalId, roleDefinitionId, vnetName и subnetName:

      "type": "Microsoft.Authorization/roleAssignments",
      "apiVersion": "2020-04-01-preview",
      "name": "[parameters('VNetRoleAssignmentID')]",
      "scope": "[concat('Microsoft.Network/virtualNetworks/', parameters('vnetName'), '/subnets/', parameters('subnetName'))]",
      "dependsOn": [
        "[concat('Microsoft.Network/virtualNetworks/', parameters('vnetName'))]"
      ],
      "properties": {
        "roleDefinitionId": "[concat('/subscriptions/', subscription().subscriptionId, '/providers/Microsoft.Authorization/roleDefinitions/4d97b98b-1d4f-4787-a291-c67834d212e7')]",
        "principalId": "00000000-0000-0000-0000-000000000000"
      }
   

   Примечание.

   VNetRoleAssignmentID должно быть GUID. При повторном развертывании шаблона с этим назначением роли убедитесь, что GUID совпадает с исходным. Рекомендуется выполнить этот изолированный ресурс или удалить этот ресурс из шаблона кластера после развертывания, так как его нужно создать только один раз.

   Ниже приведен полный пример шаблона Azure Resource Manager (ARM), который создает подсеть виртуальной сети и выполняет назначение ролей для этого шага.

3. Настройте свойство subnetId для развертывания кластера после настройки роли, как показано ниже:

• Для ресурса управляемого кластера Service Fabric параметр apiVersion должен иметь значение 2022-01-01 или выше.

    "resources": [
        {
            "apiVersion": "[variables('sfApiVersion')]",
            "type": "Microsoft.ServiceFabric/managedclusters",
            ...
            },
            "properties": {
                "subnetId": "subnetId",
            ...
            }
    ]
  

  См. статью по использованию собственного шаблона выборки кластера виртуальной сети или настройте собственный.

4. Разверните настроенный шаблон управляемого кластера Azure Resource Manager (ARM).

   В следующем примере мы создадим группу ресурсов с именем MyResourceGroup в westus и развернем кластер с включенной функцией.

    New-AzResourceGroup -Name MyResourceGroup -Location westus
    New-AzResourceGroupDeployment -Name deployment -ResourceGroupName MyResourceGroup -TemplateFile AzureDeploy.json
   

   При использовании собственной подсети виртуальной сети общедоступная конечная точка по-прежнему создается и управляется поставщиком ресурсов, но в настроенной подсети. Эта функция не позволяет указать общедоступный IP-адрес или повторно использовать статический IP-адрес в Azure Load Balancer. Вы можете использовать собственную подсистему Azure Load Balancer в сочетании с этой функцией или самостоятельно, если вам нужны эти или другие сценарии подсистемы балансировки нагрузки, которые не поддерживаются изначально.

Использование собственного экземпляра Azure Load Balancer

Управляемые кластеры создают общедоступный экземпляр Azure Load Balancer (цен. категория "Стандартный") и полное доменное имя со статическим общедоступным IP-адресом для первичных и вторичных узлов. С помощью собственной подсистемы балансировки нагрузки можно использовать имеющийся Azure Load Balancer для обработки входящего и исходящего трафика вторичных узлов. При использовании собственной подсистемы Azure Load Balancer вы можете:

• Использование предварительно настроенного статического IP-адреса Load Balancer для частного или общедоступного трафика
• Сопоставить Load Balancer с конкретным типом узла
• Настроить правила группы безопасности сети для каждого типа узла, так как узлы каждого типа развертываются в отдельной подсети.
• Поддерживать существующие политики и элементы управления
• Настроить внутреннюю подсистему балансировки нагрузки, а подсистему балансировки нагрузки по умолчанию использовать для внешнего трафика.

Примечание.

При использовании BYOVNET управляемые кластерные ресурсы развертываются в одной подсети с одной NSG независимо от дополнительных настроенных подсистем балансировки нагрузки.

Примечание.

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

Требования к компонентам

• Поддерживаются подсистемы балансировки нагрузки Azure Load Balancer с базовым и стандартным номером SKU
• В Azure Load Balancer должны быть настроены серверные пулы и пулы NAT.
• Необходимо включить исходящие подключения через предоставленную общедоступную подсистему балансировки нагрузки или общедоступную подсистему балансировки нагрузки по умолчанию.

Вот несколько примеров сценариев для использования клиентами.

В этом примере клиент хочет направить трафик через существующую подсистему Azure Load Balancer, настроенный с существующим статическим IP-адресом, на два типа узлов.

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

В этом примере клиенту нужно передавать трафик через существующие внутренние экземпляры Azure Load Balancer. Это помогает независимо управлять потоком трафика к приложениям, которые работают на узлах разных типов. При такой конфигурации узлы каждого типа будут находиться в своей управляемой NSG и для внешнего трафика использовать подсистему балансировки нагрузки по умолчанию.

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

1. Получите службу Id из подписки для приложения поставщика ресурсов Service Fabric:

   Login-AzAccount
   Select-AzSubscription -SubscriptionId <SubId>
   Get-AzADServicePrincipal -DisplayName "Azure Service Fabric Resource Provider"
   

   Примечание.

   Убедитесь, что используется правильная подписка, идентификатор субъекта изменится, если подписка принадлежит другому клиенту.

   ServicePrincipalNames : {74cb6831-0dbb-4be1-8206-fd4df301cdc2}
   ApplicationId         : 74cb6831-0dbb-4be1-8206-fd4df301cdc2
   ObjectType            : ServicePrincipal
   DisplayName           : Azure Service Fabric Resource Provider
   Id                    : 00000000-0000-0000-0000-000000000000
   

   Обратите внимание на Id предыдущего вывода как на principalId для использования на более позднем этапе

   Имя определения роли	Идентификатор определения роли
   Участник сети	4d97b98b-1d4f-4787-a291-c67834d212e7

   Обратите внимание на значения свойства Role definition name и Role definition ID для использования на более позднем этапе

2. Добавьте назначение роли для приложения поставщика ресурсов Service Fabric. Добавление назначения роли выполняется один раз. Чтобы добавить роль, необходимо выполнить следующие команды PowerShell или настроить шаблон Azure Resource Manager (ARM), как описано ниже.

   В следующих шагах мы начнем с существующей подсистемы балансировки нагрузки с именем Existing-LoadBalancer1 в группе ресурсов Existing-RG.

   Получите сведения о требуемом свойстве Id из существующей подсистемы Azure Load Balancer.

   Login-AzAccount
   Select-AzSubscription -SubscriptionId <SubId>
   Get-AzLoadBalancer -Name "Existing-LoadBalancer1" -ResourceGroupName "Existing-RG"
   

   Обратите внимание на следующий Id, который будет использоваться в дальнейшем шаге:

   {
   ...
   "Id": "/subscriptions/<subscriptionId>/resourceGroups/Existing-RG/providers/Microsoft.Network/loadBalancers/Existing-LoadBalancer1"
   }
   

   Выполните следующую команду PowerShell, используя идентификатор субъекта, имя определения роли из шага 2 и область назначения Id, полученную выше:

   New-AzRoleAssignment -PrincipalId 00000000-0000-0000-0000-000000000000 -RoleDefinitionName "Network Contributor" -Scope "/subscriptions/<subscriptionId>/resourceGroups/<resourceGroupName>/providers/Microsoft.Network/loadBalancers/<LoadBalancerName>"
   

   Или можно добавить назначение роли с помощью шаблона Azure Resource Manager (ARM), настроенного с правильными значениями для principalId и roleDefinitionId":

      "type": "Microsoft.Authorization/roleAssignments",
      "apiVersion": "2020-04-01-preview",
      "name": "[parameters('loadBalancerRoleAssignmentID')]",
      "scope": "[concat('Microsoft.Network/loadBalancers/', variables('lbName'))]",
      "dependsOn": [
        "[concat('Microsoft.Network/loadBalancers/', variables('lbName'))]"
      ],
      "properties": {
        "roleDefinitionId": "[concat('/subscriptions/', subscription().subscriptionId, '/providers/Microsoft.Authorization/roleDefinitions/4d97b98b-1d4f-4787-a291-c67834d212e7')]",
        "principalId": "00000000-0000-0000-0000-000000000000"
      }
   

   Примечание.

   loadBalancerRoleAssignmentID должно быть GUID. При повторном развертывании шаблона с этим назначением роли убедитесь, что GUID совпадает с исходным. Рекомендуется выполнить этот изолированный ресурс или удалить этот ресурс из шаблона кластера после развертывания, так как его нужно создать только один раз.

   Ознакомьтесь с этим примером шаблона, с помощью которого можно создать общедоступную подсистему балансировки нагрузки и назначить роль.

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

   Задайте outboundRules, чтобы настроить общедоступную подсистему балансировки нагрузки для обеспечения исходящих подключений. Ознакомьтесь с шаблоном Azure Resource Manager (ARM) для создания подсистемы балансировки нагрузки и назначения роли.

   ИЛИ

   Чтобы настроить тип узла для использования подсистемы балансировки нагрузки по умолчанию, задайте в шаблоне следующее:

   • Для ресурса управляемого кластера Service Fabric параметр apiVersion должен иметь значение 2022-01-01 или выше.

    "resources": [
      {
      "apiVersion": "[variables('sfApiVersion')]",
      "type": "Microsoft.ServiceFabric/managedclusters/nodetypes",
      "properties": {
          "isPrimary": false,
          "useDefaultPublicLoadBalancer": true
          }
      }
    ]
   

4. При необходимости настройте входящий порт приложения и связанную пробу на существующей подсистеме Azure Load Balancer. Ознакомьтесь с примером использования собственного шаблона Azure Resource Manager (ARM) для подсистемы балансировки нагрузки.

5. Если необходимо, настройте правила NSG управляемого кластера, применяемые к типу узла, чтобы разрешить любой требуемый трафик, настроенный в подсистеме Azure Load Balancer, или трафик будет заблокирован. В примере использования собственного шаблона Azure Resource Manager (ARM) для подсистемы балансировки нагрузки показана конфигурация правила NSG для входящего трафика. Найдите свойство networkSecurityRules в шаблоне.

6. Разверните настроенный шаблон ARM для управляемого кластера. На этом этапе мы используем собственный пример шаблона для подсистемы балансировки нагрузки Azure Resource Manager (ARM).

   Приведенный пример создает группу ресурсов MyResourceGroup в westus и развертывает кластер с использованием существующей подсистемы балансировки нагрузки.

    New-AzResourceGroup -Name MyResourceGroup -Location westus
    New-AzResourceGroupDeployment -Name deployment -ResourceGroupName MyResourceGroup -TemplateFile AzureDeploy.json
   

   После развертывания тип вторичного узла настраивается таким образом, чтобы использовать указанную подсистему балансировки нагрузки для входящего и исходящего трафика. Подключение клиента Service Fabric и конечные точки шлюза по-прежнему будут указывать на общедоступную службу DNS для статического IP-адреса типа первичного узла управляемого кластера.

Включить ускорение работы в сети

Ускорение сети позволяет использовать виртуализацию SR-IOV на виртуальной машине в масштабируемом наборе виртуальных машин, которая задана в качестве базового ресурса для типов узлов. Этот высокопроизводительный метод обеспечивает обход узла на пути к данным, что уменьшает задержку, дрожание и загрузку ЦП. Он предназначен для ресурсоемких рабочих нагрузок сети. Управляемые узлы кластера Service Fabric можно подготовить с помощью ускорения сети на виртуальных машинах с поддерживаемыми SKU. Ознакомьтесь с этими ограничениями и ограничениями для дополнительных рекомендаций.

• Обратите внимание на то, что функция ускорения сети поддерживается для большинства размеров экземпляров, оптимизированных для вычислений, и экземпляров общего назначения с количеством виртуальных ЦП от 2. На экземплярах, поддерживающих технологию Hyper-Threading, функция ускорения сети поддерживается в экземплярах виртуальных машин с количеством виртуальных ЦП от 4.

Включите ускорение сети, объявив свойство enableAcceleratedNetworking в шаблоне Resource Manager следующим образом:

• Для ресурса управляемого кластера Service Fabric параметр apiVersion должен иметь значение 2022-01-01 или выше.

   {
   "apiVersion": "[variables('sfApiVersion')]",
   "type": "Microsoft.ServiceFabric/managedclusters/nodetypes",
   ...
   "properties": {
       ...
       "enableAcceleratedNetworking": true,
       ...
   }

Чтобы включить ускорение сети в имеющемся кластере Service Fabric, следует сначала масштабировать кластер Service Fabric, добавив в него новый тип узла. Затем нужно выполнить следующее:

1. Подготовьте узел выбранного типа с поддержкой ускорения сети.
2. Перенесите службы и их состояния на подготовленный узел с поддержкой ускорения сети.

Масштабирование инфраструктуры требуется для включения ускорения сети в имеющемся кластере. Включение ускорения сети приведет к простою, так как все виртуальные машины в группе доступности следует остановить и освободить, прежде чем включить ускорение на любой имеющейся сетевой карте.

Настройка вспомогательных подсетей

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

Настройте вспомогательные подсети, задав свойство auxiliarySubnets и обязательные параметры в шаблоне Resource Manager следующим образом:

• Для ресурса управляемого кластера Service Fabric параметр apiVersion должен иметь значение 2022-01-01 или выше.

    "resources": [
        {
            "apiVersion": "[variables('sfApiVersion')]",
            "type": "Microsoft.ServiceFabric/managedclusters",
              "properties": {
                "auxiliarySubnets": [
                  {
                  "name" : "mysubnet",
                  "enableIpv6" : "true"
                  }
                ]
              }
        }
    ]              

См. полный список доступных параметров.

Следующие шаги

Параметры конфигурации управляемых кластеров Service FabricОбзор управляемых кластеров Service Fabric