Partager via

Migrer votre cluster Service Fabric vers la prise en charge des zones de disponibilité

  • Article

Ce guide explique comment migrer des clusters Service Fabric de la prise en charge de la zone de non-disponibilité vers la prise en charge de la disponibilité. Nous allons parcourir les différentes options de migration. Un cluster Service Fabric distribué entre plusieurs zones de disponibilité garantit une haute disponibilité de l’état du cluster.

Vous pouvez migrer des clusters managés comme non managés. Les deux solutions sont traitées dans cet article.

Pour les clusters non managés, nous étudions deux scénarios différents :

  • Migrer un cluster avec un équilibreur de charge et une ressource IP de référence SKU Standard. Cette configuration prend en charge les zones de disponibilité sans avoir à créer de nouvelles ressources.
  • Migrer un cluster avec un équilibreur de charge et une ressource IP de référence SKU Essentiel. Cette configuration ne prend pas en charge les zones de disponibilité et nécessite la création de nouvelles ressources.

Consultez les sections appropriées sous chaque en-tête pour votre scénario de cluster Service Fabric.

Remarque

L’avantage de répartir le type de nœud principal sur plusieurs zones de disponibilité n’est visible que pour trois zones et pas seulement deux. Cela est vrai pour les clusters managés comme non managés.

Des exemples de modèles sont disponibles dans Modèles de zones de disponibilité croisée Service Fabric.

Prérequis

Clusters managés Service Fabric

Obligatoire :

Recommandé :

  • Le niveau tarifaire du cluster doit être Standard.
  • Le type de nœud principal doit avoir au moins neuf nœuds pour une meilleure résilience, mais prend en charge un nombre minimum de six.
  • Les types de nœuds secondaires doivent avoir au moins six nœuds pour une meilleure résilience, mais prend en charge un nombre minimum de trois.

Clusters non managés Service Fabric

Obligatoire : N/A.

Recommandé :

  • Le niveau de fiabilité du cluster défini sur Platinum.
  • Une ressource d’adresse IP publique unique utilisant une référence SKU Standard.
  • Une ressource d’équilibreur de charge unique utilisant une référence SKU Standard.
  • Un groupe de sécurité réseau (NSG) référencé par le sous-réseau dans lequel vous déployez vos groupes de machines virtuelles identiques.

Équilibreur de charge et ressource IP de référence SKU Standard existants

Il n’existe aucun prérequis pour ce scénario, car il suppose que les ressources requises existent.

Ressource d’équilibreur de charge et d’adresse IP de référence SKU Essentiel

  • Un nouvel équilibreur de charge utilisant la référence SKU Standard, distinct de votre équilibreur de charge de référence SKU Essentiel existant.
  • Nouvelle ressource IP utilisant la référence SKU Standard, distincte de votre ressource IP de référence SKU Essentiel existante.

Remarque

Il n’est pas possible de mettre à niveau vos ressources existantes d’une référence SKU Essentiel vers une référence SKU Standard. De nouvelles ressources sont donc requises.

Exigences en matière de temps d’arrêt

Cluster managé Service Fabric

La migration vers une configuration résiliente aux zones peut occasionner une brève perte de connectivité externe via l’équilibreur de charge, mais n’aura aucune incidence sur l’intégrité du cluster. La perte de connectivité externe se produit lorsqu’une nouvelle adresse IP publique doit être créée afin de rendre la mise en réseau résiliente aux défaillances de zone. Planifiez la migration en conséquence.

Cluster non managé Service Fabric

Le temps d’arrêt pour la migration de clusters non managés Service Fabric varie largement en fonction du nombre de machines virtuelles et de domaines de mise à jour (Upgrade Domains/UD) de votre cluster. Les UD sont des regroupements logiques de machines virtuelles qui déterminent l’ordre dans lequel les mises à jour sont envoyées aux machines virtuelles de votre cluster. Le temps d’arrêt est également affecté par le mode de mise à jour de votre cluster, qui gère la façon dont les tâches de mise à jour des UD de votre cluster sont traitées. La propriété sfZonalUpgradeMode, qui contrôle le mode de mise à jour, est décrite plus en détail dans les sections suivantes.

