Migrowanie klastra usługi Service Fabric do obsługi strefy dostępności

W tym przewodniku opisano sposób migrowania klastrów usługi Service Fabric z obsługi stref niedostępnych do obsługi dostępności. Przeprowadzimy Cię przez różne opcje migracji. Klaster usługi Service Fabric rozproszony w różnych strefach dostępności zapewnia wysoką dostępność stanu klastra.

Można migrować zarówno zarządzane, jak i nienarządzane klastry. Oba te elementy zostały omówione w tym artykule.

W przypadku klastrów niezarządzanych omawiamy dwa różne scenariusze:

• Migrowanie klastra za pomocą modułu równoważenia obciążenia jednostki SKU w warstwie Standardowa i zasobu ADRESU IP. Ta konfiguracja obsługuje strefy dostępności bez konieczności tworzenia nowych zasobów.
• Migrowanie klastra z podstawowym modułem równoważenia obciążenia jednostki SKU i zasobem IP. Ta konfiguracja nie obsługuje stref dostępności i wymaga utworzenia nowych zasobów.

Zapoznaj się z odpowiednimi sekcjami w poszczególnych nagłówkach dla scenariusza klastra usługi Service Fabric.

Uwaga

Korzyści wynikające z połączenia typu węzła podstawowego w strefach dostępności są widoczne tylko dla trzech stref, a nie tylko dwóch. Dotyczy to zarówno klastrów zarządzanych, jak i nie zarządzanych.

Przykładowe szablony są dostępne w szablonach między strefami dostępności usługi Service Fabric.

Wymagania wstępne

Klastry zarządzane usługi Service Fabric

Wymagana liczba rdzeni:

• Klaster jednostki SKU w warstwie Standardowa.
• Trzy strefy dostępności w regionie.

Zalecane:

• Jednostka SKU klastra musi być w warstwie Standardowa.
• Typ węzła podstawowego powinien mieć co najmniej dziewięć węzłów w celu uzyskania najlepszej odporności, ale obsługuje minimalną liczbę sześciu.
• Typy węzłów pomocniczych powinny mieć co najmniej sześć węzłów w celu uzyskania najlepszej odporności, ale obsługuje minimalną liczbę trzech.

Klastry nienależące do usługi Service Fabric

Wymagane: N/A.

Zalecane:

• Poziom niezawodności klastra ustawiony na Platinumwartość .
• Pojedynczy zasób publicznego adresu IP korzystający z jednostki SKU w warstwie Standardowa.
• Pojedynczy zasób modułu równoważenia obciążenia przy użyciu jednostki SKU w warstwie Standardowa.
• Sieciowa grupa zabezpieczeń, do której odwołuje się podsieć, w której wdrażasz zestawy skalowania maszyn wirtualnych.

Istniejący moduł równoważenia obciążenia jednostki SKU w warstwie Standardowa i zasób IP

W tym scenariuszu nie ma żadnych wymagań wstępnych, ponieważ przyjęto założenie, że masz istniejące wymagane zasoby.

Podstawowy moduł równoważenia obciążenia jednostki SKU i zasób IP

• Nowy moduł równoważenia obciążenia przy użyciu jednostki SKU w warstwie Standardowa różni się od istniejącego modułu równoważenia obciążenia jednostki SKU w warstwie Podstawowa.
• Nowy zasób IP korzystający z jednostki SKU w warstwie Standardowa różni się od istniejącego zasobu adresu IP jednostki SKU w warstwie Podstawowa.

Uwaga

Nie można uaktualnić istniejących zasobów z jednostki SKU w warstwie Podstawowa do jednostki SKU w warstwie Standardowa, więc wymagane są nowe zasoby.

Wymagania dotyczące przestojów

Klaster zarządzany usługi Service Fabric

Migracja do odpornej na strefy konfiguracji może spowodować krótką utratę łączności zewnętrznej za pośrednictwem modułu równoważenia obciążenia, ale nie wpłynie to na kondycję klastra. Utrata łączności zewnętrznej występuje, gdy należy utworzyć nowy publiczny adres IP w celu zapewnienia odporności sieci na awarie strefy. Zaplanuj migrację odpowiednio.

Klaster niezarządzany usługi Service Fabric

