Distribuire un cluster gestito di 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.

Il cluster gestito di Service Fabric supporta distribuzioni che si estendono su più zone di disponibilità per garantire la resilienza della zona. Questa configurazione garantisce la disponibilità elevata dei servizi di sistema critici e delle applicazioni da proteggere da singoli punti di errore. Azure zone di disponibilità sono disponibili solo nelle aree selezionate. Per altre informazioni, vedere Panoramica di Azure zone di disponibilità.

Sono disponibili modelli di esempio: modello di zona tra disponibilità di Service Fabric

Topologia per cluster gestiti di Azure Service Fabric resilienti per la zona

Un cluster di Service Fabric distribuito tra zone di disponibilità (AZ) garantisce una disponibilità elevata dello stato del cluster.

La topologia consigliata per il cluster gestito richiede le risorse seguenti:

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

Diagramma che mostra l'architettura della zona di disponibilità di Azure Service Fabric

Elenco di nodi di esempio che illustra i formati FD/UD in un set di scalabilità di macchine virtuali che si estende su zone

Distribuzione delle repliche del servizio tra le zone: quando un servizio viene distribuito nei tipi di nodo che si estendono su zone, le repliche vengono posizionate per assicurarsi che si trovino in zone separate. Questa separazione viene garantita perché i nodi presenti nei nodi presenti in ognuno di questi tipi di nodo vengono configurati con le informazioni sulla zona ,ad esempio FD = fd:/zone1/1 e così via. Ad esempio: per cinque repliche o istanze di un servizio, la distribuzione è 2-2-1 e il runtime tenta di garantire la stessa distribuzione tra le reti AZ.

Configurazione replica servizio utente: i servizi utente con stato distribuiti nei tipi di nodo della zona di disponibilità incrociata devono essere configurati con questa configurazione: numero di repliche con target = 9, min = 5. Questa configurazione consente al servizio di funzionare anche quando una zona si arresta perché le sei repliche saranno ancora in aumento nelle altre due zone. Anche un aggiornamento dell'applicazione in uno scenario di questo tipo verrà sottoposto a verifica.

Scenario inattivo della zona: quando una zona diventa inattiva, tutti i nodi di tale zona vengono visualizzati come inattivo. Anche le repliche del servizio in questi nodi saranno inattivo. Poiché nelle altre zone sono presenti repliche, il servizio continua a essere reattivo con il failover delle repliche primarie nelle zone funzionanti. I servizi verranno visualizzati nello stato di avviso perché il numero di repliche di destinazione non viene soddisfatto e il numero di macchine virtuali (VM) è ancora superiore alle dimensioni della replica minima definite. Di conseguenza, il servizio di bilanciamento del carico di Service Fabric attiva le repliche nelle zone di lavoro in modo che corrispondano al numero di repliche di destinazione configurato. A questo punto, i servizi dovrebbero apparire integri. Quando la zona inattiva torna indietro, il servizio di bilanciamento del carico distribuirà di nuovo tutte le repliche del servizio in modo uniforme in tutte le zone.

Configurazione delle impostazioni di rete

Per altre informazioni, vedere Configurare le impostazioni di rete per i cluster gestiti di Service Fabric.

Abilitazione di un cluster gestito di Azure Service Fabric resiliente alla zona

Per abilitare un cluster gestito di Azure Service Fabric resiliente alla zona, è necessario includere la proprietà ZonalResiliency seguente, che specifica se il cluster è resiliente o meno.

{
  "apiVersion": "2021-05-01",
  "type": "Microsoft.ServiceFabric/managedclusters",
  "properties": {
  ...
  "zonalResiliency": "true",
  ...
  }
}

Eseguire la migrazione di un cluster resiliente non di zona esistente a Resiliente alla zona

È ora possibile eseguire la migrazione dei cluster gestiti di Service Fabric esistenti che non si estendono tra le zone di disponibilità per estendersi su zone di disponibilità. Gli scenari supportati includono cluster creati in aree con tre zone di disponibilità e cluster nelle aree in cui vengono rese disponibili tre zone di disponibilità dopo la distribuzione.

Requisiti:

• Cluster SKU standard.
• Tre zone di disponibilità nell'area.

