Udostępnij za pośrednictwem

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

  • Artykuł

Klastry zarządzane usługi Service Fabric są tworzone przy użyciu domyślnej konfiguracji sieci. Ta konfiguracja składa się z usługi Azure Load Balancer z publicznym adresem IP, siecią wirtualną z jedną przydzieloną 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 opisano sposób modyfikowania następujących opcji konfiguracji sieci i nie tylko:

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 dla 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, aby konfiguracje były szybkie i łatwe. Te reguły można zastąpić, dodając niestandardowe reguły sieciowej grupy zabezpieczeń w zakresie priorytetu 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 ramach zasobu 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ń. Na 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": [
      "..."
    ]
  }
}

Domyślne i opcjonalne reguły ClientConnection i HttpGatewayConnection

Reguła sieciowej grupy zabezpieczeń: SFMC_AllowServiceFabricGatewayToSFRP

Zostanie dodana domyślna reguła sieciowej grupy zabezpieczeń umożliwiająca dostawcy zasobów usługi Service Fabric dostęp do klientaConnectionPort klastra i httpGatewayConnectionPort. Ta reguła umożliwia dostęp do portów za pośrednictwem tagu ServiceFabricusługi .

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 uzyskiwanie dostępu do rozwiązania SFX, łączenie się 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 protokołu RDP można otworzyć z Internetu, 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 ruchu przychodzącego dla każdego wystąpienia w typie węzła. Aby znaleźć mapowania portów umożliwiające dotarcie do określonych wystąpień (węzłów klastra), wykonaj poniższe kroki:

Za pomocą witryny Azure Portal znajdź klaster zarządzany utworzony dla reguł nat dla ruchu przychodzącego 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 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 frontonu przychodzącego do docelowego mapowania portów 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:

    Reguły translatora adresów sieciowych dla ruchu przychodzącego

    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 chcesz korzystać z protokołu RDP, musisz oddzielnie skonfigurować pulę translatora adresów sieciowych, 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 funkcji Podłączanie pulpitu zdalnego do łączenia się z węzłem aplikacji (wystąpienie 0) w klastrze systemu Windows:

Podłączanie pulpitu zdalnego

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 skonfigurowanego w sekcji "loadBalancingRules" we właściwościach 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. Na 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ą między regionami 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 przypadku typów 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 tego artykułu , 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 zwraca 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 domyślnie nie włączają protokołu IPv6. Ta funkcja umożliwia pełne korzystanie z funkcji IPv4/IPv6 z frontonu usługi 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ń mają 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.

  • Wersja interfejsu API zasobów klastra zarządzanego usługi Service Fabric powinna 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 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 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

    Po wdrożeniu klastry sieci wirtualnej i zasoby będą dwustosowe. W związku z tym moduł równoważenia obciążenia frontonu klastrów ma unikatowy adres DNS utworzony na przykład skojarzony mycluster-ipv6.southcentralus.cloudapp.azure.com z publicznym adresem IPv6 w usłudze Azure Load Balancer i prywatnym adresami 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 wdraża 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 możesz również w razie potrzeby przenieść własny moduł 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ń ani ruchu 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 odpowiedniej 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 to jednorazowa akcja. Rolę można dodać, uruchamiając następujące polecenia programu PowerShell lub konfigurując szablon usługi Azure Resource Manager (ARM), zgodnie z poniższym opisem.

    W poniższych krokach zaczniemy 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óra zostanie użyta 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, , roleDefinitionIdvnetNamei 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 ten, który pierwotnie był 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:

  • Wersja interfejsu API zasobów klastra zarządzanego 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.

  1. Wdróż skonfigurowany szablon klastra zarządzanego usługi 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. Ta funkcja nie umożliwia określenia publicznego adresu IP/ponownego użycia statycznego adresu IP w usłudze Azure Load Balancer. Możesz połączyć własną usługę 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.

    Tworzymy klaster, a sieciowa grupa zabezpieczeń jest tworzona w zarządzanej grupie zasobów dla domyślnej podsieci na poziomie klastra. Po utworzeniu typu węzła jest on umieszczany w tej podsieci i automatycznie dziedziczy reguły sieciowej grupy zabezpieczeń, chyba że używasz podsieci na poziomie węzła.

    Usługa Bring your own virtual network obsługuje również podsieci na poziomie węzła, które umożliwiają umieszczanie typów węzłów w oddzielnych podsieciach, zapewniając elastyczność różnych konfiguracji sieci i konfiguracji.

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

    Aby użyć podsieci na poziomie typu węzła, określ "useCustomVnet": true w definicji klastra zarządzanego. Gdy "useCustomVnet" jest ustawiona wartość true, domyślna podsieć klastra nie jest tworzona. W przypadku korzystania z podsieci na poziomie typu węzła subnetId staje się wymaganą właściwością w definicji typu węzła.

    Ważne

    W przypadku korzystania z podsieci na poziomie typu węzła należy przypisać sieciową grupę zabezpieczeń do podsieci typu węzła przed utworzeniem typu węzła. Sieciowa grupa zabezpieczeń musi zawierać wymaganą regułę ruchu przychodzącego SFMC_AllowServiceFabricGatewayToSFRP lub tworzenie typu węzła kończy się niepowodzeniem.

