Distribuire un cluster di Azure Service Fabric tra zone di disponibilità

Le zone di disponibilità in Azure offrono una soluzione a disponibilità elevata che consente di proteggere le applicazioni e i dati da eventuali errori dei data center. Una zona di disponibilità identifica una posizione fisica univoca all’interno di un’area Azure, dotata di alimentazione, raffreddamento e rete indipendenti.

Azure Service Fabric fornisce i due metodi di configurazione descritti nell'articolo seguente che consentono di supportare cluster che si estendono tra le zone di disponibilità. Le zone di disponibilità sono disponibili solo nelle aree selezionate. Per ulteriori informazioni, vedere Panoramica delle zone di disponibilità.

I modelli di esempio sono disponibili in Modelli delle zone di disponibilità di Service Fabric.

Topologia per lo spanning di un tipo di nodo primario tra le zone di disponibilità

Nota

Il vantaggio di eseguire lo spanning del tipo di nodo primario tra le zone di disponibilità è in realtà evidente solo per tre zone e non solo per due.

• Livello di affidabilità del cluster impostato su Platinum
• Risorsa IP pubblico dello SKU Standard.
• Risorsa servizio di bilanciamento del carico dello SKU Standard
• Gruppo di sicurezza di rete (NSG) a cui fa riferimento la subnet in cui si distribuiscono i set di scalabilità di macchine virtuali

Nota

La proprietà del gruppo di posizionamento singolo del set di scalabilità di macchine virtuali deve essere impostata su true.

L'elenco di nodi di esempio seguente illustra i formati FD/UD in un set di scalabilità di macchine virtuali che si estende su zone diverse:

Distribuzione delle repliche dei servizi tra le zone

Quando un servizio viene distribuito nei tipi di nodo che si estendono su zone di disponibilità, le repliche vengono posizionate in modo che si trovino in zone distinte. I domini di errore nei nodi in ognuno di questi tipi di nodo vengono configurati con le informazioni sulla zona, ovvero FD = fd:/zone1/1 e così via. Ad esempio, per cinque repliche o istanze dei servizi, la distribuzione è 2-2-1 e il runtime tenterà di garantire la stessa distribuzione tra le zone.

Configurazione delle repliche dei servizi utente

I servizi utente con stato distribuiti nei tipi di nodo nelle zone di disponibilità devono essere configurati in questo modo: numero di repliche con destinazione = 9, min = 5. Questa configurazione consente il funzionamento dei servizi anche nel caso in cui una zona diventi inattiva perché sei repliche sono ancora attive nelle altre due zone. Anche un aggiornamento dell'applicazione avrà un esito positivo in questo scenario.

Affidabilità a livello di cluster

Questo valore definisce il numero di nodi di inizializzazione nel cluster e le dimensioni delle repliche dei servizi di sistema. Una configurazione tra zone di disponibilità include un numero più elevato di nodi, distribuiti tra le zone, che ne abilita la resilienza.

Un valore ReliabilityLevel più alto garantisce che siano presenti più nodi di inizializzazione e repliche dei servizi di sistema e che gli stessi siano distribuiti in modo uniforme tra le zone, in modo che un eventuale errore in una zona non abbia alcun effetto sul cluster e i servizi di sistema. ReliabilityLevel = Platinum (scelta consigliata) garantisce che siano presenti nove nodi di inizializzazione distribuiti tra le zone del cluster, con tre valori di inizializzazione in ogni zona.

Scenario con zona inattiva

Quando una zona diventa inattiva, tutti i nodi e le repliche dei servizi di tale zona vengono visualizzati come inattivi. I servizi continuano tuttavia a rispondere poiché nelle altre zone sono presenti delle repliche. Le repliche primarie effettuano il failover nelle zone funzionanti. I servizi sembrano essere nello stato di avviso perché il numero di repliche di destinazione non è ancora stato raggiunto e il numero di macchine virtuali è ancora superiore alla dimensione minima della replica di destinazione.

Il servizio di bilanciamento del carico di Service Fabric allinea le repliche nelle zone di lavoro al numero di repliche di destinazione. A questo punto, i servizi appaiono integri. Quando la zona inattiva torna a essere attiva, il servizio di bilanciamento del carico distribuirà in modo uniforme tutte le repliche dei servizi tra le zone.

Ottimizzazioni imminenti

