Konfigurowanie ustawień sieciowych dla klastrów zarządzanych usługi Service Fabric

Klastry zarządzane usługi Service Fabric są tworzone z domyślną konfiguracją sieci. Ta konfiguracja składa się z Azure Load Balancer z publicznym adresem IP, siecią wirtualną z przydzieloną jedną podsiecią i sieciową grupą zabezpieczeń skonfigurowaną pod kątem podstawowych funkcji klastra. Istnieją również opcjonalne reguły sieciowej grupy zabezpieczeń, takie jak zezwalanie na cały ruch wychodzący domyślnie, który ma ułatwić konfigurację klienta. W tym dokumencie przedstawiono sposób modyfikowania następujących opcji konfiguracji sieci i nie tylko:

• Zarządzanie regułami sieciowej grupy zabezpieczeń
• Zarządzanie dostępem RDP
• Zarządzanie konfiguracją Load Balancer
• Włączanie publicznego adresu IP
• Włączanie protokołu IPv6
• Korzystanie z własnej sieci wirtualnej
• Korzystanie z własnego modułu równoważenia obciążenia
• Włączanie przyspieszonej sieci
• Konfigurowanie podsieci pomocniczych

Zarządzanie regułami sieciowej grupy zabezpieczeń

Wskazówki dotyczące reguł sieciowej grupy zabezpieczeń

Należy pamiętać o tych zagadnieniach podczas tworzenia nowych reguł sieciowej grupy zabezpieczeń dla klastra zarządzanego.

• Klastry zarządzane usługi Service Fabric rezerwują zakres priorytetu reguły sieciowej grupy zabezpieczeń od 0 do 999 w celu uzyskania podstawowych funkcji. Nie można utworzyć niestandardowych reguł sieciowej grupy zabezpieczeń z wartością priorytetu mniejszą niż 1000.
• Klastry zarządzane usługi Service Fabric rezerwują zakres priorytetów od 3001 do 4000 do tworzenia opcjonalnych reguł sieciowej grupy zabezpieczeń. Te reguły są dodawane automatycznie w celu szybkiego i łatwego konfigurowania. Te reguły można zastąpić, dodając niestandardowe reguły sieciowej grupy zabezpieczeń w zakresie priorytetów od 1000 do 3000.
• Niestandardowe reguły sieciowej grupy zabezpieczeń powinny mieć priorytet w zakresie od 1000 do 3000.

Stosowanie reguł sieciowej grupy zabezpieczeń

Klastry zarządzane usługi Service Fabric umożliwiają przypisywanie reguł sieciowej grupy zabezpieczeń bezpośrednio w zasobie klastra szablonu wdrożenia.

Użyj właściwości networkSecurityRules zasobu Microsoft.ServiceFabric/managedclusters (wersja 2021-05-01 lub nowsza), aby przypisać reguły sieciowej grupy zabezpieczeń. Przykład:

{
  "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 i HttpGatewayConnection domyślne i opcjonalne reguły

Reguła sieciowej grupy zabezpieczeń: SFMC_AllowServiceFabricGatewayToSFRP

Dodano domyślną regułę sieciowej grupy zabezpieczeń, aby umożliwić dostawcy zasobów usługi Service Fabric dostęp do klienta klastraConnectionPort i httpGatewayConnectionPort. Ta reguła umożliwia dostęp do portów za pośrednictwem tagu usługi "ServiceFabric".

Uwaga

Ta reguła jest zawsze dodawana i nie można jej zastąpić.

{
    "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"
        ]
    }
}

Reguła sieciowej grupy zabezpieczeń: SFMC_AllowServiceFabricGatewayPorts

Ta opcjonalna reguła umożliwia klientom dostęp do rozwiązania SFX, nawiązywanie połączenia z klastrem przy użyciu programu PowerShell i używanie punktów końcowych interfejsu API klastra usługi Service Fabric z Internetu przez otwarcie portów modułu równoważenia obciążenia dla klientaConnectionPort i httpGatewayPort.

Uwaga