Korzystanie z własnego modułu równoważenia obciążenia platformy Azure

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 zarówno dla typów węzłów podstawowych, jak i pomocniczych. Użycie własnego modułu równoważenia obciążenia umożliwia użycie istniejącej usługi 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łasnej usługi Azure Load Balancer możesz wykonywać następujące czynności:

  • Używanie wstępnie skonfigurowanego statycznego adresu IP usługi Load Balancer dla ruchu prywatnego lub publicznego
  • Mapuj moduł równoważenia obciążenia 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 kontrolek, które mogą istnieć
  • 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ługiwany jest typ usługi Azure Load Balancer w warstwie Standardowa
  • Musisz mieć skonfigurowane pule zaplecza i translatora adresów sieciowych w usłudze 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, których klienci mogą używać w następujących przypadkach:

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

Używanie własnego modułu równoważenia obciążenia — przykład 1

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. W przypadku konfiguracji takiej jak w tym przykładzie każdy typ węzła będzie znajdować się za własną zarządzaną sieciową grupą zabezpieczeń.

Przynieś własny moduł równoważenia obciążenia — przykład 2

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. W przypadku konfiguracji takiej jak w tym przykładzie każdy typ węzła będzie znajdować się za własną zarządzaną sieciową grupą zabezpieczeń i używa domyślnego modułu równoważenia obciążenia dla ruchu zewnętrznego.

Przykład 3 modułu równoważenia obciążenia

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 odpowiedniej 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 to jednorazowa akcja. Rolę można dodać, uruchamiając następujące polecenia programu PowerShell lub konfigurując szablon usługi Azure Resource Manager (ARM), zgodnie z poniższym opisem.

    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ącej usługi 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 właśnie 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 ten, który pierwotnie był 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 konfigurowania 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:

    • Wersja interfejsu API zasobów klastra zarządzanego 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ę w istniejącej usłudze Azure Load Balancer. Zobacz przykładowy szablon usługi Azure Resource Manager (ARM) bring your own load balancer

  5. Opcjonalnie skonfiguruj reguły sieciowej grupy zabezpieczeń klastra zarządzanego zastosowane do typu węzła, aby zezwolić na dowolny wymagany ruch skonfigurowany w usłudze 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 arm klastra zarządzanego Dla tego kroku użyjemy przykładowego szablonu usługi Azure Resource Manager (ARM) bring your own load balancer

    Poniższe elementy spowodują utworzenie grupy zasobów o nazwie MyResourceGroup w westus systemie i wdrożenie klastra 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ć przy użyciu przyspieszonej sieci w obsługiwanych jednostkach SKU maszyn wirtualnych. Aby uzyskać dodatkowe informacje, należy odwołać się do tych ograniczeń i ograniczeń .

  • Należy pamiętać, że przyspieszona sieć jest obsługiwana w większości rozmiarów wystąpień ogólnego przeznaczenia i zoptymalizowanych pod kątem obliczeń z co najmniej 2 procesorami wirtualnymi. W przypadku wystąpień 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 usługi Resource Manager w następujący sposób:

  • Wersja interfejsu API zasobów klastra zarządzanego usługi Service Fabric powinna 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ą

Skalowanie infrastruktury w poziomie jest wymagane do włączenia przyspieszonej sieci w istniejącym klastrze, ponieważ włączenie przyspieszonej sieci spowodowałoby przestój, ponieważ wymaga to 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 umożliwiają tworzenie 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 usługi Resource Manager w następujący sposób:

  • Wersja interfejsu API zasobów klastra zarządzanego usługi Service Fabric powinna 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 opcjikonfiguracji klastra zarządzanego usługi Service Fabric