• Per fornire aggiornamenti affidabili dell'infrastruttura, Service Fabric richiede che la durabilità del set di scalabilità di macchine virtuali sia impostata almeno su Silver. Ciò consente al set di scalabilità di macchine virtuali sottostante e al runtime di Service Fabric di fornire aggiornamenti affidabili. Questa operazione richiede anche che ogni zona abbia almeno 5 macchine virtuali. Microsoft sta lavorando per ridurre questo requisito rispettivamente a 3 e 2 macchine virtuali per zona per i tipi di nodo primario e non primario.
• Tutte le configurazioni indicate di seguito e il lavoro in corso forniscono ai clienti la migrazione in loco in cui è possibile aggiornare lo stesso cluster per l’uso della nuova configurazione aggiungendo nuovi nodeType e ritirando quelli precedenti.

Requisiti di rete

Risorse IP pubblico e servizio di bilanciamento del carico

Per abilitare la proprietà zones in una risorsa del set di scalabilità di macchine virtuali, è necessario che le risorse servizio di bilanciamento del carico e indirizzo IP a cui fa riferimento il set di scalabilità di macchine virtuali usino uno SKU Standard. La creazione di risorse servizio di bilanciamento del carico o indirizzo IP senza la proprietà SKU crea uno SKU Basic, che non supporta le zone di disponibilità. Per impostazione predefinita, un servizio di bilanciamento del carico dello SKU Standard blocca tutto il traffico dall'esterno. Per consentire il traffico esterno, distribuire un gruppo di sicurezza di rete nella subnet.

{
  "apiVersion": "2018-11-01",
  "type": "Microsoft.Network/publicIPAddresses",
  "name": "[concat('LB','-', parameters('clusterName')]",
  "location": "[parameters('computeLocation')]",
  "sku": {
    "name": "Standard"
  }
}

{
  "apiVersion": "2018-11-01",
  "type": "Microsoft.Network/loadBalancers",
  "name": "[concat('LB','-', parameters('clusterName')]",
  "location": "[parameters('computeLocation')]",
  "dependsOn": [
    "[concat('Microsoft.Network/networkSecurityGroups/', concat('nsg', parameters('subnet0Name')))]"
  ],
  "properties": {
    "addressSpace": {
      "addressPrefixes": [
        "[parameters('addressPrefix')]"
      ]
    },
    "subnets": [
      {
        "name": "[parameters('subnet0Name')]",
        "properties": {
          "addressPrefix": "[parameters('subnet0Prefix')]",
          "networkSecurityGroup": {
            "id": "[resourceId('Microsoft.Network/networkSecurityGroups', concat('nsg', parameters('subnet0Name')))]"
          }
        }
      }
    ]
  },
  "sku": {
    "name": "Standard"
  }
}

Nota

Non è possibile modificare in loco le risorse servizio di bilanciamento del carico e indirizzo IP pubblico dello SKU. Vedere la sezione relativa alla migrazione in questo articolo per informazioni su come eseguire la migrazione da risorse esistenti con uno SKU Basic.

Regole NAT per i set di scalabilità di macchine virtuali

Le regole NAT (Network Address Translation) in ingresso del servizio di bilanciamento del carico devono corrispondere ai pool NAT del set di scalabilità di macchine virtuali. Ogni set di scalabilità di macchine virtuali deve avere un pool NAT in ingresso univoco.

{
  "inboundNatPools": [
    {
      "name": "LoadBalancerBEAddressNatPool0",
      "properties": {
        "backendPort": "3389",
        "frontendIPConfiguration": {
          "id": "[variables('lbIPConfig0')]"
        },
        "frontendPortRangeEnd": "50999",
        "frontendPortRangeStart": "50000",
        "protocol": "tcp"
      }
    },
    {
      "name": "LoadBalancerBEAddressNatPool1",
      "properties": {
        "backendPort": "3389",
        "frontendIPConfiguration": {
          "id": "[variables('lbIPConfig0')]"
        },
        "frontendPortRangeEnd": "51999",
        "frontendPortRangeStart": "51000",
        "protocol": "tcp"
      }
    },
    {
      "name": "LoadBalancerBEAddressNatPool2",
      "properties": {
        "backendPort": "3389",
        "frontendIPConfiguration": {
          "id": "[variables('lbIPConfig0')]"
        },
        "frontendPortRangeEnd": "52999",
        "frontendPortRangeStart": "52000",
        "protocol": "tcp"
      }
    }
  ]
}

Regole in uscita per un servizio di bilanciamento del carico dello SKU Standard

