Partager via

Effectuer un scale-up d’un type de nœud non principal de cluster Service Fabric

  • Article

Cet article explique comment effectuer un scale-up d’un type de nœud non principal de cluster Service Fabric avec un temps d’arrêt minimal. Les mises à niveau sur place des références SKU ne sont pas prises en charge sur les nœuds de cluster Service Fabric, car ces opérations peuvent entraîner une perte de données et de disponibilité. La méthode la plus sûre, la plus fiable et la plus recommandée pour la mise à l'échelle d'un type de nœud Service Fabric est la suivante :

  1. Ajoutez un nouveau type de nœud à votre cluster Service Fabric, qui s’appuie sur la référence SKU et la configuration de votre groupe de machines virtuelles identiques mis à niveau (ou modifié). Cette étape implique également la configuration d’un nouvel équilibreur de charge, d’un sous-réseau et d’une IP publique pour le groupe identique.

  2. Une fois que les groupes identiques d’origine et mis à niveau s’exécutent côte à côte, migrez la charge de travail en définissant des contraintes de placement pour les applications vers le nouveau type de nœud.

  3. Vérifiez que le cluster est sain, puis supprimez le groupe identique d’origine (et les ressources associées) et l’état du nœud pour les nœuds supprimés.

Vous trouverez ci-dessous une description du processus de mise à jour de la taille et du système d’exploitation des machines virtuelles de type nœud non principal d’un exemple de cluster avec durabilité Silver reposant sur un seul groupe identique avec cinq nœuds utilisé comme type de nœud secondaire. Le type de nœud principal avec des services système Service Fabric reste inchangé. Nous allons mettre à niveau le type de nœud non principal :

  • De la taille de machine virtuelle Standard_D2_V2 à Standard_D4_V2, et
  • Du système d’exploitation de machine virtuelle Windows Server 2019 Datacenter vers Windows Server 2022 Datacenter.

Avertissement

Avant de tenter cette procédure sur un cluster de production, nous vous recommandons d’examiner les exemples de modèles et de vérifier la procédure sur un cluster de test.

N’essayez pas d’effectuer un scale-up sur un type de nœud non principal si l’état du cluster n’est pas sain, car cela ne fera que déstabiliser le cluster. Nous allons utiliser les modèles de déploiement pas à pas d’Azure présentés dans le guide Effectuer un scale-up sur un type de nœud principal de cluster Service Fabric. Toutefois, nous allons les modifier afin qu’ils ne soient pas spécifiques aux types de nœuds principaux. Les modèles sont disponibles sur GitHub.

Configurer le cluster de test

Configurons le cluster de test Service Fabric initial. Tout d’abord, téléchargez les exemples de modèles Azure Resource Manager que nous allons utiliser pour terminer ce scénario.

Ensuite, connectez-vous à votre compte Azure.

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

Ouvrez ensuite le fichier parameters.json et mettez à jour la valeur de clusterName sur un nom unique (dans Azure).

Les commandes suivantes vous guident dans la génération d’un nouveau certificat autosigné et le déploiement du cluster de test. Si vous avez déjà un certificat que vous souhaitez utiliser, passez à Utiliser un certificat existant pour déployer le cluster.

Générer un certificat autosigné et déployer le cluster

Tout d’abord, attribuez les variables dont vous aurez besoin pour le déploiement du cluster Service Fabric. Ajustez les valeurs de resourceGroupName, certSubjectName, parameterFilePath et templateFilePath pour votre compte et votre environnement spécifiques :

# 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"

Notes

Assurez-vous que l’emplacement certOutputFolder existe sur votre ordinateur local avant d’exécuter la commande pour déployer un nouveau cluster Service Fabric. Déployez ensuite le cluster de test Service Fabric :

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

Une fois le déploiement terminé, localisez le fichier .pfx ($certPfx) sur votre ordinateur local et importez-le dans votre magasin de certificats :

