Condividi tramite

Eseguire la migrazione del cluster di Service Fabric al supporto della zona di disponibilità

  • Articolo

Questa guida descrive come eseguire la migrazione dei cluster di Service Fabric dal supporto della zona non di disponibilità al supporto della disponibilità. Verranno illustrate le diverse opzioni per la migrazione. Un cluster di Service Fabric distribuito tra zone di disponibilità garantisce una disponibilità elevata dello stato del cluster.

È possibile eseguire la migrazione di cluster gestiti e non gestiti. Entrambi sono trattati in questo articolo.

Per i cluster non gestiti, vengono illustrati due scenari diversi:

  • Migrazione di un cluster con un servizio di bilanciamento del carico sku Standard e una risorsa IP. Questa configurazione supporta le zone di disponibilità senza la necessità di creare nuove risorse.
  • Migrazione di un cluster con un servizio di bilanciamento del carico SKU Basic e una risorsa IP. Questa configurazione non supporta le zone di disponibilità e richiede la creazione di nuove risorse.

Vedere le sezioni appropriate in ogni intestazione per lo scenario del cluster di Service Fabric.

Nota

Il vantaggio dell'estensione del tipo di nodo primario tra le zone di disponibilità è visibile solo per tre zone e non solo per due. Questo vale sia per i cluster gestiti che per i cluster non gestiti.

I modelli di esempio sono disponibili in Modelli di zona tra disponibilità di Service Fabric.

Prerequisiti

Cluster gestiti di Service Fabric

Obbligatorio:

Consigliato:

  • Lo SKU del cluster deve essere Standard.
  • Il tipo di nodo primario deve avere almeno nove nodi per ottenere la migliore resilienza, ma supporta il numero minimo di sei.
  • I tipi di nodo secondari devono avere almeno sei nodi per ottenere la migliore resilienza, ma supportano il numero minimo di tre.

Cluster non gestiti di Service Fabric

Obbligatorio: N/D.

Consigliato:

  • Livello di affidabilità del cluster impostato su Platinum.
  • Una singola risorsa IP pubblica con SKU Standard.
  • Una singola risorsa del servizio di bilanciamento del carico usando lo SKU Standard.
  • Un gruppo di sicurezza di rete (NSG) a cui fa riferimento la subnet in cui si distribuisce il set di scalabilità di macchine virtuali.

Servizio di bilanciamento del carico e risorsa IP dello SKU Standard esistente

Non esistono prerequisiti per questo scenario, perché presuppone che siano presenti le risorse necessarie esistenti.

Servizio di bilanciamento del carico e risorsa IP di base per SKU

  • Un nuovo servizio di bilanciamento del carico usando lo SKU Standard, distinto dal servizio di bilanciamento del carico dello SKU Basic esistente.
  • Una nuova risorsa IP usando lo SKU Standard, diversa dalla risorsa IP SKU Basic esistente.

Nota

Non è possibile aggiornare le risorse esistenti da uno SKU Basic a uno SKU Standard, quindi sono necessarie nuove risorse.

Requisiti del tempo di inattività

Cluster gestito di Service Fabric

La migrazione a una configurazione resiliente della zona può causare una breve perdita di connettività esterna tramite il servizio di bilanciamento del carico, ma non influisce sull'integrità del cluster. La perdita di connettività esterna si verifica quando è necessario creare un nuovo indirizzo IP pubblico per rendere la rete resiliente agli errori di zona. Pianificare la migrazione di conseguenza.

Cluster non gestito di Service Fabric

I tempi di inattività per la migrazione di cluster non gestiti di Service Fabric variano notevolmente in base al numero di macchine virtuali e domini di aggiornamento nel cluster. Gli ID sono raggruppamenti logici di macchine virtuali che determinano l'ordine in cui gli aggiornamenti vengono inseriti nelle macchine virtuali del cluster. Il tempo di inattività dipende anche dalla modalità di aggiornamento del cluster, che gestisce il modo in cui vengono elaborate le attività di aggiornamento per gli ID nel cluster. La sfZonalUpgradeMode proprietà , che controlla la modalità di aggiornamento, è descritta in modo più dettagliato nelle sezioni seguenti.