Ta reguła nie zostanie dodana, jeśli istnieje reguła niestandardowa z tymi samymi wartościami dostępu, kierunku i protokołu dla tego samego portu. Tę regułę można zastąpić niestandardowymi regułami sieciowej grupy zabezpieczeń.

{
    "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"
        ]
    }
}

Włączanie dostępu do portów RDP z Internetu

Klastry zarządzane usługi Service Fabric domyślnie nie umożliwiają dostępu przychodzącego do portów RDP z Internetu. Dostęp przychodzący do portów RDP z Internetu można otworzyć, ustawiając następującą właściwość w zasobie klastra zarządzanego usługi Service Fabric.

"allowRDPAccess": true

Gdy właściwość allowRDPAccess ma wartość true, do wdrożenia klastra zostanie dodana następująca reguła sieciowej grupy zabezpieczeń.

{
    "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"
    }
}

Klastry zarządzane usługi Service Fabric automatycznie tworzą reguły NAT dla każdego wystąpienia w typie węzła. Aby znaleźć mapowania portów w celu uzyskania dostępu do określonych wystąpień (węzłów klastra), wykonaj poniższe kroki:

Za pomocą Azure Portal znajdź klaster zarządzany utworzony dla ruchu przychodzącego reguły NAT dla protokołu RDP (Remote Desktop Protocol).

1. Przejdź do grupy zasobów klastra zarządzanego w ramach subskrypcji o następującym formacie: SFC_{cluster-id}

2. Wybierz moduł równoważenia obciążenia dla klastra o następującym formacie: LB-{nazwa-klastra}

3. Na stronie modułu równoważenia obciążenia wybierz pozycję Reguły nat dla ruchu przychodzącego. Przejrzyj reguły nat dla ruchu przychodzącego, aby potwierdzić port wejściowy frontonu do mapowania portów docelowych dla węzła.

   Poniższy zrzut ekranu przedstawia reguły NAT dla ruchu przychodzącego dla trzech różnych typów węzłów:

   

   Domyślnie w przypadku klastrów systemu Windows port frontonu znajduje się w zakresie 50000 i wyższym, a port docelowy to port 3389, który jest mapowany na usługę RDP w węźle docelowym.

   Uwaga

   Jeśli używasz funkcji BYOLB i potrzebujesz protokołu RDP, musisz skonfigurować pulę translatora adresów sieciowych oddzielnie, aby to zrobić. Nie spowoduje to automatycznego utworzenia żadnych reguł NAT dla tych typów węzłów.

4. Zdalne nawiązywanie połączenia z określonym węzłem (wystąpienie zestawu skalowania). Możesz użyć nazwy użytkownika i hasła ustawionego podczas tworzenia klastra lub innych skonfigurowanych poświadczeń.

Poniższy zrzut ekranu przedstawia używanie połączenia pulpitu zdalnego w celu nawiązania połączenia z węzłem aplikacji (wystąpienie 0) w klastrze systemu Windows:

Modyfikowanie domyślnej konfiguracji modułu równoważenia obciążenia

Porty modułu równoważenia obciążenia

Klastry zarządzane usługi Service Fabric tworzą regułę sieciowej grupy zabezpieczeń w domyślnym zakresie priorytetów dla wszystkich portów modułu równoważenia obciążenia (LB) skonfigurowanych w sekcji "loadBalancingRules" w obszarze Właściwości managedCluster . Ta reguła otwiera porty modułu równoważenia obciążenia dla ruchu przychodzącego z Internetu.

Uwaga

Ta reguła jest dodawana w opcjonalnym zakresie priorytetów i może zostać zastąpiona przez dodanie niestandardowych reguł sieciowej grupy zabezpieczeń.

{
    "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"
        ]
    }
}

Sondy modułu równoważenia obciążenia

Klastry zarządzane usługi Service Fabric automatycznie tworzą sondy modułu równoważenia obciążenia dla portów bramy sieci szkieletowej i wszystkich portów skonfigurowanych w loadBalancingRules sekcji właściwości klastra zarządzanego.