Il servizio di bilanciamento del carico e l'indirizzo IP pubblico dello SKU Standard introducono nuove funzionalità e comportamenti diversi per la connettività in uscita rispetto allo SKU Basic. Per usufruire della connettività in uscita con lo SKU Standard, è necessario definirla in modo esplicito utilizzando gli indirizzi IP pubblici e il servizi di bilanciamento del carico dello SKU Standard. Per altre informazioni, vedere Connessioni in uscita e Azure Load Balancer.

Nota

Il modello standard fa riferimento a un gruppo di sicurezza di rete che consente tutto il traffico in uscita per impostazione predefinita. Il traffico in ingresso è limitato alle porte necessarie per le operazioni di gestione di Service Fabric. Le regole del gruppo di sicurezza di rete possono essere modificate per soddisfare i requisiti desiderati.

Importante

Ogni tipo di nodo in un cluster di Service Fabric che usa un servizio di bilanciamento del carico dello SKU Standard richiede una regola che consenta il traffico in uscita sulla porta 443. Questa operazione è necessaria per completare la configurazione del cluster. Qualsiasi distribuzione senza questa regola si concluderà con un errore.

1. Abilitare più zone di disponibilità in un singolo set di scalabilità di macchine virtuali

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 effettuare la distribuzione tra le zone di disponibilità mantenendo al tempo stesso un singolo set di scalabilità di macchine virtuali.

Un modello di esempio è disponibile in GitHub.

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

Per abilitare le zone in un set di scalabilità di macchine virtuali, includere i tre valori seguenti nella risorsa del set di scalabilità di macchine virtuali:

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

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

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

  In uno scenario con una zona inattiva potrebbero esserci conseguenze per un cluster con una distribuzione di macchine virtuali sbilanciata perché la maggior parte delle macchine virtuali potrebbe trovarsi in tale zona. La distribuzione di macchine virtuali non bilanciate tra le zone causa anche problemi di posizionamento dei servizi e il blocco degli aggiornamenti dell'infrastruttura. Altre informazioni su zoneBalancing.

Non è necessario configurare le sostituzioni di FaultDomain 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.
• È necessario configurare un set di scalabilità di macchine virtuali con almeno tre zone di disponibilità, indipendentemente dal livello di durabilità.
• Un'area di disponibilità che si estende su un set di scalabilità di macchine virtuali con durabilità Silver o superiore deve avere almeno 15 macchine virtuali (5 per area).
• Una zona di disponibilità che si estende su un 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

Il tipo di nodo di Service Fabric deve essere abilitato per supportare più zone di disponibilità.

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

• Il secondo valore è sfZonalUpgradeMode ed è facoltativo. Questa proprietà non può essere modificata se nel cluster è già presente un tipo di nodo con più zone di disponibilità. Questa proprietà controlla il raggruppamento logico delle macchine virtuali nei domini di aggiornamento (UD).

  • Se questo valore è impostato su Parallel: le macchine virtuali nel tipo di nodo vengono raggruppate in domini di aggiornamento e ignorano le informazioni sulla zona in cinque domini di aggiornamento. Questa impostazione determina l'aggiornamento dei domini di aggiornamento in tutte le zone contemporaneamente. Questa modalità di distribuzione è più veloce per gli aggiornamenti. Tuttavia, non è consigliabile perché non è in linea con le linee guida SDP, che indicano che gli aggiornamenti devono essere applicati a una sola zona 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 domini di aggiornamento. Ognuna delle tre zone ha cinque domini di aggiornamento. Ciò garantisce che le zone vengano aggiornate una alla volta e che si passi alla zona successiva solo dopo il completamento dell’aggiornamento di cinque domini di aggiornamento all'interno della prima zona. Questo 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 vengono ancora effettuati in parallelo in tutte le zone di disponibilità. Questa proprietà non influisce sulla distribuzione dei domini di aggiornamento per i tipi di nodo che non hanno 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 e determina se l’aggiornamento viene eseguito in parallelo o in sequenza tra le 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. Tuttavia, non è consigliabile perché non è in linea con le linee guida SDP, che indicano che gli aggiornamenti devono essere applicati a una sola zona alla volta.
  • Se questo valore viene omesso o impostato su Hierarchical: in questo modo le zone vengono aggiornate una alla volta e si passa alla zona successiva solo dopo il completamento dell’aggiornamento di cinque domini di aggiornamento 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 una versione successiva.

