Настройка параметров сети для управляемых кластеров 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 непосредственно в ресурсе кластера шаблона развертывания.

Используйте свойство networkSecurityRules ресурса Microsoft.ServiceFabric/managedclusters (версия или более поздняя), 2021-05-01 чтобы назначить правила NSG. Рассмотрим пример.

{
  "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 из Интернета, открыв порты LB для clientConnectionPort и httpGatewayPort.

{
    "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_{cluster-id}

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

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

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

   

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

   Note

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

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

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

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

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

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

{
    "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-адреса

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

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

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

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

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

Ниже описано включение общедоступного 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. Настройте образец шаблона по мере необходимости или создайте собственный. В следующем примере мы создадим группу ресурсов, которая вызывается MyResourceGroupwestus и развертывает кластер с включенной функцией.

    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 .

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

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

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

   Note

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

   ServicePrincipalNames : {00001111-aaaa-2222-bbbb-3333cccc4444}
   ApplicationId         : 00001111-aaaa-2222-bbbb-3333cccc4444
   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, roleDefinitionIdvnetNameи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"
      }
   

   Note

   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).

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

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

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

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

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

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

   Чтобы использовать подсети уровня узла, укажите "useCustomVnet": true в определении управляемого кластера. Если "useCustomVnet" задано значение true, подсеть кластера по умолчанию не создается. При использовании подсетей subnetId уровня типа узла становится обязательным свойством в определении типа узла.

   Important

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

Использование собственной подсистемы балансировки нагрузки Azure

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

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

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

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

Ниже приведены несколько примеров сценариев, для которых клиенты могут использовать следующее:

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

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

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

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

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

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

   Note

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

   ServicePrincipalNames : {00001111-aaaa-2222-bbbb-3333cccc4444}
   ApplicationId         : 00001111-aaaa-2222-bbbb-3333cccc4444
   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"
      }
   

   Note

   loadBalancerRoleAssignmentID должен быть GUID. Если вы снова развернете шаблон, включив это назначение роли, убедитесь, что ИДЕНТИФИКАТОР GUID совпадает с исходным. Мы рекомендуем запустить этот изолированный или удалить этот ресурс из шаблона кластера после развертывания, так как он просто должен быть создан один раз.

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

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

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

   OR

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

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

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

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

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

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

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

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

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

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

Ускорение сети обеспечивает виртуализацию одно корневых операций ввода-вывода (SR-IOV) для виртуальной машины масштабируемого набора виртуальных машин, которая является базовым ресурсом для типов узлов. Этот высокопроизводительный путь передает узел из пути к данным, что снижает задержку, jitter и загрузку ЦП для наиболее требовательных сетевых рабочих нагрузок. Типы узлов управляемого кластера 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