Przestój w przypadku migrowania klastrów nienależących do usługi Service Fabric różni się w zależności od liczby maszyn wirtualnych i domen uaktualniania w klastrze. Identyfikatory UD to logiczne grupy maszyn wirtualnych, które określają kolejność wypychania uaktualnień do maszyn wirtualnych w klastrze. Przestój ma również wpływ na tryb uaktualniania klastra, który obsługuje sposób przetwarzania zadań uaktualniania dla identyfikatorów UD w klastrze. Właściwość sfZonalUpgradeMode , która kontroluje tryb uaktualniania, jest bardziej szczegółowo omówiona w poniższych sekcjach.

Migracja dla klastrów zarządzanych usługi Service Fabric

Wykonaj kroki opisane w artykule Migrate Service Fabric managed cluster to zone resilient (Migrowanie klastra zarządzanego usługi Service Fabric do strefy odpornej na awarie).

Opcje migracji dla klastrów niezarządzanych usługi Service Fabric

Opcja migracji 1: włączanie wielu Strefy dostępności w jednym zestawie skalowania maszyn wirtualnych

Kiedy należy użyć tej opcji

To rozwiązanie pozwala użytkownikom obejmować trzy Strefy dostępności w tym samym typie węzła. Jest to zalecana topologia wdrożenia, ponieważ umożliwia wdrażanie w różnych strefach dostępności przy zachowaniu pojedynczego zestawu skalowania maszyn wirtualnych.

Pełny przykładowy szablon jest dostępny w witrynie GitHub.

Należy użyć tej opcji, jeśli masz istniejący klaster usługi Service Fabric, który nie jest zarządzany z modułem równoważenia obciążenia jednostki SKU w warstwie Standardowa i zasobami IP, które chcesz zmigrować. Jeśli istniejący klaster nienależące do zarządzania ma zasoby jednostki SKU w warstwie Podstawowa, powinna zostać wyświetlona poniżej opcja Migracja jednostki SKU w warstwie Podstawowa.

Jak przeprowadzić migrację klastra usługi Service Fabric niezarządzanego przy użyciu istniejącego modułu równoważenia obciążenia jednostki SKU w warstwie Standardowa i zasobów adresów IP

Aby włączyć strefy w zestawie skalowania maszyn wirtualnych:

Uwzględnij następujące trzy wartości w zasobie zestawu skalowania maszyn wirtualnych:

• Pierwszą wartością zones jest właściwość, która określa Strefy dostępności, które znajdują się w zestawie skalowania maszyn wirtualnych.

• Drugą wartością singlePlacementGroup jest właściwość , która musi być ustawiona na true. Zestaw skalowania obejmujący trzy Strefy dostępności może skalować do 300 maszyn wirtualnych nawet przy użyciu polecenia singlePlacementGroup = true.

• Trzecia wartość to zoneBalance, która zapewnia ścisłe równoważenie strefy. Ta wartość powinna mieć wartość true. Gwarantuje to, że dystrybucje maszyn wirtualnych między strefami nie są niezrównoważone, co oznacza, że gdy jedna strefa ulegnie awarii, dwie pozostałe strefy mają wystarczającą liczbę maszyn wirtualnych, aby utrzymać działanie klastra.

  Klaster z niezrównoważonej dystrybucji maszyn wirtualnych może nie przetrwać scenariusza w dół strefy, ponieważ ta strefa może mieć większość maszyn wirtualnych. Dystrybucja niezrównoważonej maszyny wirtualnej między strefami prowadzi również do problemów z umieszczaniem usług i blokowaniem aktualizacji infrastruktury. Przeczytaj więcej o strefieBalancing.

Nie trzeba konfigurować FaultDomain przesłonięć i UpgradeDomain .

{
  "apiVersion": "2018-10-01",
  "type": "Microsoft.Compute/virtualMachineScaleSets",
  "name": "[parameters('vmNodeType1Name')]",
  "location": "[parameters('computeLocation')]",
  "zones": [ "1", "2", "3" ],
  "properties": {
    "singlePlacementGroup": true,
    "zoneBalance": true
  }
}

Uwaga

• Klastry usługi Service Fabric powinny mieć co najmniej jeden typ węzła podstawowego. Poziom trwałości typów węzłów podstawowych powinien być srebrny lub wyższy.
• Strefę dostępności obejmującą zestaw skalowania maszyn wirtualnych należy skonfigurować z co najmniej trzema Strefy dostępności, niezależnie od poziomu trwałości.
• Strefa dostępności obejmująca zestaw skalowania maszyn wirtualnych ze srebrem lub większą trwałością powinna mieć co najmniej 15 maszyn wirtualnych.
• Strefa dostępności obejmująca zestaw skalowania maszyn wirtualnych z trwałością z brązu powinna mieć co najmniej sześć maszyn wirtualnych.