Migration des clusters managés Service Fabric

Suivez les étapes de migration dans Migrer un cluster managé Service Fabric vers une résilience de zone.

Options de migration des clusters non managés Service Fabric

Option de migration 1 : activer plusieurs zones de disponibilité dans un même groupe de machines virtuelles identiques

Quand utiliser cette option

Cette solution permet aux utilisateurs de couvrir trois zones de disponibilité dans le même type de nœud. Il s’agit de la topologie de déploiement recommandée, car elle vous permet un déploiement sur plusieurs zones de disponibilité tout en conservant un seul groupe de machines virtuelles identiques.

Un exemple de modèle complet est disponible sur GitHub.

Vous devez utiliser cette option lorsque vous disposez d’un cluster Service Fabric non managé existant avec l’équilibreur de charge et les ressources IP de référence SKU Standard que vous souhaitez migrer. Si votre cluster non managé existant possède des ressources SKU Essentiel, vous devez voir l’option de migration SKU De base ci-dessous.

Comment migrer votre cluster Service Fabric non managé avec un équilibreur de charge et des ressources IP de référence SKU Standard existants

Pour activer des zones sur un groupe de machines virtuelles identiques :

Incluez les trois valeurs suivantes dans la ressource du groupe de machines virtuelles identiques :

  • La première valeur est la propriété zones, qui spécifie les zones de disponibilité dans le groupe de machines virtuelles identiques.

  • La deuxième valeur est la propriété singlePlacementGroup, qui doit être définie sur true. Le groupe identique qui s’étend sur trois zones de disponibilité peut monter en puissance jusqu’à 300 machines virtuelles même avec singlePlacementGroup = true.

  • La troisième valeur est zoneBalance, qui garantit un strict équilibrage des zones. Cette valeur doit être true. Cela garantit que les distributions de machines virtuelles entre les zones ne sont pas déséquilibrées, ce qui signifie que lorsqu’une zone tombe en panne, les deux autres zones ont suffisamment de machines virtuelles pour maintenir l’exécution du cluster.

    Un cluster avec une distribution de machines virtuelles déséquilibrée peut ne pas survivre à un scénario de zone défaillante, car cette zone peut avoir la majorité des machines virtuelles. La distribution déséquilibrée des machines virtuelles entre les zones entraînera également des problèmes liés au placement de services et au blocage des mises à jour de l’infrastructure. Découvrez zoneBalancing.

Vous n’avez pas besoin de configurer les remplacements FaultDomain et UpgradeDomain.

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

Notes

  • Les clusters Service Fabric doivent avoir au moins un nodeType principal. Le niveau de durabilité des types de nœuds principaux doit être Silver ou supérieur.
  • Une zone de disponibilité qui s’étend sur un groupe de machines virtuelles identiques doit être configurée avec au moins trois zones de disponibilité, quel que soit le niveau de durabilité.
  • Une zone de disponibilité qui s’étend sur un groupe de machines virtuelles identiques avec une durabilité Silver ou supérieure doit comprendre au moins 15 machines virtuelles.
  • Une zone de disponibilité qui s’étend sur un groupe de machines virtuelles identiques avec une durabilité Bronze doit comprendre au moins six machines virtuelles.
Activation de la prise en charge de plusieurs zones dans le nodeType Service Fabric