cd c:\certificates
$certPfx = ".\sftestupgradegroup20200312121003.pfx"
Import-PfxCertificate `
     -FilePath $certPfx `
     -CertStoreLocation Cert:\CurrentUser\My `
     -Password (ConvertTo-SecureString Password!1 -AsPlainText -Force)

L’opération retournera l’empreinte de certificat, que vous pouvez utiliser pour vous connecter au nouveau cluster et vérifier son état d’intégrité. (Ignorez la section suivante, qui est une autre approche du déploiement de cluster.)

Utiliser un certificat existant pour déployer le cluster

Vous pouvez également utiliser un certificat Azure Key Vault existant pour déployer le cluster de test. Pour ce faire, vous devez obtenir les références de votre Key Vault et l’empreinte du certificat.

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

Ensuite, désignez un nom de groupe de ressources pour le cluster et définissez les emplacements templateFilePath et parameterFilePath :

Notes

Le groupe de ressources désigné doit déjà exister et se trouver dans la même région que votre Key Vault.

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

Enfin, exécutez la commande suivante pour déployer le cluster de test initial :

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

Se connecter au nouveau cluster et vérifier l’état d’intégrité

Connectez-vous au cluster et assurez-vous que ses cinq nœuds sont intègres (remplacez les variables clusterName et thumb par vos propres valeurs) :

# 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

Avec cela, nous sommes prêts à commencer la procédure de mise à niveau.

Déployer un nouveau type de nœud non principal avec un groupe identique mis à niveau

Pour mettre à niveau (mettre à l’échelle verticalement) un type de nœud, nous devons tout d’abord déployer un nouveau type de nœud reposant sur un nouveau groupe identique et les ressources de prise en charge. Comme le groupe identique d’origine, le nouveau groupe identique sera marqué comme non principal (isPrimary: false). Si vous souhaitez effectuer un scale-up sur un type de nœud principal, consultez Effectuer un scale-up sur un type de nœud principal de cluster Service Fabric. Les ressources créées dans la section suivante deviendront finalement le nouveau type de nœud de votre cluster, et les ressources du type de nœud d’origine seront supprimées.

Mettre à jour le modèle de cluster avec le groupe identique mis à niveau

Voici les modifications section par section du modèle de déploiement du cluster d’origine pour l’ajout d’un nouveau type de nœud et des ressources de prise en charge.

La plupart des modifications requises pour cette étape ont déjà été apportées dans le fichier de modèle Step1-AddPrimaryNodeType.json . Toutefois, une modification supplémentaire doit être apportée afin que le fichier de modèle fonctionne pour les types de nœuds non principaux. Les sections suivantes expliquent ces modifications en détail, et des appels seront effectués lorsque vous devrez apporter une modification.

Notes

Veillez à utiliser des noms propres au type de nœud d’origine, au groupe identique, à l’équilibreur de charge, à l’IP publique et au sous-réseau du type de nœud non principal d’origine, car ces ressources seront supprimées à une étape ultérieure du processus.

Créer un sous-réseau dans le réseau virtuel existant

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

Créer une nouvelle IP publique avec un domainNameLabel unique

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

Créer un nouvel équilibreur de charge pour l’IP publique

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

Créer un groupe de machines virtuelles identiques (avec les SKU de machine virtuelle et de système d’exploitation mises à niveau)

Ref type de nœud

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

Référence de la machine virtuelle

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

Référence (SKU) du système d’exploitation

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

En outre, assurez-vous d’inclure toutes les extensions supplémentaires requises pour votre charge de travail.

Ajouter un type de nœud non principal au cluster

Maintenant que le nouveau type de nœud (vmNodeType1Name) a son propre nom, sous-réseau, adresse IP, équilibreur de charge et groupe identique, il peut réutiliser toutes les autres variables du type de nœud d’origine (par exemple, nt0applicationEndPort, nt0applicationStartPort et nt0fabricTcpGatewayPort).

Dans le fichier de modèle existant, le paramètre isPrimary est défini sur true pour le guide Effectuer un scale-up sur un type de nœud principal de cluster Service Fabric. Modifiez isPrimary en false pour votre type de nœud non principal :

"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": false,
"reverseProxyEndpointPort": "[variables('nt0reverseProxyEndpointPort')]",
"vmInstanceCount": "[parameters('nt1InstanceCount')]"

Une fois que vous avez implémenté toutes les modifications apportées à vos fichiers de modèle et de paramètres, passez à la section suivante pour obtenir vos références Key Vault et déployer les mises à jour sur votre cluster.

Obtenir vos références Key Vault

Pour déployer la configuration mise à jour, vous aurez besoin de plusieurs références au certificat de cluster stocké dans votre coffre de clés. Le moyen le plus simple de rechercher ces valeurs consiste à utiliser le Portail Azure. Vous devez disposer des éléments suivants :

  • L’URL Key Vault de votre certificat de cluster. À partir de votre Key Vault dans Portail Azure, sélectionnez Certificats>Le certificat souhaité>Identificateur de secret :

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

  • L’empreinte de votre certificat de cluster. (Vous l’avez probablement déjà si vous vous êtes connecté au cluster initial pour vérifier son état d’intégrité.) À partir du même panneau de certificat (Certificats>Le certificat souhaité) dans Portail Azure, copiez l’empreinte SHA-1 X.509 (en hexadécimal) :

    $thumb = "BB796AA33BD9767E7DA27FE5182CF8FDEE714A70"

  • L’ID de ressource de votre Key Vault. À partir de votre Key Vault dans Portail Azure, sélectionnez Propriétés>ID de ressource :

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

Déployer le modèle mis à jour

Ajustez templateFilePath selon les besoins et exécutez la commande suivante :

# 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

Une fois le déploiement terminé, vérifiez à nouveau l’intégrité du cluster et assurez-vous que tous les nœuds des deux types de nœuds sont intègres.

Get-ServiceFabricClusterHealth

Migrer les charges de travail vers le nouveau type de nœud

Attendez que toutes les applications aient été déplacées vers le nouveau type de nœud et qu’elles soient saines.

Désactiver les nœuds dans le groupe identique du type de nœud d’origine

Une fois que tous les nœuds initiaux ont été migrés vers le nouveau groupe identique, vous pouvez désactiver les nœuds du groupe identique d’origine.

# 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
  }
}

Utilisez Service Fabric Explorer pour surveiller la progression des nœuds dans le groupe identique d’origine de l’état Désactivation à Désactivé. Attendez que tous les nœuds atteignent l’état Désactivé.

Arrêter les données sur les nœuds désactivés

Vous pouvez maintenant arrêter les données sur les nœuds désactivés.

# 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
  }
}

Supprimer le type de nœud d’origine et nettoyer ses ressources

Nous sommes prêts à supprimer le type de nœud d’origine et les ressources qui lui sont associées pour terminer la procédure de mise à l’échelle verticale.

Supprimer le groupe identique d’origine

Tout d’abord, supprimez le groupe identique de soutien du type de nœud.

$scaleSetName = "nt0vm"
$scaleSetResourceType = "Microsoft.Compute/virtualMachineScaleSets"
Remove-AzResource -ResourceName $scaleSetName -ResourceType $scaleSetResourceType -ResourceGroupName $resourceGroupName -Force

Supprimer l’adresse IP d’origine et les ressources de l’équilibreur de charge

Vous pouvez maintenant supprimer l’adresse IP d’origine et les ressources de l’équilibreur de charge. Au cours de cette étape, vous allez également mettre à jour le nom DNS.

Notes

Cette étape est facultative si vous utilisez déjà une IP publique et un équilibreur de charge du SKU Standard. Dans ce cas, vous pouvez avoir plusieurs types de nœuds/groupes identiques sous le même équilibreur de charge. Exécutez les commandes suivantes, en modifiant la valeur $lbname le cas échéant.

# 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"
$oldPublicIP = Get-AzPublicIpAddress -Name $oldPublicIpName  -ResourceGroupName $resourceGroupName
$nonPrimaryDNSName = $oldNonPrimaryPublicIP.DnsSettings.DomainNameLabel
$nonPrimaryDNSFqdn = $oldNonPrimaryPublicIP.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 = $nonPrimaryDNSName
$PublicIP.DnsSettings.Fqdn = $nonPrimaryDNSFqdn
Set-AzPublicIpAddress -PublicIpAddress $PublicIP

Supprimer l’état du nœud du type de nœud d’origine

Les nœuds du type de nœud d’origine affichent désormais Erreur pour leur état d’intégrité. Supprimez l’état du nœud du cluster.

# 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 doit maintenant refléter uniquement les cinq nœuds du nouveau type de nœud (nt1vm), tous avec des valeurs d’état d’intégrité OK. Nous y remédierons ensuite en mettant à jour le modèle pour qu’il reflète les dernières modifications et en le redéployant.

Mettre à jour le modèle de déploiement pour refléter le type de nœud non principal nouvellement mis à l’échelle

La plupart des modifications requises pour cette étape ont déjà été apportées dans le fichier de modèle Step3-CleanupOriginalPrimaryNodeType.json . Toutefois, une modification supplémentaire doit être apportée afin que le fichier de modèle fonctionne pour les types de nœuds non principaux. Les sections suivantes expliquent ces modifications en détail, et des appels seront effectués lorsque vous devrez apporter une modification.

Mettre à jour le point de terminaison de gestion du cluster

Mettez à jour le cluster managementEndpoint sur le modèle de déploiement pour référencer la nouvelle adresse IP (en mettant à jour vmNodeType0Name avec vmNodeType1Name).

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

Supprimer la référence au type de nœud d’origine

Supprimez la référence au type de nœud d’origine de la ressource Service Fabric dans le modèle de déploiement.

Dans le fichier de modèle existant, le paramètre isPrimary est défini sur true pour le guide Effectuer un scale-up sur un type de nœud principal de cluster Service Fabric. Modifiez isPrimary en false pour votre type de nœud non principal :

"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": false,
"reverseProxyEndpointPort": "[variables('nt0reverseProxyEndpointPort')]",
"vmInstanceCount": "[parameters('nt0InstanceCount')]"

Configurer des stratégies d’intégrité pour ignorer les erreurs existantes

Pour les clusters de durabilité Argent et supérieure uniquement, mettez à jour la ressource de cluster dans le modèle et configurez les stratégies d’intégrité de manière à ignorer l’intégrité de l’application fabric:/System en ajoutant applicationDeltaHealthPolicies sous les propriétés de la ressource de cluster, comme indiqué ci-dessous. La stratégie ci-dessous ignore les erreurs existantes, mais n’autorise pas les nouvelles erreurs d’intégrité.

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

Supprimer les ressources de prise en charge pour le type de nœud d’origine

Supprimez toutes les autres ressources associées au type de nœud d’origine à partir du modèle ARM et du fichier de paramètres. Supprimez le code suivant :

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

Déployer le modèle finalisé

Enfin, déployez le modèle Azure Resource Manager modifié.

# Deploy the updated template file
$templateFilePath = "C:\Step3-CleanupOriginalPrimaryNodeType"
New-AzResourceGroupDeployment `
    -ResourceGroupName $resourceGroupName `
    -TemplateFile $templateFilePath `
    -TemplateParameterFile $parameterFilePath `
    -CertificateThumbprint $thumb `
    -CertificateUrlValue $certUrlValue `
    -SourceVaultValue $sourceVaultValue `
    -Verbose

Notes

Cette étape prendra un certain temps, mais généralement pas plus de deux heures. Comme la mise à niveau modifie les paramètres d’InfrastructureService, un redémarrage du nœud est nécessaire. Dans ce cas, forceRestart est ignoré. Le paramètre upgradeReplicaSetCheckTimeout spécifie la durée maximale pendant laquelle Service Fabric doit attendre qu'une partition soit sécurisée, si ce n'est pas encore le cas. Une fois les contrôles de sécurité réussis pour toutes les partitions d'un nœud, Service Fabric procède à la mise à niveau sur ce nœud. La valeur du paramètre upgradeTimeout peut être réduite à 6 heures, mais pour une sécurité maximale, il convient d'utiliser 12 heures.

Une fois le déploiement terminé, vérifiez dans Portail Azure que l’état de la ressource Service Fabric est Prêt. Vérifiez que vous pouvez atteindre le nouveau point de terminaison de Service Fabric Explorer, que l’état d’intégrité du cluster est OK, et que toutes les applications déployées fonctionnent correctement.

Avec cela, vous avez mis à l’échelle verticalement un type de nœud non principal de cluster.

Étapes suivantes