Włączanie obsługi wielu stref w typie węzła usługi Service Fabric

Aby obsługiwać wiele stref dostępności, należy włączyć typ węzła usługi Service Fabric.

• Pierwsza wartość to multipleAvailabilityZones, która powinna być ustawiona na true dla typu węzła.

• Druga wartość to sfZonalUpgradeMode i jest opcjonalna. Tej właściwości nie można zmodyfikować, jeśli typ węzła z wieloma strefami dostępności jest już obecny w klastrze. Ta właściwość steruje logicznym grupowaniem maszyn wirtualnych w identyfikatorach UD.

  • Jeśli ta wartość jest ustawiona na Parallel: Maszyny wirtualne w ramach typu węzła są pogrupowane w identyfikatory UD i ignorują informacje o strefie w pięciu identyfikatorach UD. To ustawienie powoduje uaktualnienie identyfikatorów UD we wszystkich strefach w tym samym czasie. Mimo że ten tryb wdrażania jest szybszy w przypadku uaktualnień, nie zalecamy go, ponieważ jest on zgodny z wytycznymi SDP, które stanowią, że aktualizacje powinny być stosowane do jednej strefy jednocześnie.

  • Jeśli ta wartość zostanie pominięta lub ustawiona na Hierarchical: maszyny wirtualne są pogrupowane w celu odzwierciedlenia rozkładu strefowego w maksymalnie 15 identyfikatorach UD. Każda z trzech stref ma pięć identyfikatorów UD. Dzięki temu strefy są aktualizowane pojedynczo, przechodząc do następnej strefy dopiero po ukończeniu pięciu identyfikatorów UD w pierwszej strefie. Proces aktualizacji jest bezpieczniejszy dla klastra i aplikacji użytkownika.

  Ta właściwość definiuje tylko zachowanie uaktualniania dla aplikacji usługi Service Fabric i uaktualnień kodu. Podstawowe uaktualnienia zestawu skalowania maszyn wirtualnych są nadal równoległe we wszystkich Strefy dostępności. Ta właściwość nie ma wpływu na dystrybucję trasy zdefiniowanej przez użytkownika dla typów węzłów, które nie mają włączonej wielu stref.

• Trzecia wartość to vmssZonalUpgradeMode, jest opcjonalna i może być aktualizowana w dowolnym momencie. Ta właściwość definiuje schemat uaktualniania zestawu skalowania maszyn wirtualnych, który ma być wykonywane równolegle lub sekwencyjnie w Strefy dostępności.

  • Jeśli ta wartość jest ustawiona na Parallel: Wszystkie aktualizacje zestawu skalowania są wykonywane równolegle we wszystkich strefach. Ten tryb wdrażania jest szybszy w przypadku uaktualnień, dlatego nie zalecamy go, ponieważ jest zgodny z wytycznymi SDP, które stanowią, że aktualizacje powinny być stosowane do jednej strefy naraz.
  • Jeśli ta wartość zostanie pominięta lub ustawiona na Hierarchicalwartość : Gwarantuje to, że strefy są aktualizowane pojedynczo, przechodząc do następnej strefy dopiero po ukończeniu pięciu identyfikatorów UD w pierwszej strefie. Ten proces aktualizacji jest bezpieczniejszy dla klastra i aplikacji użytkownika.

Ważne

Wersja interfejsu API zasobów klastra usługi Service Fabric powinna mieć wartość 2020-12-01-preview lub nowsza.

Wersja kodu klastra powinna być co najmniej 8.1.321 lub nowsza.

{
  "apiVersion": "2020-12-01-preview",
  "type": "Microsoft.ServiceFabric/clusters",
  "name": "[parameters('clusterName')]",
  "location": "[parameters('clusterLocation')]",
  "dependsOn": [
    "[concat('Microsoft.Storage/storageAccounts/', parameters('supportLogStorageAccountName'))]"
  ],
  "properties": {
    "reliabilityLevel": "Platinum",
    "sfZonalUpgradeMode": "Hierarchical",
    "vmssZonalUpgradeMode": "Parallel",
    "nodeTypes": [
      {
        "name": "[parameters('vmNodeType0Name')]",
        "multipleAvailabilityZones": true
      }
    ]
  }
}

