Skalowanie w górę węzła klastra usługi Service Fabric podstawowego typu

W tym artykule opisano sposób skalowania w górę typu podstawowego węzła klastra usługi Service Fabric z minimalnym przestojem. Uaktualnienia jednostki SKU w miejscu nie są obsługiwane w węzłach klastra usługi Service Fabric, ponieważ takie operacje mogą potencjalnie obejmować utratę danych i dostępności. Najbezpieczniejszą, najbardziej niezawodną i zalecaną metodą skalowania w górę typu węzła usługi Service Fabric jest:

1. Dodaj nowy typ węzła do klastra usługi Service Fabric, wspierany przez uaktualnioną (lub zmodyfikowaną) jednostkę SKU zestawu skalowania maszyn wirtualnych i konfigurację. Ten krok obejmuje również skonfigurowanie nowego modułu równoważenia obciążenia, podsieci i publicznego adresu IP dla zestawu skalowania.

2. Gdy zarówno oryginalne, jak i uaktualnione zestawy skalowania są uruchamiane obok siebie, należy jednocześnie wyłączyć oryginalne wystąpienia węzłów, aby usługi systemowe (lub repliki usług stanowych) migrowały do nowego zestawu skalowania.

3. Sprawdź, czy klaster i nowe węzły są w dobrej kondycji, a następnie usuń oryginalny zestaw skalowania (i powiązane zasoby) oraz stan węzła dla usuniętych węzłów.

Poniżej przedstawiono proces aktualizowania rozmiaru maszyny wirtualnej i systemu operacyjnego maszyn wirtualnych typu węzła podstawowego maszyn wirtualnych przykładowego klastra z trwałością silver, wspieranego przez pojedynczy zestaw skalowania z pięcioma węzłami. Uaktualnimy typ węzła podstawowego:

• Od rozmiaru maszyny wirtualnej Standard_D2_V2 do D4_V2 w warstwie Standardowa i
• Z systemu operacyjnego Maszyny wirtualnej Windows Server 2019 Datacenter do systemu Windows Server 2022 Datacenter.

Ostrzeżenie

Przed podjęciem tej procedury w klastrze produkcyjnym zalecamy zapoznanie się z przykładowymi szablonami i zweryfikowanie procesu względem klastra testowego. Klaster może być również niedostępny przez krótki czas.

Nie należy podejmować próby wykonania procedury skalowania w górę typu węzła podstawowego, jeśli stan klastra jest w złej kondycji, ponieważ spowoduje to dalsze destabilizację klastra.

Szablony wdrażania krok po kroku platformy Azure, których użyjemy do ukończenia tego przykładowego scenariusza uaktualnienia, są dostępne w usłudze GitHub.

Konfigurowanie klastra testowego

Skonfigurujmy początkowy klaster testowy usługi Service Fabric. Najpierw pobierz przykładowe szablony usługi Azure Resource Manager, których użyjemy do ukończenia tego scenariusza.

Następnie zaloguj się do swojego konta platformy Azure.

# Sign in to your Azure account
Login-AzAccount -SubscriptionId "<subscription ID>"

Następnie otwórz plik parameters.json i zaktualizuj wartość elementu do clusterName czegoś unikatowego (w obrębie platformy Azure).

Poniższe polecenia przeprowadzą Cię przez generowanie nowego certyfikatu z podpisem własnym i wdrażanie klastra testowego. Jeśli masz już certyfikat, którego chcesz użyć, przejdź do sekcji Używanie istniejącego certyfikatu do wdrożenia klastra.

Generowanie certyfikatu z podpisem własnym i wdrażanie klastra

Najpierw przypisz zmienne potrzebne do wdrożenia klastra usługi Service Fabric. Dostosuj wartości dla resourceGroupName, , certSubjectNameparameterFilePathi templateFilePath dla określonego konta i środowiska:

# Assign deployment variables
$resourceGroupName = "sftestupgradegroup"
$certOutputFolder = "c:\certificates"
$certPassword = "Password!1" | ConvertTo-SecureString -AsPlainText -Force
$certSubjectName = "sftestupgrade.southcentralus.cloudapp.azure.com"
$parameterFilePath = "C:\parameters.json"
$templateFilePath = "C:\Initial-TestClusterSetup.json"

Uwaga