Migrazione per cluster gestiti di Service Fabric

Seguire i passaggi descritti in Eseguire la migrazione del cluster gestito di Service Fabric alla zona resiliente.

Opzioni di migrazione per cluster non gestiti di Service Fabric

Opzione di migrazione 1: abilitare più zone di disponibilità in un singolo set di scalabilità di macchine virtuali

Quando usare questa opzione

Questa soluzione consente agli utenti di estendersi su tre zone di disponibilità nello stesso tipo di nodo. Si tratta della topologia di distribuzione consigliata perché consente di distribuire tra zone di disponibilità mantenendo un singolo set di scalabilità di macchine virtuali.

Un modello di esempio completo è disponibile in GitHub.

È consigliabile usare questa opzione quando si dispone di un cluster non gestito di Service Fabric esistente con il servizio di bilanciamento del carico dello SKU Standard e le risorse IP di cui si vuole eseguire la migrazione. Se il cluster non gestito esistente dispone di risorse SKU basic, verrà visualizzata l'opzione di migrazione dello SKU Basic di seguito.

Come eseguire la migrazione del cluster non gestito di Service Fabric con il servizio di bilanciamento del carico dello SKU Standard e le risorse IP esistenti

Per abilitare le zone in un set di scalabilità di macchine virtuali:

Includere i tre valori seguenti nella risorsa set di scalabilità di macchine virtuali:

  • Il primo valore è la zones proprietà , che specifica il zone di disponibilità presenti nel set di scalabilità di macchine virtuali.

  • Il secondo valore è la singlePlacementGroup proprietà , che deve essere impostata su true. Il set di scalabilità esteso tra tre zone di disponibilità può aumentare fino a 300 macchine virtuali anche con singlePlacementGroup = true.

  • Il terzo valore è zoneBalance, che garantisce un bilanciamento della zona rigoroso. Questo valore deve essere true. Ciò garantisce che le distribuzioni di macchine virtuali tra zone non siano sbilanciate, il che significa che quando una zona scende, le altre due zone hanno macchine virtuali sufficienti per mantenere il cluster in esecuzione.

    Un cluster con una distribuzione di macchine virtuali sbilanciata potrebbe non sopravvivere a uno scenario di zona inattivo perché tale zona potrebbe avere la maggior parte delle macchine virtuali. La distribuzione di macchine virtuali non bilanciate tra zone comporta anche problemi di posizionamento dei servizi e gli aggiornamenti dell'infrastruttura rimangono bloccati. Altre informazioni su zoneBalancing.

Non è necessario configurare le FaultDomain sostituzioni e UpgradeDomain .

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

Nota

  • I cluster di Service Fabric devono avere almeno un tipo di nodo primario. Il livello di durabilità dei tipi di nodo primario deve essere Silver o superiore.
  • È consigliabile configurare una zona di disponibilità che si estende sul set di scalabilità di macchine virtuali con almeno tre zone di disponibilità, indipendentemente dal livello di durabilità.
  • Una zona di disponibilità che si estende su set di scalabilità di macchine virtuali con durabilità Silver o superiore deve avere almeno 15 macchine virtuali.
  • Una zona di disponibilità che si estende su set di scalabilità di macchine virtuali con durabilità Bronze deve avere almeno sei macchine virtuali.
Abilitare il supporto per più zone nel tipo di nodo di Service Fabric