Uwaga

• Zasoby publicznego adresu IP i modułu równoważenia obciążenia powinny używać jednostki SKU w warstwie Standardowa opisanej wcześniej w artykule.
• multipleAvailabilityZones Właściwość typu węzła można zdefiniować tylko po utworzeniu typu węzła i nie można jej później modyfikować. Nie można skonfigurować istniejących typów węzłów za pomocą tej właściwości.
• Jeśli sfZonalUpgradeMode pominięto lub ustawiono wartość Hierarchical, wdrożenia klastra i aplikacji będą wolniejsze, ponieważ w klastrze istnieje więcej domen uaktualnienia. Ważne jest, aby prawidłowo dostosować limity czasu zasad uaktualniania, aby uwzględnić czas uaktualniania wymagany dla 15 domen uaktualnienia. Zasady uaktualniania aplikacji i klastra powinny zostać zaktualizowane, aby upewnić się, że wdrożenie nie przekracza limitu czasu wdrożenia usługi Azure Resource Service w wysokości 12 godzin. Oznacza to, że wdrożenie nie powinno trwać dłużej niż 12 godzin dla 15 identyfikatorów UD (czyli nie powinno trwać więcej niż 40 minut dla każdego użytkownika).
• Ustaw poziom niezawodności klastra, aby Platinum upewnić się, że klaster przetrwa scenariusz z jedną strefą w dół.
• Uaktualnianie elementu DurabilityLevel dla typu węzła za pomocą funkcji multipleAvailabilityZones nie jest obsługiwane. Utwórz nowy typ węzła z większą trwałością.
• Usługa SF obsługuje tylko 3 strefy dostępności. Każda wyższa liczba nie jest obecnie obsługiwana.

Napiwek

Zalecamy ustawienie sfZonalUpgradeMode wartości Hierarchical lub pominięcie jej. Wdrożenie będzie zgodne z rozkładem strefowym maszyn wirtualnych i wpłynie na mniejszą ilość replik lub wystąpień, co czyni je bezpieczniejszymi. Ustaw sfZonalUpgradeMode wartość , jeśli szybkość Parallel wdrożenia jest priorytetem lub tylko bezstanowe obciążenia są uruchamiane w typie węzła z wieloma Strefy dostępności. Powoduje to równoległe przejście przez użytkownika we wszystkich Strefy dostępności.

Migrowanie do typu węzła z wieloma Strefy dostępności

W przypadku wszystkich scenariuszy migracji należy dodać nowy typ węzła, który obsługuje wiele Strefy dostępności. Nie można migrować istniejącego typu węzła do obsługi wielu stref. Artykuł Skalowanie w górę podstawowego typu węzła klastra usługi Service Fabric zawiera szczegółowe kroki dodawania nowego typu węzła i innych zasobów wymaganych dla nowego typu węzła, takich jak adres IP i zasoby modułu równoważenia obciążenia. W tym artykule opisano również sposób wycofywania istniejącego typu węzła po dodaniu nowego typu węzła z wieloma Strefy dostępności do klastra.

• Migracja z typu węzła korzystającego z podstawowego modułu równoważenia obciążenia i zasobów IP: ten proces został już opisany w podsieci poniżej dla rozwiązania z jednym typem węzła na strefę dostępności.

  W przypadku nowego typu węzła jedyną różnicą jest to, że istnieje tylko jeden zestaw skalowania maszyn wirtualnych i jeden typ węzła dla wszystkich Strefy dostępności zamiast jednego na strefę dostępności.

• Migracja z typu węzła korzystającego z modułu równoważenia obciążenia jednostki SKU w warstwie Standardowa i zasobów IP z sieciową grupą zabezpieczeń: wykonaj tę samą procedurę opisaną wcześniej. Nie ma jednak potrzeby dodawania nowych zasobów modułu równoważenia obciążenia, adresu IP i sieciowej grupy zabezpieczeń. Te same zasoby można ponownie użyć w nowym typie węzła.

Jeśli napotkasz jakiekolwiek problemy, skontaktuj się z pomocą techniczną w celu uzyskania pomocy.

Opcja migracji 2: wdrażanie stref przez przypięcie jednego zestawu skalowania maszyn wirtualnych do każdej strefy

Kiedy należy użyć tej opcji