Przed uruchomieniem polecenia w celu wdrożenia nowego klastra usługi Service Fabric upewnij się, że certOutputFolder lokalizacja istnieje na komputerze lokalnym.

Następnie wdróż klaster testowy usługi Service Fabric:

# Deploy the initial test cluster
New-AzServiceFabricCluster `
    -ResourceGroupName $resourceGroupName `
    -CertificateOutputFolder $certOutputFolder `
    -CertificatePassword $certPassword `
    -CertificateSubjectName $certSubjectName `
    -TemplateFile $templateFilePath `
    -ParameterFile $parameterFilePath

Po zakończeniu wdrażania znajdź plik pfx ($certPfx) na komputerze lokalnym i zaimportuj go do magazynu certyfikatów:

cd c:\certificates
$certPfx = ".\sftestupgradegroup20200312121003.pfx"

Import-PfxCertificate `
     -FilePath $certPfx `
     -CertStoreLocation Cert:\CurrentUser\My `
     -Password (ConvertTo-SecureString Password!1 -AsPlainText -Force)

Operacja zwraca odcisk palca certyfikatu, za pomocą którego można teraz nawiązać połączenie z nowym klastrem i sprawdzić jego stan kondycji. (Pomiń następującą sekcję, czyli alternatywne podejście do wdrożenia klastra).

Wdrażanie klastra przy użyciu istniejącego certyfikatu

Alternatywnie możesz użyć istniejącego certyfikatu usługi Azure Key Vault do wdrożenia klastra testowego. W tym celu należy uzyskać odwołania do Key Vault i odcisku palca certyfikatu.

# Key Vault variables
$certUrlValue = "https://sftestupgradegroup.vault.azure.net/secrets/sftestupgradegroup20200309235308/dac0e7b7f9d4414984ccaa72bfb2ea39"
$sourceVaultValue = "/subscriptions/########-####-####-####-############/resourceGroups/sftestupgradegroup/providers/Microsoft.KeyVault/vaults/sftestupgradegroup"
$thumb = "BB796AA33BD9767E7DA27FE5182CF8FDEE714A70"

Następnie należy wyznaczyć nazwę grupy zasobów dla klastra i ustawić templateFilePath lokalizacje i parameterFilePath :

Uwaga

Wyznaczona grupa zasobów musi już istnieć i znajdować się w tym samym regionie co Key Vault.

$resourceGroupName = "sftestupgradegroup"
$templateFilePath = "C:\Initial-TestClusterSetup.json"
$parameterFilePath = "C:\parameters.json"

Na koniec uruchom następujące polecenie, aby wdrożyć początkowy klaster testowy:

# Deploy the initial test cluster
New-AzResourceGroupDeployment `
    -ResourceGroupName $resourceGroupName `
    -TemplateFile $templateFilePath `
    -TemplateParameterFile $parameterFilePath `
    -CertificateThumbprint $thumb `
    -CertificateUrlValue $certUrlValue `
    -SourceVaultValue $sourceVaultValue `
    -Verbose

Nawiązywanie połączenia z nowym klastrem i sprawdzanie stanu kondycji

Połącz się z klastrem i upewnij się, że wszystkie pięć jego węzłów jest w dobrej kondycji (zastąp clusterName zmienne i thumb własnymi wartościami):

# Connect to the cluster
$clusterName = "sftestupgrade.southcentralus.cloudapp.azure.com:19000"
$thumb = "BB796AA33BD9767E7DA27FE5182CF8FDEE714A70"

Connect-ServiceFabricCluster `
    -ConnectionEndpoint $clusterName `
    -KeepAliveIntervalInSec 10 `
    -X509Credential `
    -ServerCertThumbprint $thumb  `
    -FindType FindByThumbprint `
    -FindValue $thumb `
    -StoreLocation CurrentUser `
    -StoreName My

# Check cluster health
Get-ServiceFabricClusterHealth

Teraz możemy rozpocząć procedurę uaktualniania.

Wdrażanie nowego typu węzła podstawowego z uaktualnionym zestawem skalowania

Aby uaktualnić (skalowanie w pionie) typ węzła, najpierw musimy wdrożyć nowy typ węzła wspierany przez nowy zestaw skalowania i zasoby pomocnicze. Nowy zestaw skalowania zostanie oznaczony jako podstawowy (isPrimary: true), podobnie jak oryginalny zestaw skalowania. Jeśli chcesz skalować w górę typ węzła innego niż podstawowy, zobacz Skalowanie w górę klastra usługi Service Fabric innego niż podstawowy typ węzła. Zasoby utworzone w poniższej sekcji ostatecznie staną się nowym typem węzła podstawowego w klastrze, a oryginalne zasoby typu węzła podstawowego zostaną usunięte.