Pour prendre en charge plusieurs zones de disponibilité, le type de nœud Service Fabric doit être activé.

  • La première valeur est multipleAvailabilityZones, qui doit être définie sur true pour le type de nœud.

  • La deuxième valeur, sfZonalUpgradeMode, est facultative. Il n’est pas possible de modifier cette propriété si un type de nœud avec plusieurs zones de disponibilité est déjà présent dans le cluster. La propriété contrôle le regroupement logique des machines virtuelles dans les UD.

    • Si cette valeur est définie sur Parallel : les machines virtuelles sous le type de nœud sont regroupées en UD et ignorent les informations de zone dans cinq UD. Ce paramètre entraîne la mise à niveau simultanée des UD dans toutes les zones. Bien que ce mode de déploiement soit plus rapide pour les mises à jour, nous ne le recommandons pas car il va à l’encontre des instructions SDP, qui stipulent que les mises à jour doivent être appliquées à une zone à la fois.

    • Si la valeur est omise ou définie sur Hierarchical : les machines virtuelles sont regroupées pour refléter la distribution zonale jusqu’à 15 UD. Chacune des trois zones a cinq UD. Cela permet de s’assurer que les zones sont mises à jour l’une après l’autre, en passant à la zone suivante uniquement après avoir terminé cinq UD au sein de la première zone. Le processus de mise à jour est plus sûr pour le cluster et l’application utilisateur.

    Cette propriété définit uniquement le comportement de mise à niveau pour l’application Service Fabric et les mises à niveau de code. Les mises à jour du groupe de machines virtuelles identiques sous-jacentes seront toujours parallèles dans toutes les zones de disponibilité. Cette propriété n’affecte pas la distribution d’UD pour les types de nœuds pour lesquels plusieurs zones ne sont pas activées.

  • La troisième valeur est vmssZonalUpgradeMode. Elle est facultative et peut être mise à jour à tout moment. Cette propriété définit que le schéma de mise à jour pour le groupe de machines virtuelles identiques se produise en parallèle ou de manière séquentielle entre les zones de disponibilité.

    • Si cette valeur est définie sur Parallel : toutes les mises à jour de groupe identique se produisent en parallèle dans toutes les zones. Ce mode de déploiement est plus rapide pour les mises à jour, et donc nous ne le recommandons, car il va à l’encontre des instructions SDP qui stipulent que les mises à jour doivent être appliquées à une zone à la fois.
    • Si la valeur est omise ou définie sur Hierarchical : Cela permet de s’assurer que les zones sont mises à jour l’une après l’autre, en passant à la zone suivante uniquement après avoir terminé cinq UD au sein de la première zone. Ce processus de mise à jour est plus sûr pour le cluster et l’application utilisateur.

Important

La version d’API de la ressource de cluster Service Fabric doit être « 2020-12-01-preview » ou une version ultérieure.

La version de code du cluster doit être au moins 8.1.321 ou une version ultérieure.

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

Remarque

  • Les ressources d’adresse IP publique et d’équilibreur de charge doivent utiliser la référence (SKU) Standard, comme décrit précédemment dans l’article.
  • La propriété multipleAvailabilityZones sur le type de nœud ne peut être définie que lorsque le type de nœud est créé et ne peut pas être modifié ultérieurement. Des types de nœuds existants ne peuvent pas être configurés avec cette propriété.
  • Quand sfZonalUpgradeMode est omis ou défini sur Hierarchical, les déploiements de cluster et d’application sont plus lents, car il y a plus de domaines de mise à niveau dans le cluster. Il est important d’ajuster correctement les délais d’expiration de stratégie de mise à niveau pour prendre en compte la durée de mise à niveau requise pour 15 domaines de mise à niveau. La stratégie de mise à niveau pour l’application et le cluster doit être mise à jour pour s’assurer que le déploiement ne dépasse pas les délais d’attente de déploiement du service Azure Resource de 12 heures. Cela signifie que le déploiement ne doit pas durer plus de 12 heures pour 15 UD (autrement dit, il ne doit pas prendre plus de 40 minutes pour chaque UD).
  • Définissez le niveau de fiabilité du cluster sur Platinum pour garantir que le cluster résiste au scénario à une seule zone.
  • La mise à niveau de DurabilityLevel pour un type de nœud avec plusieursAvailabilityZones n’est pas prise en charge. Veuillez créer un type de nœud avec la durabilité supérieure à la place.
  • SF prend en charge seulement 3 AvailabilityZones. Tout nombre plus élevé n’est pas pris en charge pour l’instant.

Conseil