{
  "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"
    }
  ]
}

Włączanie publicznego adresu IP

Uwaga

Obecnie obsługiwany jest tylko publiczny protokół IPv4.

Węzły klastra zarządzanego usługi Service Fabric nie wymagają własnych publicznych adresów IP do komunikacji. Jednak niektóre scenariusze mogą wymagać, aby węzeł miał własny publiczny adres IP do komunikowania się z Internetem i publicznymi usługami platformy Azure. Przykład:

• Gry, w których konsola musi nawiązać bezpośrednie połączenie z maszyną wirtualną w chmurze, która wykonuje przetwarzanie fizyki gry.
• Maszyny wirtualne, które muszą nawiązać połączenia zewnętrzne ze sobą w różnych regionach w rozproszonej bazie danych.

Aby uzyskać więcej informacji na temat połączeń wychodzących na platformie Azure, zobacz Understanding outbound connections (Opis połączeń wychodzących).

Publiczny adres IP można włączyć tylko w typach węzłów pomocniczych, ponieważ podstawowe typy węzłów są zarezerwowane dla usług systemowych usługi Service Fabric. Wykonaj kroki opisane w sekcji Bring your own load balancer w tym artykule , aby utworzyć pomocniczy typ węzła dla klastra zarządzanego.

Platforma Azure dynamicznie przypisuje dostępne adresy IP.

Uwaga

Włączanie publicznego adresu IP jest obsługiwane tylko za pośrednictwem szablonu usługi ARM.

W poniższych krokach opisano włączanie publicznego adresu IP w węźle.

1. Pobierz szablon usługi ARM.

2. Dla każdego typu węzła w szablonie dodaj enableNodePublicIP do szablonu usługi 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. Deloy szablon usługi ARM.

4. Sprawdź, czy masz publiczny adres IP w węzłach, uruchamiając następujące polecenie programu PowerShell:

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

   Polecenie generuje dane wyjściowe w formacie 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"
       }
     }
   ]
   

Włączanie protokołu IPv6

Klastry zarządzane nie włączają domyślnie protokołu IPv6. Ta funkcja włączy pełną funkcję IPv4/IPv6 z frontonu Load Balancer do zasobów zaplecza. Wszelkie zmiany wprowadzone w konfiguracji modułu równoważenia obciążenia klastra zarządzanego lub reguły sieciowej grupy zabezpieczeń będą mieć wpływ zarówno na routing IPv4, jak i IPv6.

Uwaga

To ustawienie nie jest dostępne w portalu i nie można go zmienić po utworzeniu klastra.

• Interfejs API zasobów zarządzanego klastra usługi Service Fabric powinien mieć wartość 2022-01-01 lub nowszą.

1. Ustaw następującą właściwość w zasobie klastra zarządzanego usługi Service Fabric.

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

2. Wdróż klaster zarządzany z włączoną obsługą protokołu IPv6. Dostosuj przykładowy szablon zgodnie z potrzebami lub skompiluj własny. W poniższym przykładzie utworzymy grupę zasobów o nazwie MyResourceGroup i westus wdrożymy klaster z włączoną tą funkcją.

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

   Po wdrożeniu sieć wirtualna i zasoby klastrów będą mieć podwójny stos. W związku z tym moduł równoważenia obciążenia frontonu klastrów będzie miał utworzony unikatowy adres DNS, mycluster-ipv6.southcentralus.cloudapp.azure.com który jest skojarzony z publicznym adresem IPv6 na Azure Load Balancer i prywatnych adresach IPv6 na maszynach wirtualnych.

Korzystanie z własnej sieci wirtualnej