Per supportare più zone di disponibilità, è necessario abilitare il tipo di nodo di Service Fabric.

  • Il primo valore è multipleAvailabilityZones, che deve essere impostato su true per il tipo di nodo.

  • Il secondo valore è e è sfZonalUpgradeMode facoltativo. Questa proprietà non può essere modificata se un tipo di nodo con più zone di disponibilità è già presente nel cluster. Questa proprietà controlla il raggruppamento logico delle macchine virtuali negli ID.

    • Se questo valore è impostato su Parallel: le macchine virtuali nel tipo di nodo vengono raggruppate in ID e ignorano le informazioni sulla zona in cinque ID. Questa impostazione determina l'aggiornamento degli ID in tutte le zone contemporaneamente. Anche se questa modalità di distribuzione è più veloce per gli aggiornamenti, non è consigliabile perché va contro le linee guida SDP, che indica che gli aggiornamenti devono essere applicati a un fuso alla volta.

    • Se questo valore viene omesso o impostato su Hierarchical: le macchine virtuali vengono raggruppate per riflettere la distribuzione di zona in un massimo di 15 ID. Ognuna delle tre zone ha cinque ID. Ciò garantisce che le zone vengano aggiornate una alla volta, passando alla zona successiva solo dopo aver completato cinque ID all'interno della prima zona. Il processo di aggiornamento è più sicuro per il cluster e l'applicazione utente.

    Questa proprietà definisce solo il comportamento di aggiornamento per l'applicazione e gli aggiornamenti del codice di Service Fabric. Gli aggiornamenti del set di scalabilità di macchine virtuali sottostanti sono ancora paralleli in tutte le zone di disponibilità. Questa proprietà non influisce sulla distribuzione definita dall'utente per i tipi di nodo che non dispongono di più zone abilitate.

  • Il terzo valore è vmssZonalUpgradeMode, è facoltativo e può essere aggiornato in qualsiasi momento. Questa proprietà definisce lo schema di aggiornamento per il set di scalabilità di macchine virtuali in parallelo o sequenziale in zone di disponibilità.

    • Se questo valore è impostato su Parallel: tutti gli aggiornamenti del set di scalabilità vengono eseguiti in parallelo in tutte le zone. Questa modalità di distribuzione è più veloce per gli aggiornamenti e pertanto non è consigliabile perché è in linea con le linee guida SDP, che indica che gli aggiornamenti devono essere applicati a un solo fuso alla volta.
    • Se questo valore viene omesso o impostato su Hierarchical: in questo modo le zone vengono aggiornate una alla volta, passando alla zona successiva solo dopo aver completato cinque ID all'interno della prima zona. Questo processo di aggiornamento è più sicuro per il cluster e l'applicazione utente.

Importante

La versione dell'API della risorsa cluster di Service Fabric deve essere 2020-12-01-preview o successiva.

La versione del codice del cluster deve essere almeno 8.1.321 o successiva.

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

Nota

  • Gli indirizzi IP pubblici e le risorse del servizio di bilanciamento del carico devono usare lo SKU Standard descritto in precedenza nell'articolo.
  • La multipleAvailabilityZones proprietà nel tipo di nodo può essere definita solo quando viene creato il tipo di nodo e non può essere modificata in un secondo momento. I tipi di nodo esistenti non possono essere configurati con questa proprietà.
  • Quando sfZonalUpgradeMode viene omesso o impostato su Hierarchical, le distribuzioni di cluster e applicazioni saranno più lente perché nel cluster sono presenti più domini di aggiornamento. È importante modificare correttamente i timeout dei criteri di aggiornamento per tenere conto del tempo di aggiornamento necessario per 15 domini di aggiornamento. I criteri di aggiornamento per l'app e il cluster devono essere aggiornati per assicurarsi che la distribuzione non superi il limite di tempo di distribuzione del servizio risorse di Azure di 12 ore. Ciò significa che la distribuzione non deve richiedere più di 12 ore per 15 UD, ovvero non deve richiedere più di 40 minuti per ogni UD.
  • Impostare il livello di affidabilità del cluster per Platinum assicurarsi che il cluster superi lo scenario di un'unica zona verso il basso.
  • L'aggiornamento di DurabilityLevel per un tipo di nodo con multipleAvailabilityZones non è supportato. Creare invece un nuovo tipo di nodo con maggiore durabilità.
  • SF supporta solo 3 zone di disponibilità. Al momento non è supportato un numero più elevato.

Suggerimento