Aktualizowanie szablonu klastra przy użyciu uaktualnionego zestawu skalowania

Poniżej przedstawiono modyfikacje sekcji po sekcji oryginalnego szablonu wdrożenia klastra w celu dodania nowego typu węzła podstawowego i zasobów pomocniczych.

Wymagane zmiany w tym kroku zostały już wprowadzone w pliku szablonu Step1-AddPrimaryNodeType.json , a poniższe objaśnią te zmiany szczegółowo. Jeśli wolisz, możesz pominąć wyjaśnienie i kontynuować uzyskiwanie odwołań do Key Vault i wdrożyć zaktualizowany szablon, który dodaje nowy typ węzła podstawowego do klastra.

Uwaga

Upewnij się, że używasz nazw unikatowych od oryginalnego typu węzła, zestawu skalowania, modułu równoważenia obciążenia, publicznego adresu IP i podsieci oryginalnego typu węzła podstawowego, ponieważ te zasoby zostaną usunięte w późniejszym kroku procesu.

Tworzenie nowej podsieci w istniejącej sieci wirtualnej

{
    "name": "[variables('subnet1Name')]",
    "properties": {
        "addressPrefix": "[variables('subnet1Prefix')]"
    }
}

Tworzenie nowego publicznego adresu IP z unikatową domenąNameLabel

{
    "apiVersion": "[variables('publicIPApiVersion')]",
    "type": "Microsoft.Network/publicIPAddresses",
    "name": "[concat(variables('lbIPName'),'-',variables('vmNodeType1Name'))]",
    "location": "[variables('computeLocation')]",
    "properties": {
        "dnsSettings": {
            "domainNameLabel": "[concat(variables('dnsName'),'-','nt1')]"
        },
        "publicIPAllocationMethod": "Dynamic"
    },
    "tags": {
        "resourceType": "Service Fabric",
        "clusterName": "[parameters('clusterName')]"
    }
}

Tworzenie nowego modułu równoważenia obciążenia dla publicznego adresu IP

"dependsOn": [
    "[concat('Microsoft.Network/publicIPAddresses/',concat(variables('lbIPName'),'-',variables('vmNodeType1Name')))]"
]

Tworzenie nowego zestawu skalowania maszyn wirtualnych (z uaktualnionymi jednostkami SKU maszyn wirtualnych i jednostek SKU systemu operacyjnego)

Typ węzła — ref

"nodeTypeRef": "[variables('vmNodeType1Name')]"

Jednostka SKU maszyny wirtualnej

"sku": {
    "name": "[parameters('vmNodeType1Size')]",
    "capacity": "[parameters('nt1InstanceCount')]",
    "tier": "Standard"
}

Jednostka SKU systemu operacyjnego

"imageReference": {
    "publisher": "[parameters('vmImagePublisher1')]",
    "offer": "[parameters('vmImageOffer1')]",
    "sku": "[parameters('vmImageSku1')]",
    "version": "[parameters('vmImageVersion1')]"
}

Jeśli zmieniasz jednostkę SKU systemu operacyjnego w klastrze systemu Linux

W klastrze systemu Windows wartość właściwości vmImage to "Windows", a wartość tej samej właściwości klastra systemu Linux to nazwa używanego obrazu systemu operacyjnego. Na przykład — Ubuntu20_04 (użyj najnowszej nazwy obrazu maszyny wirtualnej).

Jeśli więc zmieniasz obraz maszyny wirtualnej (jednostka SKU systemu operacyjnego) w klastrze systemu Linux, zaktualizuj również ustawienie vmImage w zasobie klastra usługi Service Fabric.

#Update the property vmImage with the required OS name in your ARM template
{
    "vmImage": "[parameter(newVmImageName]”
}

Uwaga: przykład newVmImageName: Ubuntu20_04

Zasób klastra można również zaktualizować za pomocą następującego polecenia programu PowerShell:

# Update cluster vmImage to target OS. This registers the SF runtime package type that is supplied for upgrades.
Update-AzServiceFabricVmImage -ResourceGroupName $resourceGroup -ClusterName $clusterName -VmImage Ubuntu20_04