1. Iniziare a determinare se è necessario un nuovo INDIRIZZO IP e quali risorse devono essere migrate per diventare resilienti per la zona. Per ottenere lo stato di resilienza corrente della zona di disponibilità per le risorse del cluster gestito, usare la chiamata API seguente:

   POST https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.ServiceFabric/managedClusters/{clusterName}/getazresiliencystatus?api-version=2022-02-01-preview
   

   In alternativa, è possibile usare il modulo Az come indicato di seguito:

   Select-AzSubscription -SubscriptionId {subscriptionId}
   Invoke-AzResourceAction -ResourceId /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.ServiceFabric/managedClusters/{clusterName} -Action getazresiliencystatus -ApiVersion 2022-02-01-preview
   

   Il comando deve fornire una risposta simile alla seguente:

   {
   "baseResourceStatus" :[
     {
     "resourceName": "sfmccluster1"
     "resourceType": "Microsoft.Storage/storageAccounts"
     "isZoneResilient": false
     },
     {
     "resourceName": "PublicIP-sfmccluster1"
     "resourceType": "Microsoft.Network/publicIPAddresses"
     "isZoneResilient": false
     },
     {
     "resourceName": "primary"
     "resourceType": "Microsoft.Compute/virutalmachinescalesets"
     "isZoneResilient": false
     }
   ],
   "isClusterZoneResilient": false
   }
   

   Se la risorsa IP pubblico non è resiliente alla zona, la migrazione del cluster causerà una breve perdita di connettività esterna. Questa perdita di connessione è dovuta alla configurazione del nuovo indirizzo IP pubblico e all'aggiornamento del nome di dominio completo (FQDN) del cluster al nuovo indirizzo IP. Se la risorsa IP pubblico è resiliente alla zona, la migrazione non modificherà la risorsa IP pubblico né il nome di dominio completo e non ci sarà alcun impatto sulla connettività esterna.

2. Avviare la conversione dell'account di archiviazione sottostante creato per il cluster gestito dall'archiviazione con ridondanza locale all'archiviazione con ridondanza della zona usando la conversione avviata dal cliente. Il gruppo di risorse dell'account di archiviazione di cui è necessario eseguire la migrazione sarà il formato "SFC_ClusterId"(ad esempio SFC_9240df2f-71ab-4733-a641-53a846464d992d) nella stessa sottoscrizione della risorsa cluster gestita.

3. Aggiungere la proprietà zones ai tipi di nodo esistenti

   Questo passaggio configura il set di scalabilità di macchine virtuali gestite associato al tipo di nodo come resiliente alla zona, assicurando che tutte le nuove macchine virtuali aggiunte verranno distribuite tra zone di disponibilità (macchine virtuali di zona). Se il tipo di nodo specificato è primario, il provider di risorse eseguirà la migrazione dell'indirizzo IP pubblico insieme a un aggiornamento DNS FQDN del cluster, se necessario, per diventare resiliente alla zona. Usare l'API per comprendere l'implicazione getazresiliencystatus di questo passaggio.

• Usare apiVersion 2022-02-01-preview o versione successiva.

• Aggiungere il zones parametro impostato su ai ["1", "2", "3"] tipi di nodo esistenti:

  {
     "apiVersion": "2024-02-01-preview",
     "type": "Microsoft.ServiceFabric/managedclusters/nodetypes",
     "name": "[concat(parameters('clusterName'), '/', parameters('nodeTypeName'))]",
     "location": "[resourcegroup().location]",
     "dependsOn": [
       "[concat('Microsoft.ServiceFabric/managedclusters/', parameters('clusterName'))]"
     ],
     "properties": {
       ...
       "isPrimary": true,
       "zones": ["1", "2", "3"]
       ...
     }
  },
  {
     "apiVersion": "2024-02-01-preview",
     "type": "Microsoft.ServiceFabric/managedclusters/nodetypes",
     "name": "[concat(parameters('clusterName'), '/', parameters('nodeTypeNameSecondary'))]",
     "location": "[resourcegroup().location]",
     "dependsOn": [
       "[concat('Microsoft.ServiceFabric/managedclusters/', parameters('clusterName'))]"
     ],
     "properties": {
       ...
       "isPrimary": false,
       "zones": ["1", "2", "3"]
       ...
     }
  }
  

4. Ridimensionare i tipi di nodo per aggiungere nodi di zona e rimuovere nodi a livello di area

   In questa fase, il set di scalabilità di macchine virtuali viene contrassegnato come resiliente alla zona. Pertanto, quando si aumentano le prestazioni, i nodi appena aggiunti saranno a livello di zona e, quando si aumenta il numero di istanze, i nodi a livello di area verranno rimossi. Questo approccio offre la flessibilità necessaria per la scalabilità in qualsiasi ordine allineato ai requisiti di capacità modificando la vmInstanceCount proprietà sui tipi di nodo.

   Ad esempio, se vmInstanceCount iniziale è impostato su 6 (che indica sei nodi internazionali), è possibile eseguire due distribuzioni:

   • Prima distribuzione: aumentare vmInstanceCount a 12 per aggiungere 6 nodi di zona .
   • Seconda distribuzione: ridurre vmInstanceCount su 6 per rimuovere tutti i nodi internazionali .

   Durante il processo, è possibile controllare l'API getazresiliencystatus per recuperare lo stato di avanzamento, come illustrato di seguito. Il processo viene considerato completato una volta che ogni tipo di nodo ha un minimo di sei nodi di zona e 0 nodi a livello di area.

   {
   "baseResourceStatus" :[
     {
     "resourceName": "sfmccluster1"
     "resourceType": "Microsoft.Storage/storageAccounts"
     "isZoneResilient": true
     },
     {
     "resourceName": "PublicIP-sfmccluster1"
     "resourceType": "Microsoft.Network/publicIPAddresses"
     "isZoneResilient": true
     },
     {
     "resourceName": "ntPrimary"
     "resourceType": "Microsoft.Compute/virutalmachinescalesets"
     "isZoneResilient": false
     "details": "Status: InProgress, ZonalNodes: 6, RegionalNodes: 6"
     },
     {
     "resourceName": "ntSecondary"
     "resourceType": "Microsoft.Compute/virutalmachinescalesets"
     "isZoneResilient": true
     "details": "Status: Done, ZonalNodes: 6, RegionalNodes: 0"
     }
   ],
   "isClusterZoneResilient": false
   }
   

   Nota

   Il processo di ridimensionamento per il tipo di nodo primario richiederà tempo aggiuntivo, perché ogni aggiunta o rimozione di un nodo avvierà un aggiornamento del cluster di Service Fabric.