Nous vous recommandons de définir la valeur sfZonalUpgradeMode sur Hierarchical ou de l’omettre. Le déploiement suivra la distribution zonale des machines virtuelles ayant un impact sur un plus petit nombre de réplicas et/ou d’instances, rendant celles-ci plus sûres. Utilisez sfZonalUpgradeMode défini sur Parallel si la vitesse de déploiement est une priorité ou si seule une charge de travail sans état s’exécute sur le type de nœud avec plusieurs zones de disponibilité. Cela provoque l’exécution en parallèle des UD dans toutes les zones de disponibilité.

Migration vers le type de nœud avec plusieurs zones de disponibilité

Pour tous les scénarios de migration, vous devez ajouter un nouveau type de nœud qui prend en charge plusieurs zones de disponibilité. Un type de nœud existant ne peut pas être migré pour prendre en charge plusieurs zones. L’article Monter en puissance un type de nœud principal de cluster Service Fabric comprend des étapes détaillées pour ajouter un nouveau type de nœud et les autres ressources requises pour le nouveau type de nœud, telles que les ressources d’équilibrage de charge et d’adresse IP. Le même article décrit également comment retirer le type de nœud existant après l’ajout du type de nœud avec plusieurs zones de disponibilité au cluster.

  • Migration à partir d’un type de nœud qui utilise l’équilibrage de charge et les ressources IP de base : ce processus est déjà décrit dans la sous-section ci-dessous pour la solution avec un type de nœud par zone de disponibilité.

    Pour le nouveau type de nœud, la seule différence est qu’il n’y a qu’un seul groupe de machines virtuelles identiques et un seul type de nœud pour toutes les zones de disponibilité, au lieu d’un par zone de disponibilité.

  • Migration à partir d’un type de nœud qui utilise l’équilibrage de charge et les ressources IP de référence SKU standard avec un groupe de sécurité réseau : suivez la même procédure que celle décrite précédemment. Toutefois, il n’est pas nécessaire d’ajouter de nouvelles ressources d’équilibrage de charge, d’adresse IP et de groupe de sécurité réseau. Les mêmes ressources peuvent être réutilisées dans le nouveau type de nœud.

Si vous rencontrez des problèmes, contactez le support technique.

Option de migration 2 : déployer des zones en épinglant un groupe de machines virtuelles identiques à chaque zone

Quand utiliser cette option

Il s’agit de la configuration généralement disponible actuellement.

Pour étendre un cluster Service Fabric sur des zones de disponibilité, vous devez créer un type de nœud principal dans chaque zone de disponibilité prise en charge par la région. Les nœuds initiaux sont ainsi distribués uniformément sur chacun des types de nœuds principaux.

La topologie recommandée du type de nœud principal nécessite les éléments suivants :

  • Trois types de nœuds marqués comme principaux
    • Chaque type de nœud doit être mappé à son propre groupe de machines virtuelles identiques situé dans une zone différente.
    • Chaque groupe de machines virtuelles identiques doit avoir au moins cinq nœuds (durabilité Silver).

Vous devez utiliser cette option lorsque vous disposez d’un cluster Service Fabric non managé existant avec l’équilibreur de charge et les ressources IP de référence SKU Standard que vous souhaitez migrer. Si votre cluster non managé existant possède des ressources SKU Essentiel, vous devez voir l’option de migration SKU De base ci-dessous.

Comment migrer votre cluster Service Fabric non managé avec un équilibreur de charge et des ressources IP de référence SKU Standard existants

Activer des zones sur un groupe de machines virtuelles identiques

Pour activer une zone sur un groupe de machines virtuelles identiques, incluez les trois valeurs suivantes dans la ressource de groupe de machines virtuelles identiques :

  • La première valeur est la propriété zones, qui spécifie la zone de disponibilité sur laquelle le groupe de machines virtuelles identiques est déployé.
  • La deuxième valeur est la propriété singlePlacementGroup, qui doit être définie sur true.
  • La troisième valeur est la propriété faultDomainOverride dans l’extension de groupe de machines virtuelles identiques Service Fabric. Cette propriété ne doit inclure que la zone dans laquelle ce groupe de machines virtuelles identiques sera placé. Exemple : "faultDomainOverride": "az1". Toutes les ressources de groupe de machines virtuelles identiques doivent être placées dans la même région car les clusters Azure Service Fabric ne disposent pas de la prise en charge inter-régions.
{
  "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"
          }
        }
      ]
    }
  }
}
Activation de plusieurs types de nœuds principaux dans la ressource de cluster Service Fabric