Upewnij się również, że do obciążenia są wymagane dodatkowe rozszerzenia.

Dodawanie nowego typu węzła podstawowego do klastra

Teraz, gdy nowy typ węzła (vmNodeType1Name) ma własną nazwę, podsieć, adres IP, moduł równoważenia obciążenia i zestaw skalowania, może ponownie użyć wszystkich innych zmiennych z oryginalnego typu węzła (na przykład nt0applicationEndPort, nt0applicationStartPorti nt0fabricTcpGatewayPort):

"name": "[variables('vmNodeType1Name')]",
"applicationPorts": {
    "endPort": "[variables('nt0applicationEndPort')]",
    "startPort": "[variables('nt0applicationStartPort')]"
},
"clientConnectionEndpointPort": "[variables('nt0fabricTcpGatewayPort')]",
"durabilityLevel": "Bronze",
"ephemeralPorts": {
    "endPort": "[variables('nt0ephemeralEndPort')]",
    "startPort": "[variables('nt0ephemeralStartPort')]"
},
"httpGatewayEndpointPort": "[variables('nt0fabricHttpGatewayPort')]",
"isPrimary": true,
"reverseProxyEndpointPort": "[variables('nt0reverseProxyEndpointPort')]",
"vmInstanceCount": "[parameters('nt1InstanceCount')]"

Po zaimplementowaniu wszystkich zmian w plikach szablonu i parametrów przejdź do następnej sekcji, aby uzyskać odwołania do Key Vault i wdrożyć aktualizacje w klastrze.

Uzyskiwanie odwołań do Key Vault

Aby wdrożyć zaktualizowaną konfigurację, potrzebujesz kilku odwołań do certyfikatu klastra przechowywanego w Key Vault. Najprostszym sposobem znalezienia tych wartości jest Azure Portal. Potrzebne elementy:

• Adres URL Key Vault certyfikatu klastra. W Key Vault w Azure Portal wybierz pozycję Certyfikaty> Żądanyidentyfikator wpisu tajnegocertyfikatu>:

  $certUrlValue="https://sftestupgradegroup.vault.azure.net/secrets/sftestupgradegroup20200309235308/dac0e7b7f9d4414984ccaa72bfb2ea39"
  

• Odcisk palca certyfikatu klastra. (Prawdopodobnie masz już certyfikat, jeśli nawiązaliśmy połączenie z klastrem początkowym, aby sprawdzić jego stan kondycji). W tym samym bloku certyfikatu (Certyfikaty>Żądany certyfikat) w Azure Portal skopiuj odcisk palca SHA-1 X.509 (w szesnastku):

  $thumb = "BB796AA33BD9767E7DA27FE5182CF8FDEE714A70"
  

• Identyfikator zasobu Key Vault. W Key Vault w Azure Portal wybierz pozycjęIdentyfikator zasobuwłaściwości>:

  $sourceVaultValue = "/subscriptions/########-####-####-####-############/resourceGroups/sftestupgradegroup/providers/Microsoft.KeyVault/vaults/sftestupgradegroup"
  

Wdrażanie zaktualizowanego szablonu

Dostosuj wartość zgodnie z potrzebami templateFilePath i uruchom następujące polecenie:

# Deploy the new node type and its resources
$templateFilePath = "C:\Step1-AddPrimaryNodeType.json"

New-AzResourceGroupDeployment `
    -ResourceGroupName $resourceGroupName `
    -TemplateFile $templateFilePath `
    -TemplateParameterFile $parameterFilePath `
    -CertificateThumbprint $thumb `
    -CertificateUrlValue $certUrlValue `
    -SourceVaultValue $sourceVaultValue `
    -Verbose

Po zakończeniu wdrażania ponownie sprawdź kondycję klastra i upewnij się, że wszystkie węzły w obu typach węzłów są w dobrej kondycji.

Get-ServiceFabricClusterHealth

Migrowanie węzłów inicjowanych do nowego typu węzła

Teraz możemy zaktualizować oryginalny typ węzła jako inny niż podstawowy i rozpocząć wyłączanie węzłów. Po wyłączeniu węzłów usługi systemowe klastra i węzły początkowe są migrowane do nowego zestawu skalowania.

Usuń oznaczenie oryginalnego typu węzła jako podstawowego

Najpierw usuń isPrimary oznaczenie w szablonie z oryginalnego typu węzła.

{
    "isPrimary": false,
}

Następnie wdróż szablon przy użyciu aktualizacji. To wdrożenie inicjuje migrację węzłów początkowych do nowego zestawu skalowania.

$templateFilePath = "C:\Step2-UnmarkOriginalPrimaryNodeType.json"

New-AzResourceGroupDeployment `
    -ResourceGroupName $resourceGroupName `
    -TemplateFile $templateFilePath `
    -TemplateParameterFile $parameterFilePath `
    -CertificateThumbprint $thumb `
    -CertificateUrlValue $certUrlValue `
    -SourceVaultValue $sourceVaultValue `
    -Verbose

