Déployer un cluster managé Service Fabric sur plusieurs zones de disponibilité

Article
03/28/2024

Les zones de disponibilité dans Azure constituent une offre à haute disponibilité qui protège vos applications et données contre les pannes des centres de données. Une zone de disponibilité est un emplacement physique unique équipé d’une alimentation, d’un refroidissement et d’une mise en réseau indépendants dans une région Azure.

Un cluster managé Service Fabric prend en charge les déploiements qui s’étendent sur plusieurs zones de disponibilité pour assurer la résilience des zones. Cette configuration permet d’obtenir une haute disponibilité des services système critiques et de vos applications afin de les protéger contre des points de défaillance uniques. Les zones de disponibilité Azure sont disponibles uniquement dans les régions sélectionnées. Pour plus d’informations, consultez Vue d’ensemble des zones de disponibilité Azure.

Notes

La répartition sur plusieurs zones de disponibilité est disponible uniquement sur les clusters de niveau tarifaire Standard.

Des exemples de modèles sont disponibles : Modèle entre zones de disponibilité Service Fabric

Topologie pour les clusters managés Service Fabric résilient aux zones

Notes

L’avantage de répartir le type de nœud principal entre les zones de disponibilité n’est vraiment visible que pour trois zones et pas seulement deux.

Un cluster Service Fabric distribué entre des Zones de disponibilité (AZ) garantit la haute disponibilité de l’état du cluster.

La topologie recommandée pour un cluster managé s’appuie sur les ressources suivantes :

Le niveau tarifaire du cluster doit être Standard.
Le type de nœud principal doit est constitué d’au moins neuf nœuds (3 dans chaque AZ) pour une résilience optimale, mais prend en charge un nombre minimum de six (2 dans chaque AZ).
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.

Remarque

Seuls les déploiements sur trois zones de disponibilité sont pris en charge.

Notes

Il n’est pas possible de modifier sur place les groupes de machines virtuelles identiques dans un cluster géré, en passant d’un cluster sans couverture de zone à un cluster avec couverture de zone.

Diagramme illustrant l’architecture des zones de disponibilité Azure Service Fabric

Exemple de liste de nœuds illustrant les formats FD/UD dans les zones étendues d’un groupe de machines virtuelles identiques

Exemple de liste de nœuds illustrant les formats FD/UD dans les zones étendues d’un groupe de machines virtuelles identiques.

Distribution des réplicas de service entre les zones : Quand un service est déployé sur les nodeTypes, qui sont des zones étendues, des réplicas sont placés pour s’assurer qu’ils se trouvent dans des zones distinctes. Cette séparation est assurée, car le domaine d’erreur sur les nœuds présents dans chacun de ces types de nœuds est configuré avec les informations de zone (par exemple, FD = fd:/zone1/1 etc.). Par exemple : pour cinq réplicas ou instances d’un service, la distribution est 2-2-1 et le runtime essaie de garantir une distribution égale entre les zones de disponibilité.

Configuration du réplica de service utilisateur : Les services d’utilisateur avec état déployés sur la zone de disponibilité croisée nodeTypes doivent être configurés avec cette configuration : nombre de réplicas avec cible = 9, min = 5. Cette configuration permet au service de fonctionner même en cas de défaillance dans une zone, car il reste six réplicas en service dans les deux autres zones. Une mise à niveau d’une application passera également dans un tel scénario.

Scénario de panne de zone : lorsqu’une zone est défaillante, tous les nœuds de cette zone apparaissent comme étant en panne. Les réplicas de service sur ces nœuds sont également indisponibles. Du fait de la présence de réplicas dans les autres zones, le service continue de répondre grâce au basculement des réplicas principaux vers les zones fonctionnelles. Les services s’affichent dans un état d’avertissement, car le nombre de réplicas cibles n’est pas atteint et le nombre de machines virtuelles est toujours supérieur à la taille minimale de réplica cible définie. Par conséquent, un équilibreur de charge Service Fabric affiche des réplicas dans les zones de travail pour qu’elles correspondent au nombre de réplicas cibles configuré. À ce stade, les services doivent apparaître intègres. Lorsque la zone qui était en panne se remet en marche, l’équilibreur de charge répartit à nouveau tous les réplicas de service de manière égale sur toutes les zones.