Jest to teraz ogólnie dostępna konfiguracja.

Aby obejmować klaster usługi Service Fabric w Strefy dostępności, należy utworzyć podstawowy typ węzła w każdej strefie dostępności obsługiwanej przez region. Powoduje to równomierne rozłożenie węzłów inicjowania w każdym z typów węzłów podstawowych.

Zalecana topologia typu węzła podstawowego wymaga następującej:

• Trzy typy węzłów oznaczone jako podstawowe
  • Każdy typ węzła powinien być mapowany na własny zestaw skalowania maszyn wirtualnych znajdujący się w innej strefie.
  • Każdy zestaw skalowania maszyn wirtualnych powinien mieć co najmniej pięć węzłów (trwałość srebra).

Należy użyć tej opcji, jeśli masz istniejący klaster usługi Service Fabric, który nie jest zarządzany z modułem równoważenia obciążenia jednostki SKU w warstwie Standardowa i zasobami IP, które chcesz zmigrować. Jeśli istniejący klaster nienależące do zarządzania ma zasoby jednostki SKU w warstwie Podstawowa, powinna zostać wyświetlona poniżej opcja Migracja jednostki SKU w warstwie Podstawowa.

Jak przeprowadzić migrację klastra usługi Service Fabric niezarządzanego przy użyciu istniejącego modułu równoważenia obciążenia jednostki SKU w warstwie Standardowa i zasobów adresów IP

Włączanie stref w zestawie skalowania maszyn wirtualnych

Aby włączyć strefę w zestawie skalowania maszyn wirtualnych, uwzględnij następujące trzy wartości w zasobie zestawu skalowania maszyn wirtualnych:

• Pierwszą wartością zones jest właściwość, która określa strefę dostępności wdrożony w zestawie skalowania maszyn wirtualnych.
• Drugą wartością singlePlacementGroup jest właściwość , która musi być ustawiona na true.
• Trzecia wartość to faultDomainOverride właściwość w rozszerzeniu zestawu skalowania maszyn wirtualnych usługi Service Fabric. Ta właściwość powinna zawierać tylko strefę, w której zostanie umieszczony ten zestaw skalowania maszyn wirtualnych. Przykład: "faultDomainOverride": "az1". Wszystkie zasoby zestawu skalowania maszyn wirtualnych muszą być umieszczone w tym samym regionie, ponieważ klastry usługi Azure Service Fabric nie obsługują wielu regionów.

{
  "apiVersion": "2018-10-01",
  "type": "Microsoft.Compute/virtualMachineScaleSets",
  "name": "[parameters('vmNodeType1Name')]",
  "location": "[parameters('computeLocation')]",
  "zones": [
    "1"
  ],
  "properties": {
    "singlePlacementGroup": true
  },
  "virtualMachineProfile": {
    "extensionProfile": {
      "extensions": [
        {
          "name": "[concat(parameters('vmNodeType1Name'),'_ServiceFabricNode')]",
          "properties": {
            "type": "ServiceFabricNode",
            "autoUpgradeMinorVersion": false,
            "publisher": "Microsoft.Azure.ServiceFabric",
            "settings": {
              "clusterEndpoint": "[reference(parameters('clusterName')).clusterEndpoint]",
              "nodeTypeRef": "[parameters('vmNodeType1Name')]",
              "dataPath": "D:\\\\SvcFab",
              "durabilityLevel": "Silver",
              "certificate": {
                "thumbprint": "[parameters('certificateThumbprint')]",
                "x509StoreName": "[parameters('certificateStoreValue')]"
              },
              "systemLogUploadSettings": {
                "Enabled": true
              },
              "faultDomainOverride": "az1"
            },
            "typeHandlerVersion": "1.0"
          }
        }
      ]
    }
  }
}

Włączanie wielu podstawowych typów węzłów w zasobie klastra usługi Service Fabric

Aby ustawić co najmniej jeden typ węzła jako podstawowy w zasobie klastra, ustaw isPrimary właściwość na true. Podczas wdrażania klastra usługi Service Fabric w Strefy dostępności powinny istnieć trzy typy węzłów w różnych strefach.