Ta funkcja umożliwia klientom korzystanie z istniejącej sieci wirtualnej przez określenie dedykowanej podsieci, w której klaster zarządzany wdroży swoje zasoby. Może to być przydatne, jeśli masz już skonfigurowaną sieć wirtualną i podsieć z powiązanymi zasadami zabezpieczeń i routingiem ruchu, którego chcesz użyć. Po wdrożeniu w istniejącej sieci wirtualnej można łatwo korzystać z innych funkcji sieciowych, takich jak Azure ExpressRoute, Azure VPN Gateway, sieciowa grupa zabezpieczeń i komunikacja równorzędna sieci wirtualnych. Ponadto w razie potrzeby możesz również skorzystać z własnego modułu równoważenia obciążenia platformy Azure .

Uwaga

W przypadku korzystania z usługi BYOVNET zasoby klastra zarządzanego zostaną wdrożone w jednej podsieci.

Uwaga

Tego ustawienia nie można zmienić po utworzeniu klastra, a zarządzany klaster przypisze sieciową grupę zabezpieczeń do podanej podsieci. Nie przesłaniaj przypisania sieciowej grupy zabezpieczeń lub ruch może ulec awarii.

Aby przenieść własną sieć wirtualną:

1. Pobierz usługę Id z subskrypcji dla aplikacji dostawcy zasobów usługi Service Fabric.

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

   Uwaga

   Upewnij się, że jesteś w prawidłowej subskrypcji, identyfikator podmiotu zabezpieczeń zmieni się, jeśli subskrypcja znajduje się w innej dzierżawie.

   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
   

   Zanotuj identyfikator poprzednich danych wyjściowych jako principalId do użycia w późniejszym kroku

   Nazwa definicji roli	Identyfikator definicji roli
   Współautor sieci	4d97b98b-1d4f-4787-a291-c67834d212e7

   Zanotuj Role definition name wartości właściwości i Role definition ID do użycia w późniejszym kroku

2. Dodaj przypisanie roli do aplikacji dostawcy zasobów usługi Service Fabric. Dodawanie przypisania roli jest akcją jednorazową. Rolę można dodać, uruchamiając następujące polecenia programu PowerShell lub konfigurując szablon usługi Azure Resource Manager (ARM), jak opisano poniżej.

   W poniższych krokach rozpoczynamy od istniejącej sieci wirtualnej o nazwie ExistingRG-vnet w grupie zasobów ExistingRG. Podsieć ma nazwę domyślną.

   Uzyskaj wymagane informacje z istniejącej sieci wirtualnej.

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

   Zwróć uwagę na następującą nazwę podsieci i Id wartość właściwości zwróconą z Subnets sekcji w odpowiedzi, której użyjesz w kolejnych krokach.

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

   Uruchom następujące polecenie programu PowerShell przy użyciu identyfikatora podmiotu zabezpieczeń, nazwy definicji roli z kroku 2 i zakresu Id przypisania uzyskanego powyżej:

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

   Możesz też dodać przypisanie roli przy użyciu szablonu usługi Azure Resource Manager (ARM) skonfigurowanego z odpowiednimi wartościami dla principalId, , vnetNameroleDefinitionIdi 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"
      }
   

   Uwaga

   Identyfikator VNetRoleAssignmentID musi być identyfikatorem GUID. Jeśli ponownie wdrożysz szablon wraz z tym przypisaniem roli, upewnij się, że identyfikator GUID jest taki sam jak pierwotnie używany. Zalecamy uruchomienie tego izolowanego lub usunięcie tego zasobu z szablonu klastra po wdrożeniu, ponieważ należy go utworzyć tylko raz.

   Oto pełny przykładowy szablon usługi Azure Resource Manager (ARM), który tworzy podsieć sieci wirtualnej i wykonuje przypisanie roli, którego można użyć w tym kroku.

3. subnetId Skonfiguruj właściwość wdrożenia klastra po skonfigurowaniu roli, jak pokazano poniżej:

• Wartość apiVersion zasobu zarządzanego klastra usługi Service Fabric powinna mieć wartość 2022-01-01 lub nowszą.

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

  Zobacz przykładowy szablon przykładowego klastra sieci wirtualnej bring your own lub dostosuj własny.