Configuration de la mise en réseau

Pour plus d’informations, consultez Configuration des paramètres réseau pour les clusters managés Service Fabric.

Activation d’un cluster managé Azure Service Fabric résilient aux zones

Pour activer un cluster managé Azure Service Fabric résilient aux zones, vous devez inclure la propriété ZonalResiliency suivante, qui précise si le cluster est résilient ou non aux zones.

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

Migrer un cluster non résilient aux zones vers un cluster résilient aux zones (préversion)

Les clusters managés Service Fabric existants qui ne sont pas répartis sur différentes zones de disponibilité peuvent désormais être migrés sur place de façon à être répartis ainsi. Les clusters créés dans les régions disposant de trois zones de disponibilité et les clusters dans les régions où trois zones de disponibilité sont mises à disposition après déploiement comptent parmi les scénarios pris en charge.

Conditions requises :

Cluster SKU Standard.
Trois zones de disponibilité dans la région.

Notes

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’a pas aucune incidence sur l’intégrité du cluster. Cela se produit quand une nouvelle adresse IP publique doit être créée pour rendre la mise en réseau résiliente aux défaillances de zone. Planifiez la migration en conséquence.

Commencez par déterminer si une nouvelle adresse IP est nécessaire et quelles ressources doivent être migrées pour devenir résilientes au niveau des zones. Pour obtenir l’état actuel de résilience de la zone de disponibilité pour les ressources du cluster managé, utilisez l’appel d’API suivant :
```
POST https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.ServiceFabric/managedClusters/{clusterName}/getazresiliencystatus?api-version=2022-02-01-preview
```
Vous pouvez également utiliser le module Az comme suit :
```
Select-AzSubscription -SubscriptionId {subscriptionId}
Invoke-AzResourceAction -ResourceId /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.ServiceFabric/managedClusters/{clusterName} -Action getazresiliencystatus -ApiVersion 2022-02-01-preview
```
La commande doit fournir une réponse similaire à ceci :
```
{
"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
}
```
Si la ressource IP publique n’est pas résiliente au niveau des zones, la migration du cluster entraîne une brève perte de connectivité externe. Cette perte de connexion est due au fait que la migration configure une nouvelle adresse IP publique et met à jour le nom de domaine complet (FQDN) du cluster avec la nouvelle adresse IP. Si la ressource IP publique est résiliente au niveau des zones, la migration ne modifie ni la ressource IP publique ni le nom de domaine complet, et il n’y a aucun impact sur la connectivité externe.
Lancez la conversion du compte de stockage sous-jacent créé pour le cluster managé à partir du stockage localement redondant (LRS) vers le stockage redondant interzone (ZRS) à l’aide de la conversion initiée par le client. Le groupe de ressources du compte de stockage qui doit être migré est de la forme « SFC_ClusterId » (ex SFC_9240df2f-71ab-4733-a641-53a8464d992d) sous le même abonnement que la ressource de cluster managé.
Ajouter une propriété de zones aux types de nœuds existants

Cette étape configure le groupe de machines virtuelles identiques managé associé au type de nœud comme résilient au niveau de la zone, ce qui garantit que toutes les nouvelles machines virtuelles qui y sont ajoutées seront déployées entre les zones de disponibilité (machines virtuelles zonales). Si le type de nœud spécifié est principal, le fournisseur de ressources effectue la migration de l’adresse IP publique, ainsi qu’une mise à jour DNS du nom de domaine complet du cluster, si nécessaire, pour devenir résilient au niveau de la zone. Utilisez l’API getazresiliencystatus pour comprendre l’implication de cette étape.

Utiliser apiVersion 2022-02-01-preview ou une version supérieure.

Ajoutez le paramètres zones défini sur ["1", "2", "3"] aux types de nœuds existants :

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

Mettre à l’échelle les types de nœuds pour ajouter des nœuds zonaux et supprimer les nœuds régionaux

À ce stade, Virtual Machine Scale Sets est marqué comme résilient au niveau des zones. Par conséquent, lors de la mise à l’échelle avec une augmentation, les nœuds nouvellement ajoutés seront zonaux et, lors de la mise à l’échelle avec une réduction, les nœuds régionaux seront supprimés. Cette approche offre la possibilité d’effectuer un scale-in pour n’importe quel ordre qui s’aligne sur vos besoins en capacité en ajustant la propriété vmInstanceCount sur les types de nœuds.