Uwaga

Ukończenie migracji węzła początkowego do nowego zestawu skalowania zajmie trochę czasu. Aby zagwarantować spójność danych, tylko jeden węzeł inicjuje się w danym momencie. Każda zmiana węzła inicjowania wymaga aktualizacji klastra; dlatego zastąpienie węzła inicjujące wymaga dwóch uaktualnień klastra (po jednym dla dodawania i usuwania węzłów). Uaktualnienie pięciu węzłów inicjacyjnych w tym przykładowym scenariuszu spowoduje dziesięć uaktualnień klastra.

Użyj Service Fabric Explorer, aby monitorować migrację węzłów początkowych do nowego zestawu skalowania. Węzły oryginalnego typu węzła (nt0vm) powinny być fałszywe w kolumnie Is Seed Node , a węzły nowego typu węzła (nt1vm) powinny być prawdziwe.

Wyłączanie węzłów w oryginalnym zestawie skalowania typu węzła

Po przeprowadzeniu migracji wszystkich węzłów inicjowanych do nowego zestawu skalowania można wyłączyć węzły oryginalnego zestawu skalowania.

# Disable the nodes in the original scale set.
$nodeType = "nt0vm"
$nodes = Get-ServiceFabricNode

Write-Host "Disabling nodes..."
foreach($node in $nodes)
{
  if ($node.NodeType -eq $nodeType)
  {
    $node.NodeName

    Disable-ServiceFabricNode -Intent RemoveNode -NodeName $node.NodeName -Force
  }
}

Użyj Service Fabric Explorer, aby monitorować postęp węzłów w oryginalnym zestawie skalowania z wyłączeniem do stanu Wyłączone.

W przypadku trwałości silver i Gold niektóre węzły będą przechodzić do stanu Wyłączone, podczas gdy inne mogą pozostać w stanie Wyłączanie . W Service Fabric Explorer sprawdź kartę Szczegóły węzłów w obszarze Stan wyłączania. Jeśli zostaną wyświetlone oczekujące sprawdzanie bezpieczeństwa typu EnsurePartitionQuorem (zapewnienie kworum dla partycji usługi infrastruktury), można kontynuować.

Jeśli klaster ma trwałość brązu, poczekaj, aż wszystkie węzły osiągną stan Wyłączone .

Zatrzymywanie danych w wyłączonych węzłach

Teraz możesz zatrzymać dane w wyłączonych węzłach.

# Stop data on the disabled nodes.
foreach($node in $nodes)
{
  if ($node.NodeType -eq $nodeType)
  {
    $node.NodeName

    Start-ServiceFabricNodeTransition -Stop -OperationId (New-Guid) -NodeInstanceId $node.NodeInstanceId -NodeName $node.NodeName -StopDurationInSeconds 10000
  }
}

Usuń oryginalny typ węzła i wyczyść jego zasoby

Jesteśmy gotowi usunąć oryginalny typ węzła i skojarzone z nim zasoby, aby zakończyć procedurę skalowania pionowego.

Usuwanie oryginalnego zestawu skalowania

Najpierw usuń zestaw skalowania kopii zapasowych typu węzła.

$scaleSetName = "nt0vm"
$scaleSetResourceType = "Microsoft.Compute/virtualMachineScaleSets"

Remove-AzResource -ResourceName $scaleSetName -ResourceType $scaleSetResourceType -ResourceGroupName $resourceGroupName -Force

Usuwanie oryginalnych zasobów adresu IP i modułu równoważenia obciążenia

Możesz teraz usunąć oryginalny adres IP i zasoby modułu równoważenia obciążenia. W tym kroku zaktualizujesz również nazwę DNS.