La versione del codice del cluster deve essere almeno 8.1.321 o una versione 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

• Le risorse indirizzo IP pubblico e servizio di bilanciamento del carico devono usare lo SKU Standard descritto in precedenza nell'articolo.
• La proprietà multipleAvailabilityZones 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 verificare che la distribuzione non superi il limite di tempo di distribuzione di Azure Resource Service di 12 ore. Ciò significa che la distribuzione non deve richiedere più di 12 ore per 15 domini di aggiornamento, ovvero non deve richiedere più di 40 minuti per ogni dominio di aggiornamento.
• Impostare il livello di affidabilità del cluster su Platinum per assicurarsi che il cluster superi lo scenario di inattività di una zona.
• L'aggiornamento del livello di durabilità per un tipo di nodo con più zone di disponibilità non è supportato. Creare invece un nuovo tipo di nodo con maggiore durabilità.
• Service Fabric supporta solo 3 zone di disponibilità. Attualmente non supporta un numero più elevato.

Suggerimento

È consigliabile impostare sfZonalUpgradeMode su Hierarchical o non specificare alcun valore. La distribuzione seguirà la distribuzione a livello di zona delle macchine virtuali e influirà su un numero minore di repliche o istanze, rendendole più sicure. Usare sfZonalUpgradeMode impostato su Parallel se la velocità di distribuzione è una priorità o se vengono eseguiti solo carichi di lavoro senza stato nel tipo di nodo con più zone di disponibilità. In questo modo, il passaggio tra i domini di aggiornamento avviene in parallelo in tutte le zone di disponibilità.

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

È necessario aggiungere un nuovo tipo di nodo che supporti più zone di disponibilità per tutti gli scenari di migrazione. 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 che illustrano come aggiungere un nuovo tipo di nodo e le altre risorse necessarie per il nuovo tipo di nodo, ad esempio le risorse indirizzo IP e servizio 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 le risorse servizio di bilanciamento del carico di base e indirizzo IP: questo processo è già descritto in una sezione secondaria seguente relativa alla 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 tutte le zone di disponibilità anziché una di ciascuna di queste risorse per ogni zona di disponibilità.

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

2. Distribuire le zone aggiungendo un set di scalabilità di macchine virtuali a ogni zona

Attualmente questa è la configurazione disponibile a livello generale. Per estendere un cluster di Service Fabric tra le 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 in modo uniforme 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 situato in una zona diversa.
  • Ogni set di scalabilità di macchine virtuali deve avere almeno cinque nodi (durabilità Silver).

Il diagramma seguente illustra l'architettura delle zone di disponibilità di Azure Service Fabric:

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 del set di scalabilità di macchine virtuali:

• Il primo valore è la proprietà zones, che specifica la zona di disponibilità in cui viene distribuito il set di scalabilità di macchine virtuali.
• Il secondo valore è la proprietà singlePlacementGroup, che deve essere impostata su true.
• Il terzo valore è la proprietà faultDomainOverride nell'estensione del set di scalabilità di macchine virtuali di Service Fabric. Questa proprietà deve includere solo la zona in cui verrà inserito il 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 forniscono il 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 proprietà isPrimary su true. Quando si distribuisce un cluster di Service Fabric tra 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')]"
    }
  ]
}

Eseguire la migrazione alle zone di disponibilità da un cluster usando un servizio di bilanciamento del carico dello SKU Basic e un indirizzo IP dello SKU Basic

Per eseguire la migrazione di un cluster, che usa un servizio di bilanciamento del carico e un indirizzo IP dello SKU Basic, è prima necessario creare un servizio di bilanciamento del carico e un indirizzo IP completamente nuovi 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 delle zone di disponibilità che si desidera usare. Nell'esempio precedente sono state aggiunte tre nuove risorse del set di scalabilità di macchine virtuali alle zone 1, 2 e 3. Questi set di scalabilità di macchine virtuali fanno riferimento al servizio di bilanciamento del carico e all’IP appena creati e vengono contrassegnati come tipi di nodo senza stato nella risorsa cluster di Service Fabric.

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

   • Risorsa IP pubblico dello SKU Standard
   • Risorsa del servizio bilanciamento di carico dello SKU Standard
   • Gruppo di sicurezza di rete a cui fa riferimento la subnet in cui si distribuiscono i 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 situato 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 le risorse indirizzo IP, servizio di bilanciamento del carico e set di scalabilità di macchine virtuali originali.

   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