5. Contrassegnare gli errori di resilienza del cluster in caso di errori di zona

   Questo passaggio consente di eseguire distribuzioni future, poiché garantisce che tutte le distribuzioni future dei tipi di nodo si estendono tra le zone di disponibilità e pertanto il cluster rimanga tollerante agli errori az. Impostare zonalResiliency: true nel modello arm del cluster ed eseguire una distribuzione per contrassegnare il cluster come resiliente alla zona e assicurarsi che tutte le nuove distribuzioni dei tipi di nodo si estendono tra le zone di disponibilità. Questo aggiornamento è consentito solo se tutti i tipi di nodo hanno almeno sei nodi di zona e 0 nodi a livello di area.

   {
     "apiVersion": "2022-02-01-preview",
     "type": "Microsoft.ServiceFabric/managedclusters",
     "zonalResiliency": "true"
   }
   

   È anche possibile visualizzare lo stato aggiornato nel portale in Panoramica -> Proprietà simili a Zonal resiliency True, una volta completato.

6. Verificare che tutte le risorse siano resilienti per la zona

   Per convalidare lo stato di resilienza della zona di disponibilità per le risorse del cluster gestito, usare la chiamata API GET seguente:

   POST https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.ServiceFabric/managedClusters/{clusterName}/getazresiliencystatus?api-version=2022-02-01-preview
   

   Questa chiamata API deve fornire una risposta simile alla seguente:

   {
    "baseResourceStatus" :[
      {
      "resourceName": "sfmccluster1"
      "resourceType": "Microsoft.Storage/storageAccounts"
      "isZoneResilient": true
      },
      {
      "resourceName": "PublicIP-sfmccluster1"
      "resourceType": "Microsoft.Network/publicIPAddresses"
      "isZoneResilient": true
      },
      {
        "resourceName": "ntPrimary"
        "resourceType": "Microsoft.Compute/virutalmachinescalesets"
        "isZoneResilient": true
        "details": "Status: Done, ZonalNodes: 6, RegionalNodes: 0"
      },
      {
        "resourceName": "ntSecondary"
        "resourceType": "Microsoft.Compute/virutalmachinescalesets"
        "isZoneResilient": true
        "details": "Status: Done, ZonalNodes: 6, RegionalNodes: 0"
      }
    ],
    "isClusterZoneResilient": true
   }
   

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

Abilitare FastZonalUpdate nei cluster gestiti di Service Fabric

I cluster gestiti di Service Fabric supportano aggiornamenti di cluster e applicazioni più veloci riducendo il numero massimo di domini di aggiornamento per zona di disponibilità. La configurazione predefinita ora può avere al massimo 15 domini di aggiornamento (UD) in più nodetype AZ. Questo numero enorme di ID ha ridotto la velocità di aggiornamento. La nuova configurazione riduce il numero massimo di DOMINI, che comportano aggiornamenti più veloci, mantenendo intatta la sicurezza degli aggiornamenti.

L'aggiornamento deve essere eseguito tramite il modello di Resource Manager impostando la proprietà zonalUpdateMode su "fast" e quindi modificando un attributo del tipo di nodo, ad esempio aggiungendo un nodo e quindi rimuovendo il nodo a ogni tipo di nodo (vedere i passaggi necessari 2 e 3). L'api della risorsa cluster gestita di Service FabricVersion deve essere 2022-10-01-preview o versione successiva.

1. Modificare il modello di Resource Manager con la nuova proprietà zonalUpdateMode.

   "resources": [
        {
            "type": "Microsoft.ServiceFabric/managedClusters",
            "apiVersion": "2022-10-01-preview",
            '''
            "properties": {
                '''
                "zonalResiliency": true,
                "zonalUpdateMode": "fast",
                ...
            }
        }]

2. Aggiungere un nodo a un cluster usando il comando az sf cluster node add PowerShell.

3. Rimuovere un nodo da un cluster usando il comando az sf cluster node remove di PowerShell.