4. Wdróż skonfigurowany szablon klastra zarządzanego azure Resource Manager (ARM).

   W poniższym przykładzie utworzymy grupę zasobów o nazwie MyResourceGroup w westus i wdrożymy klaster z włączoną tą funkcją.

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

   W przypadku korzystania z własnej podsieci sieci wirtualnej publiczny punkt końcowy jest nadal tworzony i zarządzany przez dostawcę zasobów, ale w skonfigurowanej podsieci. Funkcja nie umożliwia określenia publicznego adresu IP/ponownego użycia statycznego adresu IP w Azure Load Balancer. Możesz połączyć własne Azure Load Balancer z tą funkcją lub samodzielnie, jeśli potrzebujesz tych lub innych scenariuszy modułu równoważenia obciążenia, które nie są natywnie obsługiwane.

Przynieś własne Azure Load Balancer

Klastry zarządzane tworzą publiczną usługa Load Balancer w warstwie Standardowa platformy Azure i w pełni kwalifikowaną nazwę domeny ze statycznym publicznym adresem IP dla typów węzłów podstawowych i pomocniczych. Korzystanie z własnego modułu równoważenia obciążenia umożliwia użycie istniejącego Azure Load Balancer dla typów węzłów pomocniczych zarówno dla ruchu przychodzącego, jak i wychodzącego. W przypadku korzystania z własnego Azure Load Balancer możesz wykonywać następujące czynności:

• Używanie wstępnie skonfigurowanego Load Balancer statycznego adresu IP dla ruchu prywatnego lub publicznego
• Mapuj Load Balancer na określony typ węzła
• Konfigurowanie reguł sieciowej grupy zabezpieczeń na typ węzła, ponieważ każdy typ węzła jest wdrażany we własnej podsieci
• Obsługa istniejących zasad i mechanizmów kontroli, które mogą być stosowane
• Konfigurowanie modułu równoważenia obciążenia tylko wewnętrznego i używanie domyślnego modułu równoważenia obciążenia dla ruchu zewnętrznego

Uwaga

W przypadku korzystania z usługi BYOVNET zasoby klastra zarządzanego zostaną wdrożone w jednej podsieci z jedną sieciową grupą zabezpieczeń niezależnie od dodatkowych skonfigurowanych modułów równoważenia obciążenia.

Uwaga

Nie można przełączyć się z domyślnego modułu równoważenia obciążenia na niestandardowy po wdrożeniu typu węzła, ale można zmodyfikować niestandardową konfigurację modułu równoważenia obciążenia po wdrożeniu, jeśli jest włączona.

Wymagania dotyczące funkcji

• Obsługiwane są typy Azure Load Balancer jednostek SKU w warstwie Podstawowa i Standardowa
• Musisz mieć skonfigurowane pule zaplecza i translatora adresów sieciowych w Azure Load Balancer
• Należy włączyć łączność wychodzącą przy użyciu udostępnionego publicznego modułu równoważenia obciążenia lub domyślnego publicznego modułu równoważenia obciążenia

Oto kilka przykładowych scenariuszy, w których klienci mogą używać następujących elementów:

W tym przykładzie klient chce kierować ruch przez istniejący Azure Load Balancer skonfigurowany przy użyciu istniejącego statycznego adresu IP do dwóch typów węzłów.

W tym przykładzie klient chce kierować ruch przez istniejące moduły równoważenia obciążenia platformy Azure, aby pomóc im zarządzać przepływem ruchu do aplikacji niezależnie, które działają w osobnych typach węzłów. Po skonfigurowaniu takiego przykładu każdy typ węzła będzie znajdować się za własną zarządzaną sieciową grupą zabezpieczeń.

W tym przykładzie klient chce kierować ruch przez istniejące wewnętrzne moduły równoważenia obciążenia platformy Azure. Ułatwia to zarządzanie przepływem ruchu do aplikacji niezależnie, które działają w osobnych typach węzłów. Po skonfigurowaniu takiego przykładu każdy typ węzła będzie znajdować się za własną zarządzaną sieciową grupą zabezpieczeń i użyć domyślnego modułu równoważenia obciążenia dla ruchu zewnętrznego.

