Udostępnij za pośrednictwem

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

  • Artykuł

W tym artykule opisano sposób skalowania w górę typu węzła podstawowego klastra usługi Service Fabric z minimalnym przestojem. Uaktualnienia jednostek SKU w miejscu nie są obsługiwane w węzłach klastra usługi Service Fabric, ponieważ takie operacje potencjalnie obejmują 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 działają obok siebie, wyłącz jednocześnie 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ższy przewodnik przeprowadzi Cię przez proces aktualizowania rozmiaru maszyny wirtualnej i systemu operacyjnego maszyn wirtualnych typu węzła podstawowego przykładowego klastra z trwałością srebra, 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 próby wykonania 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, których użyjemy do ukończenia tego przykładowego scenariusza uaktualniania, 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 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 na clusterName coś unikatowego (w obrębie platformy Azure).

Poniższe polecenia przeprowadzą Cię przez wygenerowanie nowego certyfikatu z podpisem własnym i wdrożenie 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, którego można teraz użyć do nawiązania połączenia z nowym klastrem i sprawdzenia jego stanu kondycji. (Pomiń następującą sekcję, która jest alternatywnym podejściem do wdrażania 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 usługi 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 usługa 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 będziemy musieli 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 dla tego kroku zostały już wprowadzone w pliku szablonu Step1-AddPrimaryNodeType.json , a poniższe wyjaśnią te zmiany szczegółowo. Jeśli wolisz, możesz pominąć wyjaśnienie i kontynuować uzyskiwanie odwołań do usługi 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 przy użyciu unikatowej nazwydomenyLabel

{
    "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 maszyny wirtualnej i systemu operacyjnego)

Typ węzła — odwołanie

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

Dlatego w przypadku zmiany obrazu maszyny wirtualnej (jednostki 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ć przy użyciu 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łączysz wszelkie dodatkowe rozszerzenia wymagane dla obciążenia.

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 szablonów i parametrów przejdź do następnej sekcji, aby uzyskać odwołania do usługi Key Vault i wdrożyć aktualizacje w klastrze.

Uzyskiwanie odwołań do usługi Key Vault

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

  • Adres URL usługi Key Vault certyfikatu klastra. W usłudze Key Vault w witrynie Azure Portal wybierz pozycję Certyfikaty>Żądany identyfikator wpisu tajnego certyfikatu:>

    $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 Żądane certyfikaty>) w witrynie Azure Portal skopiuj odcisk palca SHA-1 (w formacie szesnastkowym) X.509:

    $thumb = "BB796AA33BD9767E7DA27FE5182CF8FDEE714A70"

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

    $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 jego węzłów. Gdy węzły są wyłączone, usługi systemowe klastra i węzły inicjują migrację 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 za pomocą aktualizacji. To wdrożenie inicjuje migrację węzłów inicjowania 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 inicjowania do nowego zestawu skalowania zajmie trochę czasu. Aby zagwarantować spójność danych, tylko jeden węzeł inicjuje zmianę w danym momencie. Każda zmiana węzła inicjowania wymaga aktualizacji klastra; w ten sposób zastąpienie węzła inicjujące wymaga dwóch uaktualnień klastra (po jednym do dodawania i usuwania węzła). Uaktualnienie pięciu węzłów inicjacyjnych w tym przykładowym scenariuszu spowoduje uaktualnienie dziesięciu klastrów.

Użyj narzędzia Service Fabric Explorer, aby monitorować migrację węzłów inicjowania 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 mieć wartość true.

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 narzędzia Service Fabric Explorer, aby monitorować postęp węzłów w oryginalnym zestawie skalowania z wyłączeniem do stanu Wyłączone .

Eksplorator usługi Service Fabric przedstawiający stan wyłączonych węzłów

W przypadku trwałości Silver i Gold niektóre węzły będą w stanie Wyłączone, a inne mogą pozostać w stanie Wyłączanie . W narzędziu 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ć.

Możesz kontynuować zatrzymywanie danych i usuwanie węzłów zablokowanych w stanie

Jeśli klaster ma trwałość z 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

Możemy usunąć oryginalny typ węzła i skojarzone z nim zasoby, aby zakończyć procedurę skalowania w pionie.

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 jednostki SKU w warstwie Standardowa i modułu równoważenia obciążenia. 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 $lbname wartość zgodnie z 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 oryginalnego typu węzła będą teraz wyświetlać wartość Błąd dla 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
  }
}

Narzędzie Service Fabric Explorer powinno 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. Korygujemy to dalej, aktualizując szablon w celu odzwierciedlenia najnowszych zmian i ponownego wdrożenia.

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

Wymagane zmiany dla tego 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ńczyć samouczek.

Aktualizowanie punktu końcowego zarządzania klastrem

Zaktualizuj klaster managementEndpoint w szablonie wdrożenia, aby odwoływać się do nowego adresu IP (aktualizując vmNodeType0Name za pomocą 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 element 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 pliku 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 spowoduje zmianę ustawień usługi 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 partycję w bezpiecznym stanie, jeśli jeszcze nie jest w stanie bezpiecznym. Po przejściu kontroli bezpieczeństwa dla wszystkich partycji w węźle usługa Service Fabric kontynuuje uaktualnianie w tym węźle. Wartość parametru upgradeTimeout można zmniejszyć do 6 godzin, ale dla maksymalnego bezpieczeństwa należy użyć 12 godzin.

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

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

Następne kroki