Par exemple, si la propriété vmInstanceCount initiale est définie sur 6 (indiquant six nœuds régionaux), vous pouvez effectuer deux déploiements :
- Premier déploiement : augmentez la propriété vmInstanceCount sur 12 pour ajouter 6 nœuds zonaux.
- Deuxième déploiement : réduisez la propriété vmInstanceCount sur 6 pour supprimer tous les nœuds régionaux.
Tout au long du processus, vous pouvez vérifier l’API getazresiliencystatus pour récupérer l’état de progression, comme illustré ci-dessous. Le processus est considéré comme terminé une fois que chaque type de nœud a au moins six nœuds zonaux et 0 nœuds régionaux.
```
{
"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
}
```
Remarque

Le processus de mise à l’échelle pour le type de nœud principal nécessite un temps supplémentaire, car chaque ajout ou suppression d’un nœud lance une mise à niveau d’un cluster Service Fabric.
Marquer le cluster comme résilient aux échecs de zone

Cette étape vous aidera pour les déploiements futurs, car elle garantit que tous les déploiements de types de nœuds futurs s’étendent sur des zones de disponibilité, et donc que le cluster reste tolérant aux échecs de zone de disponibilité. Définissez zonalResiliency: true dans le modèle ARM de cluster et opérez un déploiement afin de marquer le cluster comme résilient aux zones et de vous assurer que tous les nouveaux déploiements de type de nœud sont répartis sur des zones de disponibilité. Cette mise à jour est autorisée uniquement si tous les types de nœuds ont au moins six nœuds zonaux et 0 nœuds régionaux.
```
{
  "apiVersion": "2022-02-01-preview",
  "type": "Microsoft.ServiceFabric/managedclusters",
  "zonalResiliency": "true"
}
```
Vous pouvez également voir l’état mis à jour dans le portail sous Vue d’ensemble -> Propriétés, comme Zonal resiliency True, une fois cela terminé.

Valider que toutes les ressources sont résilientes pour la zone

Pour valider l’état de résilience de la zone de disponibilité pour les ressources du cluster managé, utilisez l’appel d’API GET suivant :

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

Cet appel d’API doit fournir une réponse similaire à ceci :

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

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

Activation de FastZonalUpdate sur les clusters managés Service Fabric (préversion)

Les clusters managés Service Fabric prennent en charge des mises à niveau de clusters et d’applications plus rapides en réduisant le nombre maximal de domaines de mise à niveau par zone de disponibilité. La configuration par défaut peut actuellement avoir au plus 15 domaines de mise à niveau dans plusieurs types de nœuds de zone de disponibilité. Ce nombre énorme d’UD a réduit la vitesse de mise à niveau. La nouvelle configuration réduit le nombre maximal de domaines de mise à niveau, ce qui se traduit par des mises à jour plus rapides, tout en préservant la sécurité des mises à niveau.

La mise à jour doit être effectuée via un modèle ARM en définissant la propriété zonalUpdateMode sur « fast », puis en modifiant un attribut de type de nœud, par exemple en ajoutant et supprimant un nœud pour chaque type de nœud (voir les étapes nécessaires 2 et 3). La valeur apiVersion de la ressource de cluster managé Service Fabric doit être 2022-10-01-preview ou ultérieure.

Modifiez le modèle ARM avec la nouvelle propriété zonalUpdateMode.

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

Ajoutez un nœud à un cluster à l’aide de la commande az sf cluster node add PowerShell.
Supprimez un nœud d’un cluster à l’aide de la commande az sf cluster node remove PowerShell.

Déployer un cluster managé Service Fabric sur plusieurs zones de disponibilité

Topologie pour les clusters managés Service Fabric résilient aux zones

Configuration de la mise en réseau

Activation d’un cluster managé Azure Service Fabric résilient aux zones

Migrer un cluster non résilient aux zones vers un cluster résilient aux zones (préversion)

Activation de FastZonalUpdate sur les clusters managés Service Fabric (préversion)

Ressources supplémentaires