Aby skonfigurować przy użyciu własnego modułu równoważenia obciążenia:

1. Pobierz usługę Id z subskrypcji dla aplikacji dostawcy zasobów usługi Service Fabric:

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

   Uwaga

   Upewnij się, że jesteś w prawidłowej subskrypcji, identyfikator podmiotu zabezpieczeń zmieni się, jeśli subskrypcja znajduje się w innej dzierżawie.

   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
   

   Zanotuj identyfikator poprzednich danych wyjściowych jako principalId do użycia w późniejszym kroku

   Nazwa definicji roli	Identyfikator definicji roli
   Współautor sieci	4d97b98b-1d4f-4787-a291-c67834d212e7

   Zanotuj Role definition name wartości właściwości i Role definition ID do użycia w późniejszym kroku

2. Dodaj przypisanie roli do aplikacji dostawcy zasobów usługi Service Fabric. Dodawanie przypisania roli jest akcją jednorazową. Rolę można dodać, uruchamiając następujące polecenia programu PowerShell lub konfigurując szablon usługi Azure Resource Manager (ARM), jak opisano poniżej.

   W poniższych krokach zaczniemy od istniejącego modułu równoważenia obciążenia o nazwie Existing-LoadBalancer1 w grupie zasobów Existing-RG.

   Uzyskaj wymagane Id informacje o właściwości z istniejącego Azure Load Balancer.

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

   Zwróć uwagę na następujące Id elementy, których użyjesz w następnym kroku:

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

   Uruchom następujące polecenie programu PowerShell przy użyciu identyfikatora podmiotu zabezpieczeń, nazwy definicji roli z kroku 2 i uzyskanego zakresu Id przypisania:

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

   Możesz też dodać przypisanie roli przy użyciu szablonu usługi Azure Resource Manager (ARM) skonfigurowanego z odpowiednimi wartościami dla principalIdelementu , 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"
      }
   

   Uwaga

   loadBalancerRoleAssignmentID musi być identyfikatorem GUID. Jeśli ponownie wdrożysz szablon wraz z tym przypisaniem roli, upewnij się, że identyfikator GUID jest taki sam jak pierwotnie używany. Zalecamy uruchomienie tego izolowanego lub usunięcie tego zasobu z szablonu klastra po wdrożeniu, ponieważ należy go utworzyć tylko raz.

   Zobacz ten przykładowy szablon , aby utworzyć publiczny moduł równoważenia obciążenia i przypisać rolę.

3. Skonfiguruj wymaganą łączność wychodzącą dla typu węzła. Należy skonfigurować publiczny moduł równoważenia obciążenia, aby zapewnić łączność wychodzącą lub użyć domyślnego publicznego modułu równoważenia obciążenia.

   Konfigurowanie outboundRules w celu skonfigurowania publicznego modułu równoważenia obciążenia w celu zapewnienia łączności wychodzącej Zobacz tworzenie modułu równoważenia obciążenia i przypisywanie przykładowego szablonu usługi Azure Resource Manager (ARM)

   LUB

   Aby skonfigurować typ węzła do używania domyślnego modułu równoważenia obciążenia, ustaw następujące ustawienia w szablonie:

   • Wartość apiVersion zasobu zarządzanego klastra usługi Service Fabric powinna mieć wartość 2022-01-01 lub nowszą.

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

4. Opcjonalnie skonfiguruj port aplikacji przychodzącej i powiązaną sondę na istniejącym Azure Load Balancer. Zobacz przykładowy szablon usługi Azure Resource Manager (ARM), aby zapoznać się z przykładowym szablonem usługi Azure Resource Manager (ARM).

5. Opcjonalnie skonfiguruj reguły sieciowej grupy zabezpieczeń klastra zarządzanego zastosowane do typu węzła, aby zezwolić na dowolny wymagany ruch skonfigurowany na Azure Load Balancer lub ruch zostanie zablokowany. Zobacz przykładowy szablon usługi Azure Resource Manager (ARM), aby zapoznać się z przykładową konfiguracją reguły sieciowej grupy zabezpieczeń dla ruchu przychodzącego. W szablonie wyszukaj networkSecurityRules właściwość .