È consigliabile impostarla sfZonalUpgradeModeHierarchical su o ometterla. La distribuzione seguirà la distribuzione a livello di zona delle macchine virtuali e influirà su una quantità minore di repliche o istanze, rendendole più sicure. Usare sfZonalUpgradeMode impostato su Parallel se la velocità di distribuzione è una priorità o solo i carichi di lavoro senza stato vengono eseguiti nel tipo di nodo con più zone di disponibilità. In questo modo, la procedura definita dall'utente viene eseguita in parallelo in tutte le zone di disponibilità.

Eseguire la migrazione al tipo di nodo con più zone di disponibilità

Per tutti gli scenari di migrazione, è necessario aggiungere un nuovo tipo di nodo che supporta più zone di disponibilità. Non è possibile eseguire la migrazione di un tipo di nodo esistente per supportare più zone. L'articolo Aumentare le prestazioni di un tipo di nodo primario del cluster di Service Fabric include passaggi dettagliati per aggiungere un nuovo tipo di nodo e le altre risorse necessarie per il nuovo tipo di nodo, ad esempio le risorse IP e di bilanciamento del carico. Questo articolo descrive anche come ritirare il tipo di nodo esistente dopo l'aggiunta di un nuovo tipo di nodo con più zone di disponibilità al cluster.

  • Migrazione da un tipo di nodo che usa il servizio di bilanciamento del carico di base e le risorse IP: questo processo è già descritto in una sezione secondaria seguente per la soluzione con un tipo di nodo per ogni zona di disponibilità.

    Per il nuovo tipo di nodo, l'unica differenza è che è presente un solo set di scalabilità di macchine virtuali e un tipo di nodo per tutti i zone di disponibilità anziché uno per ogni zona di disponibilità.

  • Migrazione da un tipo di nodo che usa il servizio di bilanciamento del carico dello SKU Standard e le risorse IP con un gruppo di sicurezza di rete: seguire la stessa procedura descritta in precedenza. Non è tuttavia necessario aggiungere nuove risorse di bilanciamento del carico, IP e gruppo di sicurezza di rete. Le stesse risorse possono essere riutilizzate nel nuovo tipo di nodo.

Se si verificano problemi, contattare il supporto per ricevere assistenza.

Opzione di migrazione 2: distribuire le zone aggiungendo un set di scalabilità di macchine virtuali a ogni zona

Quando usare questa opzione

Questa è la configurazione disponibile a livello generale al momento.

Per estendere un cluster di Service Fabric in zone di disponibilità, è necessario creare un tipo di nodo primario in ogni zona di disponibilità supportata dall'area. In questo modo i nodi di inizializzazione vengono distribuiti uniformemente in ogni tipo di nodo primario.

La topologia consigliata per il tipo di nodo primario richiede quanto segue:

  • Tre tipi di nodo contrassegnati come primari
    • Ogni tipo di nodo deve essere mappato al proprio set di scalabilità di macchine virtuali che si trova in una zona diversa.
    • Ogni set di scalabilità di macchine virtuali deve avere almeno cinque nodi (durabilità Silver).

È consigliabile usare questa opzione quando si dispone di un cluster non gestito di Service Fabric esistente con il servizio di bilanciamento del carico dello SKU Standard e le risorse IP di cui si vuole eseguire la migrazione. Se il cluster non gestito esistente dispone di risorse SKU basic, verrà visualizzata l'opzione di migrazione dello SKU Basic di seguito.

Come eseguire la migrazione del cluster non gestito di Service Fabric con il servizio di bilanciamento del carico dello SKU Standard e le risorse IP esistenti

Abilitare le zone in un set di scalabilità di macchine virtuali

Per abilitare una zona in un set di scalabilità di macchine virtuali, includere i tre valori seguenti nella risorsa set di scalabilità di macchine virtuali:

  • Il primo valore è la zones proprietà , che specifica la zona di disponibilità in cui viene distribuito il set di scalabilità di macchine virtuali.
  • Il secondo valore è la singlePlacementGroup proprietà , che deve essere impostata su true.
  • Il terzo valore è la faultDomainOverride proprietà nell'estensione del set di scalabilità di macchine virtuali di Service Fabric. Questa proprietà deve includere solo la zona in cui verrà inserito questo set di scalabilità di macchine virtuali. Esempio: "faultDomainOverride": "az1". Tutte le risorse del set di scalabilità di macchine virtuali devono essere inserite nella stessa area perché i cluster di Azure Service Fabric non dispongono del supporto tra aree.
{
  "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"
          }
        }
      ]
    }
  }
}
Abilitare più tipi di nodo primario nella risorsa cluster di Service Fabric