{
  "reliabilityLevel": "Platinum",
  "nodeTypes": [
    {
      "name": "[parameters('vmNodeType0Name')]",
      "applicationPorts": {
        "endPort": "[parameters('nt0applicationEndPort')]",
        "startPort": "[parameters('nt0applicationStartPort')]"
      },
      "clientConnectionEndpointPort": "[parameters('nt0fabricTcpGatewayPort')]",
      "durabilityLevel": "Silver",
      "ephemeralPorts": {
        "endPort": "[parameters('nt0ephemeralEndPort')]",
        "startPort": "[parameters('nt0ephemeralStartPort')]"
      },
      "httpGatewayEndpointPort": "[parameters('nt0fabricHttpGatewayPort')]",
      "isPrimary": true,
      "vmInstanceCount": "[parameters('nt0InstanceCount')]"
    },
    {
      "name": "[parameters('vmNodeType1Name')]",
      "applicationPorts": {
        "endPort": "[parameters('nt1applicationEndPort')]",
        "startPort": "[parameters('nt1applicationStartPort')]"
      },
      "clientConnectionEndpointPort": "[parameters('nt1fabricTcpGatewayPort')]",
      "durabilityLevel": "Silver",
      "ephemeralPorts": {
        "endPort": "[parameters('nt1ephemeralEndPort')]",
        "startPort": "[parameters('nt1ephemeralStartPort')]"
      },
      "httpGatewayEndpointPort": "[parameters('nt1fabricHttpGatewayPort')]",
      "isPrimary": true,
      "vmInstanceCount": "[parameters('nt1InstanceCount')]"
    },
    {
      "name": "[parameters('vmNodeType2Name')]",
      "applicationPorts": {
        "endPort": "[parameters('nt2applicationEndPort')]",
        "startPort": "[parameters('nt2applicationStartPort')]"
      },
      "clientConnectionEndpointPort": "[parameters('nt2fabricTcpGatewayPort')]",
      "durabilityLevel": "Silver",
      "ephemeralPorts": {
        "endPort": "[parameters('nt2ephemeralEndPort')]",
        "startPort": "[parameters('nt2ephemeralStartPort')]"
      },
      "httpGatewayEndpointPort": "[parameters('nt2fabricHttpGatewayPort')]",
      "isPrimary": true,
      "vmInstanceCount": "[parameters('nt2InstanceCount')]"
    }
  ]
}

Jeśli napotkasz jakiekolwiek problemy, skontaktuj się z pomocą techniczną w celu uzyskania pomocy.

Opcja migracji: klaster nienależące do usługi Service Fabric z modułem równoważenia obciążenia jednostki SKU w warstwie Podstawowa i zasobami ip

Kiedy należy użyć tej opcji

Należy użyć tej opcji, jeśli masz istniejący klaster nienależące do zarządzania usługą Service Fabric z modułem równoważenia obciążenia jednostki SKU w warstwie Podstawowa i zasobami IP, które chcesz zmigrować. Jeśli istniejący klaster niezarządzany ma zasoby jednostki SKU w warstwie Standardowa, powinny zostać wyświetlone powyższe opcje migracji. Jeśli nie utworzono jeszcze klastra niezarządzanego, ale wiesz, że chcesz, aby był on włączony za pomocą modułu AZ, utwórz go przy użyciu zasobów jednostki SKU w warstwie Standardowa.

Jak przeprowadzić migrację klastra usługi Service Fabric niezarządzanego przy użyciu podstawowego modułu równoważenia obciążenia jednostki SKU i zasobów adresów IP

Aby przeprowadzić migrację klastra korzystającego z modułu równoważenia obciążenia i adresu IP z podstawową jednostkę SKU, należy najpierw utworzyć całkowicie nowy zasób modułu równoważenia obciążenia i adresu IP przy użyciu standardowej jednostki SKU. Nie można zaktualizować tych zasobów.

Odwołuj się do nowego modułu równoważenia obciążenia i adresu IP w nowych typach węzłów strefy dostępności, których chcesz użyć. W poprzednim przykładzie dodano trzy nowe zasoby zestawu skalowania maszyn wirtualnych w strefach 1, 2 i 3. Te zestawy skalowania maszyn wirtualnych odwołują się do nowo utworzonego modułu równoważenia obciążenia i adresu IP i są oznaczone jako podstawowe typy węzłów w zasobie klastra usługi Service Fabric.