6. Wdróż skonfigurowany szablon usługi ARM klastra zarządzanego Dla tego kroku użyjemy przykładowego szablonu usługi Azure Resource Manager (ARM) bring your own load balancer

   Poniżej zostanie utworzona grupa zasobów o nazwie MyResourceGroup in westus i wdróż klaster przy użyciu istniejącego modułu równoważenia obciążenia.

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

   Po wdrożeniu typ węzła pomocniczego jest skonfigurowany do używania określonego modułu równoważenia obciążenia dla ruchu przychodzącego i wychodzącego. Połączenie klienta usługi Service Fabric i punkty końcowe bramy będą nadal wskazywać publiczny system DNS podstawowego węzła klastra zarządzanego typu statycznego adresu IP.

Włączanie przyspieszonej sieci

Przyspieszona sieć umożliwia wirtualizację we/wy pojedynczego katalogu głównego (SR-IOV) na maszynę wirtualną zestawu skalowania maszyn wirtualnych, która jest podstawowym zasobem dla typów węzłów. Ta ścieżka o wysokiej wydajności pomija hosta ze ścieżki danych, co zmniejsza opóźnienia, zakłócenia i wykorzystanie procesora CPU dla najbardziej wymagających obciążeń sieciowych. Typy węzłów klastra zarządzanego usługi Service Fabric można aprowizować za pomocą przyspieszonej sieci na obsługiwanych jednostkach SKU maszyn wirtualnych. Aby uzyskać dodatkowe uwagi, należy odwołać się do tych ograniczeń i ograniczeń .

• Należy pamiętać, że przyspieszona sieć jest obsługiwana w przypadku większości rozmiarów wystąpień ogólnego przeznaczenia i zoptymalizowanych pod kątem obliczeń z co najmniej 2 procesorami wirtualnymi. W wystąpieniach obsługujących funkcję hyperthreading przyspieszona sieć jest obsługiwana w wystąpieniach maszyn wirtualnych z co najmniej 4 procesorami wirtualnymi.

Włącz przyspieszoną sieć, deklarując enableAcceleratedNetworking właściwość w szablonie Resource Manager w następujący sposób:

• Interfejs API zasobów zarządzanego klastra usługi Service Fabric powinien mieć wartość 2022-01-01 lub nowszą.

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

Aby włączyć przyspieszoną sieć w istniejącym klastrze usługi Service Fabric, należy najpierw skalować klaster usługi Service Fabric w poziomie, dodając nowy typ węzła i wykonując następujące czynności:

1. Aprowizowanie typu węzła z włączoną przyspieszoną siecią
2. Migrowanie usług i ich stanu do typu aprowizowanego węzła z włączoną przyspieszoną siecią

Aby włączyć przyspieszoną sieć w istniejącym klastrze, wymagana jest infrastruktura skalowania w poziomie, ponieważ włączenie przyspieszonej sieci spowodowałoby przestój, ponieważ wymaga zatrzymania i cofnięcia przydziału wszystkich maszyn wirtualnych w zestawie dostępności przed włączeniem przyspieszonej sieci na dowolnej istniejącej karcie sieciowej.

Konfigurowanie podsieci pomocniczych

Podsieci pomocnicze zapewniają możliwość tworzenia dodatkowych podsieci zarządzanych bez typu węzła dla scenariuszy pomocniczych, takich jak usługa Private Link i hosty bastionu.

Skonfiguruj podsieci pomocnicze, deklarując auxiliarySubnets właściwość i wymagane parametry w szablonie Resource Manager w następujący sposób:

• Interfejs API zasobów zarządzanego klastra usługi Service Fabric powinien mieć wartość 2022-01-01 lub nowszą.

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

Zobacz pełną listę dostępnych parametrów

Następne kroki

Omówienie opcji konfiguracji klastra zarządzanego usługi Service Fabric