Uwaga

Ten krok jest opcjonalny, jeśli używasz już publicznego adresu IP i modułu równoważenia obciążenia jednostki SKU w warstwie Standardowa . W takim przypadku można mieć wiele zestawów skalowania/typów węzłów w ramach tego samego modułu równoważenia obciążenia.

Uruchom następujące polecenia, modyfikując wartość zgodnie z $lbname potrzebami.

# Delete the original IP and load balancer resources
$lbName = "LB-sftestupgrade-nt0vm"
$lbResourceType = "Microsoft.Network/loadBalancers"
$ipResourceType = "Microsoft.Network/publicIPAddresses"
$oldPublicIpName = "PublicIP-LB-FE-nt0vm"
$newPublicIpName = "PublicIP-LB-FE-nt1vm"

$oldPrimaryPublicIP = Get-AzPublicIpAddress -Name $oldPublicIpName  -ResourceGroupName $resourceGroupName
$primaryDNSName = $oldPrimaryPublicIP.DnsSettings.DomainNameLabel
$primaryDNSFqdn = $oldPrimaryPublicIP.DnsSettings.Fqdn

Remove-AzResource -ResourceName $lbName -ResourceType $lbResourceType -ResourceGroupName $resourceGroupName -Force
Remove-AzResource -ResourceName $oldPublicIpName -ResourceType $ipResourceType -ResourceGroupName $resourceGroupName -Force

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

Usuwanie stanu węzła z oryginalnego typu węzła

Węzły typu oryginalnego węzła będą teraz zawierać komunikat Błąd dla ich stanu kondycji. Usuń stan węzła z klastra.

# Remove state of the obsolete nodes from the cluster
$nodeType = "nt0vm"
$nodes = Get-ServiceFabricNode

Write-Host "Removing node state..."
foreach($node in $nodes)
{
  if ($node.NodeType -eq $nodeType)
  {
    $node.NodeName

    Remove-ServiceFabricNodeState -NodeName $node.NodeName -Force
  }
}

Service Fabric Explorer powinny teraz odzwierciedlać tylko pięć węzłów nowego typu węzła (nt1vm), wszystkie z wartościami stanu kondycji ok. Stan kondycji klastra nadal będzie wyświetlany błąd. Następnie skorygowamy ten problem, aktualizując szablon w celu odzwierciedlenia najnowszych zmian i ponownego wdrażania.

Zaktualizuj szablon wdrożenia, aby odzwierciedlał nowo skalowany w górę typ węzła podstawowego

Wymagane zmiany w tym kroku zostały już wprowadzone w pliku szablonu Step3-CleanupOriginalPrimaryNodeType.json , a poniższe sekcje szczegółowo wyjaśnią te zmiany szablonu. Jeśli wolisz, możesz pominąć wyjaśnienie i kontynuować wdrażanie zaktualizowanego szablonu i ukończenie samouczka.

Aktualizowanie punktu końcowego zarządzania klastrem

Zaktualizuj klaster managementEndpoint w szablonie wdrożenia, aby odwoływać się do nowego adresu IP (aktualizując wartość vmNodeType0Name za pomocą parametru vmNodeType1Name).

  "managementEndpoint": "[concat('https://',reference(concat(variables('lbIPName'),'-',variables('vmNodeType1Name'))).dnsSettings.fqdn,':',variables('nt0fabricHttpGatewayPort'))]",

Usuń odwołanie do oryginalnego typu węzła

Usuń odwołanie do oryginalnego typu węzła z zasobu usługi Service Fabric w szablonie wdrożenia:

"name": "[variables('vmNodeType0Name')]",
"applicationPorts": {
    "endPort": "[variables('nt0applicationEndPort')]",
    "startPort": "[variables('nt0applicationStartPort')]"
},
"clientConnectionEndpointPort": "[variables('nt0fabricTcpGatewayPort')]",
"durabilityLevel": "Bronze",
"ephemeralPorts": {
    "endPort": "[variables('nt0ephemeralEndPort')]",
    "startPort": "[variables('nt0ephemeralStartPort')]"
},
"httpGatewayEndpointPort": "[variables('nt0fabricHttpGatewayPort')]",
"isPrimary": true,
"reverseProxyEndpointPort": "[variables('nt0reverseProxyEndpointPort')]",
"vmInstanceCount": "[parameters('nt0InstanceCount')]"