Pour définir un ou plusieurs types de nœuds comme principal dans une ressource de cluster, définissez la propriété isPrimary sur true. Lorsque vous déployez un cluster Service Fabric entre des zones de disponibilité, vous devez avoir trois types de nœuds dans des zones distinctes.

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

Si vous rencontrez des problèmes, contactez le support technique.

Option de migration : cluster non managé Service Fabric avec un équilibreur de charge et des ressources IP de référence SKU Essentiel

Quand utiliser cette option

Vous devez utiliser cette option lorsque vous disposez d’un cluster non managé Service Fabric existant avec équilibreur de charge et ressources IP de référence SKU Essentiel que vous voulez migrer. Si votre cluster non managé existant dispose de ressources de référence SKU Standard, vous devez consulter les options de migration ci-dessus. Si vous n’avez pas encore créé votre cluster non managé, mais que vous savez qu’il devra être activé par zone de disponibilité, créez-le avec des ressources de référence SKU Standard.

Comment migrer votre cluster non managé Service Fabric avec équilibreur de charge et ressources IP de référence SKU Essentiel

Pour migrer un cluster qui utilisait un Load Balancer et une adresse IP avec une référence SKU de base, vous devez tout d’abord créer une toute nouvelle ressource de Load Balancer et d’adresse à l’aide de la référence SKU standard. Il n’est pas possible de mettre à jour ces ressources.

Référencez le nouvel équilibreur de charge et l’adresse IP dans les nouveaux types de nœuds de zone de disponibilité croisée que vous souhaitez utiliser. Dans l’exemple précédent, trois nouvelles ressources de groupe de machines virtuelles identiques ont été ajoutées dans les zones 1, 2 et 3. Ces groupes de machines virtuelles identiques font référence à l’équilibreur de charge et à l’adresse IP nouvellement créés, et sont marqués comme des types de nœuds principaux dans la ressource de cluster Service Fabric.

  1. Pour commencer, ajoutez les nouvelles ressources à votre modèle Azure Resource Manager existant. Ces ressources incluent :

    • Une ressource d’adresse IP publique utilisant une référence SKU standard
    • Une ressource de Load Balancer utilisant une référence SKU standard
    • Un NSG référencé par le sous-réseau dans lequel vous déployez vos groupes de machines virtuelles identiques
    • Trois types de nœuds marqués comme principaux
      • Chaque type de nœud doit être mappé à son propre groupe de machines virtuelles identiques situé dans une zone différente.
      • Chaque groupe de machines virtuelles identiques doit avoir au moins cinq nœuds (durabilité Silver).

    Vous trouverez un exemple de ces ressources dans l’exemple de modèle.

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

  2. Une fois le déploiement des ressources terminé, vous pouvez désactiver les nœuds dans le type de nœud principal du cluster d’origine. Comme les nœuds sont désactivés, les services système migrent vers le nouveau type de nœud principal que vous avez déployé précédemment.

    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. Lorsque tous les nœuds sont désactivés, les services système s’exécutent sur le type de nœud principal, qui s’étend entre des zones. Vous pouvez ensuite supprimer les nœuds désactivés du cluster. Lorsque les nœuds sont supprimés, vous pouvez supprimer les ressources d’adresse IP, d’équilibreur de charge et de groupe de machines virtuelles identiques d’origine.

    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. Ensuite, supprimez les références à ces ressources du modèle Resource Manager que vous avez déployé.

  5. Enfin, mettez à jour le nom DNS et l’adresse IP publique.

$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

Si vous rencontrez des problèmes, contactez le support technique.

Étapes suivantes