Per impostare uno o più tipi di nodo come primario in una risorsa cluster, impostare la isPrimary proprietà su true. Quando si distribuisce un cluster di Service Fabric in zone di disponibilità, è necessario avere tre tipi di nodo in zone distinte.

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

Se si verificano problemi, contattare il supporto per ricevere assistenza.

Opzione di migrazione: cluster non gestito di Service Fabric con il servizio di bilanciamento del carico dello SKU Basic e le risorse IP

Quando usare questa opzione

È consigliabile usare questa opzione quando si dispone di un cluster non gestito di Service Fabric esistente con il servizio di bilanciamento del carico sku Basic e le risorse IP di cui si vuole eseguire la migrazione. Se il cluster non gestito esistente dispone di risorse SKU Standard, verranno visualizzate le opzioni di migrazione precedenti. Se non è ancora stato creato il cluster non gestito, ma si sa che sarà abilitato per AZ, crearlo con le risorse SKU Standard.

Come eseguire la migrazione del cluster non gestito di Service Fabric con il servizio di bilanciamento del carico dello SKU Basic e le risorse IP

Per eseguire la migrazione di un cluster che usa un servizio di bilanciamento del carico e un indirizzo IP con uno SKU di base, è prima necessario creare un servizio di bilanciamento del carico completamente nuovo e una risorsa IP usando lo SKU standard. Non è possibile aggiornare queste risorse.

Fare riferimento al nuovo servizio di bilanciamento del carico e all'indirizzo IP nei nuovi tipi di nodo zona tra disponibilità che si desidera usare. Nell'esempio precedente sono state aggiunte tre nuove risorse del set di scalabilità di macchine virtuali nelle zone 1, 2 e 3. Questi set di scalabilità di macchine virtuali fanno riferimento al servizio di bilanciamento del carico e all'INDIRIZZO IP appena creati e sono contrassegnati come tipi di nodo primari nella risorsa cluster di Service Fabric.

  1. Per iniziare, aggiungere le nuove risorse al modello di Azure Resource Manager esistente. Tali risorse includono:

    • Una risorsa IP pubblico con SKU Standard
    • Una risorsa del servizio di bilanciamento del carico con SKU Standard
    • Un gruppo di sicurezza di rete a cui fa riferimento la subnet in cui si distribuisce il set di scalabilità di macchine virtuali
    • Tre tipi di nodo contrassegnati come primari
      • Ogni tipo di nodo deve essere mappato al proprio set di scalabilità di macchine virtuali che si trova in una zona diversa.
      • Ogni set di scalabilità di macchine virtuali deve avere almeno cinque nodi (durabilità Silver).

    Un esempio di queste risorse è disponibile nel modello di esempio.

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

  2. Al termine della distribuzione delle risorse, è possibile disabilitare i nodi nel tipo di nodo primario dal cluster originale. Quando i nodi sono disabilitati, i servizi di sistema eseguono la migrazione al nuovo tipo di nodo primario distribuito in precedenza.

    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. Dopo aver disabilitato tutti i nodi, i servizi di sistema verranno eseguiti nel tipo di nodo primario, che viene distribuito tra le zone. È quindi possibile rimuovere i nodi disabilitati dal cluster. Dopo aver rimosso i nodi, è possibile rimuovere l'indirizzo IP, il servizio di bilanciamento del carico e le risorse del set di scalabilità di macchine virtuali originale.

    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. Rimuovere quindi i riferimenti a queste risorse dal modello di Resource Manager distribuito.

  5. Aggiornare infine il nome DNS e l'indirizzo IP pubblico.

$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

Se si verificano problemi, contattare il supporto per ricevere assistenza.

Passaggi successivi