Konfigurowanie zasad kondycji w celu ignorowania istniejących błędów

Tylko w przypadku klastrów silver i wyższych trwałości zaktualizuj zasób klastra w szablonie i skonfiguruj zasady kondycji, aby zignorować fabric:/System kondycję aplikacji, dodając applicationDeltaHealthPolicies w obszarze właściwości zasobów klastra, jak pokazano poniżej. Poniższe zasady będą ignorować istniejące błędy, ale nie zezwalają na nowe błędy kondycji.

"upgradeDescription":  
{ 
 "forceRestart": false, 
 "upgradeReplicaSetCheckTimeout": "10675199.02:48:05.4775807", 
 "healthCheckWaitDuration": "00:05:00", 
 "healthCheckStableDuration": "00:05:00", 
 "healthCheckRetryTimeout": "00:45:00", 
 "upgradeTimeout": "12:00:00", 
 "upgradeDomainTimeout": "02:00:00", 
 "healthPolicy": { 
   "maxPercentUnhealthyNodes": 100, 
   "maxPercentUnhealthyApplications": 100 
 }, 
 "deltaHealthPolicy":  
 { 
   "maxPercentDeltaUnhealthyNodes": 0, 
   "maxPercentUpgradeDomainDeltaUnhealthyNodes": 0, 
   "maxPercentDeltaUnhealthyApplications": 0, 
   "applicationDeltaHealthPolicies":  
   { 
       "fabric:/System":  
       { 
           "defaultServiceTypeDeltaHealthPolicy":  
           { 
                   "maxPercentDeltaUnhealthyServices": 0 
           } 
       } 
   } 
 } 
}

Usuwanie zasobów pomocniczych dla oryginalnego typu węzła

Usuń wszystkie inne zasoby związane z oryginalnym typem węzła z szablonu usługi ARM i plikiem parametrów. Usuń następujące elementy:

    "vmImagePublisher": {
      "value": "MicrosoftWindowsServer"
    },
    "vmImageOffer": {
      "value": "WindowsServer"
    },
    "vmImageSku": {
      "value": "2019-Datacenter"
    },
    "vmImageVersion": {
      "value": "latest"
    },

Wdrażanie finalizowanego szablonu

Na koniec wdróż zmodyfikowany szablon usługi Azure Resource Manager.

# Deploy the updated template file
$templateFilePath = "C:\Step3-CleanupOriginalPrimaryNodeType"

New-AzResourceGroupDeployment `
    -ResourceGroupName $resourceGroupName `
    -TemplateFile $templateFilePath `
    -TemplateParameterFile $parameterFilePath `
    -CertificateThumbprint $thumb `
    -CertificateUrlValue $certUrlValue `
    -SourceVaultValue $sourceVaultValue `
    -Verbose

Uwaga

Ten krok zajmie trochę czasu, zwykle do dwóch godzin.

Uaktualnienie zmieni ustawienia na InfrastructureService; dlatego wymagane jest ponowne uruchomienie węzła. W takim przypadku polecenie forceRestart jest ignorowane. Parametr upgradeReplicaSetCheckTimeout określa maksymalny czas oczekiwania usługi Service Fabric na bezpieczną partycję, jeśli jeszcze nie jest w bezpiecznym stanie. Po sprawdzeniu bezpieczeństwa wszystkich partycji w węźle usługa Service Fabric przejdzie do uaktualnienia w tym węźle. Wartość parametru upgradeTimeout można zmniejszyć do 6 godzin, ale w przypadku maksymalnego bezpieczeństwa należy użyć 12 godzin.

Po zakończeniu wdrażania sprawdź w Azure Portal, czy stan zasobu usługi Service Fabric jest gotowy. Sprawdź, czy możesz uzyskać dostęp do nowego punktu końcowego Service Fabric Explorer, stan kondycji klastra jest ok, a wszystkie wdrożone aplikacje działają prawidłowo.

Teraz skalowano w pionie typ węzła podstawowego klastra.

Następne kroki

• Dowiedz się, jak dodać typ węzła do klastra
• Dowiedz się więcej o skalowalności aplikacji.
• Skalowanie klastra platformy Azure w poziomie lub w poziomie.
• Programowe skalowanie klastra platformy Azure przy użyciu płynnego zestawu Azure Compute SDK.
• Skalowanie klastra autonomicznego w poziomie lub w poziomie.