1. Aby rozpocząć, dodaj nowe zasoby do istniejącego szablonu usługi Azure Resource Manager. Te zasoby obejmują:

   • Zasób publicznego adresu IP korzystający z jednostki SKU w warstwie Standardowa
   • Zasób modułu równoważenia obciążenia przy użyciu jednostki SKU w warstwie Standardowa
   • Sieciowa grupa zabezpieczeń, do której odwołuje się podsieć, w której wdrażasz zestawy skalowania maszyn wirtualnych
   • Trzy typy węzłów oznaczone jako podstawowe
     • Każdy typ węzła powinien być mapowany na własny zestaw skalowania maszyn wirtualnych znajdujący się w innej strefie.
     • Każdy zestaw skalowania maszyn wirtualnych powinien mieć co najmniej pięć węzłów (trwałość srebra).

   Przykład tych zasobów można znaleźć w przykładowym szablonie.

   New-AzureRmResourceGroupDeployment `
       -ResourceGroupName $ResourceGroupName `
       -TemplateFile $Template `
       -TemplateParameterFile $Parameters
   

2. Po zakończeniu wdrażania zasobów można wyłączyć węzły w typie węzła podstawowego z oryginalnego klastra. Gdy węzły są wyłączone, usługi systemowe są migrowane do nowego typu węzła podstawowego, który został wcześniej wdrożony.

   Connect-ServiceFabricCluster -ConnectionEndpoint $ClusterName `
       -KeepAliveIntervalInSec 10 `
       -X509Credential `
       -ServerCertThumbprint $thumb  `
       -FindType FindByThumbprint `
       -FindValue $thumb `
       -StoreLocation CurrentUser `
       -StoreName My 
   
   Write-Host "Connected to cluster"
   
   $nodeNames = @("_nt0_0", "_nt0_1", "_nt0_2", "_nt0_3", "_nt0_4")
   
   Write-Host "Disabling nodes..."
   foreach($name in $nodeNames) {
       Disable-ServiceFabricNode -NodeName $name -Intent RemoveNode -Force
   }
   

3. Po wyłączeniu wszystkich węzłów usługi systemowe będą działać w typie węzła podstawowego, który jest rozłożony na strefy. Następnie można usunąć wyłączone węzły z klastra. Po usunięciu węzłów można usunąć oryginalny adres IP, moduł równoważenia obciążenia i zasoby zestawu skalowania maszyn wirtualnych.

   foreach($name in $nodeNames){
       # Remove the node from the cluster
       Remove-ServiceFabricNodeState -NodeName $name -TimeoutSec 300 -Force
       Write-Host "Removed node state for node $name"
   }
   
   $scaleSetName="nt0"
   Remove-AzureRmVmss -ResourceGroupName $groupname -VMScaleSetName $scaleSetName -Force
   
   $lbname="LB-cluster-nt0"
   $oldPublicIpName="LBIP-cluster-0"
   $newPublicIpName="LBIP-cluster-1"
   
   Remove-AzureRmLoadBalancer -Name $lbname -ResourceGroupName $groupname -Force
   Remove-AzureRmPublicIpAddress -Name $oldPublicIpName -ResourceGroupName $groupname -Force
   

4. Następnie usuń odwołania do tych zasobów z wdrożonego szablonu usługi Resource Manager.

5. Na koniec zaktualizuj nazwę DNS i publiczny adres IP.

$oldprimaryPublicIP = Get-AzureRmPublicIpAddress -Name $oldPublicIpName  -ResourceGroupName $groupname
$primaryDNSName = $oldprimaryPublicIP.DnsSettings.DomainNameLabel
$primaryDNSFqdn = $oldprimaryPublicIP.DnsSettings.Fqdn

Remove-AzureRmLoadBalancer -Name $lbname -ResourceGroupName $groupname -Force
Remove-AzureRmPublicIpAddress -Name $oldPublicIpName -ResourceGroupName $groupname -Force

$PublicIP = Get-AzureRmPublicIpAddress -Name $newPublicIpName  -ResourceGroupName $groupname
$PublicIP.DnsSettings.DomainNameLabel = $primaryDNSName
$PublicIP.DnsSettings.Fqdn = $primaryDNSFqdn
Set-AzureRmPublicIpAddress -PublicIpAddress $PublicIP

Jeśli napotkasz jakiekolwiek problemy, skontaktuj się z pomocą techniczną w celu uzyskania pomocy.

Następne kroki

• Skalowanie w górę typu węzła podstawowego klastra nienależącego do klastra zarządzanego

• Dodawanie, usuwanie lub skalowanie typów węzłów klastra zarządzanego usługi Service Fabric