Continuité d’activité et reprise d’activité pour Azure VMware Solution

Ce scénario à l’échelle de l’entreprise permet d’améliorer la continuité d’activité et la récupération d’urgence (BCDR). Azure VMware Solution fournit des clouds privés qui contiennent des clusters VMware vSphere créés à partir d’une infrastructure Azure complète dédiée. La solution fournit au minimum trois hôtes ESXi et au maximum 16 hôtes par cluster. Tous les clouds privés approvisionnés comportent VMware vCenter Server, VMware vSAN, VMware vSphere et VMware NSX-T Data Center. Pour en savoir plus sur le contrat SLA d’Azure VMware Solution, consultez Contrat SLA d’Azure VMware Solution.

Que vous ayez une instance locale ou Azure VMware Solution, vous devez prendre en compte différents facteurs de BCDR pour vous préparer aux sinistres. Un plan de BCDR robuste vise à protéger une entreprise contre la perte de données, les pertes financières et les temps d’arrêt en cas d’événement perturbateur. L’arbre de décision suivante montre les différentes options de BCDR disponibles pour Azure VMware Solution.

Remarque

Un environnement pilote léger est configuré avec une configuration minimale, comprenant uniquement les composants principaux pour prendre en charge un ensemble critique d’applications. Toutefois, il peut se développer (scale-out) et générer davantage d’hôtes pour prendre la majeure partie de la charge en cas de basculement. Pour la récupération d’urgence des charges de travail Azure VMware Solution nécessitant beaucoup de calcul et de mémoire, la même quantité de stockage est requise sur le site secondaire.

Considérations relatives à la conception de la continuité de l’activité

• Les stratégies de stockage VMware vSAN sur Azure VMware Solution sont implémentées en tenant compte de la disponibilité du stockage. Quand le cluster a entre trois et cinq hôtes, le nombre de défaillances d’hôtes à tolérer sans perte de données est égal à un. Quand le cluster a entre 6 et 16 hôtes, le nombre de défaillances d’hôtes à tolérer avant qu’une perte de données ne se produise est égal à deux. Les stratégies de stockage VMware vSAN peuvent être appliquées en fonction de chaque machine virtuelle. Bien qu’il s’agisse des stratégies par défaut, vous pouvez modifier la stratégie en fonction de besoins personnalisés. Pour plus d’informations, consultez Concepts de stockage d’Azure VMware Solution.

• VMware High Availability est activé par défaut sur Azure VMware Solution. La stratégie d’admission de haute disponibilité réserve la capacité de calcul et de mémoire pour un seul nœud. Cette réservation garantit une capacité suffisante pour redémarrer les charges de travail sur un autre nœud d’un cluster Azure VMware Solution.

• Haute disponibilité avec cluster étendu : Avec Azure VMware Solution, les hôtes ESXi déployés dans un cluster vSphere standard résident traditionnellement dans une seule zone de disponibilité Azure et sont protégés par la haute disponibilité vSphere. Toutefois, les charges de travail ne sont pas protégées contre une défaillance de zone de disponibilité. Pour se protéger contre une défaillance, un seul cluster vSAN couvre deux zones de disponibilité distinctes, appelé cluster étendu vSAN. Pour plus d’informations, consultez Déployer des clusters étendus vSAN.

• Choisissez une solution de sauvegarde validée pour les machines virtuelles VMware vSphere, par exemple MABS (Serveur de sauvegarde Microsoft Azure), ou une solution de sauvegarde partenaire.

• Pour plus d’informations sur les fonctionnalités prises en charge dans les solutions de sauvegarde partenaires, reportez-vous à la documentation du partenaire respectif.

  Remarque

  Les configurations de vCenter Server et NSX-T Data Center pour les clouds privés sont sauvegardées toutes les heures, et les sauvegardes sont conservées pendant trois jours.

• Les composants Azure VMware Solution, tels que vCenter Server, NSX-T Manager ou HCX Manager sont des services managés dont Azure gère la sauvegarde. Pour effectuer une restauration à partir d’une sauvegarde, créez une demande de support Azure.

Recommandations relatives à la conception de la continuité de l’activité

• Utilisez un serveur de sauvegarde Azure pour sauvegarder le cloud privé Azure VMware Solution. Pour plus d’informations, consultez Sauvegarder les machines virtuelles VMware vSphere avec Sauvegarde Azure. Les topologies de déploiement prises en charge incluent l’agent MARS et Data Protection Manager. Chaque topologie de déploiement a sa propre matrice de prise en charge, ses contraintes et ses limites.

• Déployez le serveur de sauvegarde Azure dans la même région Azure que le cloud privé Azure VMware Solution. Cette méthode de déploiement réduit les coûts de trafic, facilite l’administration et permet de conserver la topologie principale/secondaire. Consultez le guide de décision concernant les régions Azure pour connaître les bonnes pratiques de déploiement dans une région Azure.

• La Sauvegarde Azure peut être déployée en tant que machine virtuelle Azure IaaS (infrastructure as a service) ou dans le cloud privé Azure VMware Solution. Il est vivement recommandé de la déployer en dehors du cloud privé Azure VMware Solution. Déployez la sauvegarde dans un réseau virtuel Azure et vérifiez que ce réseau virtuel est connecté à la même instance ExpressRoute que celle connectée au cloud privé Azure VMware Solution. L’exécution du serveur de sauvegarde en dehors du cloud privé Azure VMware Solution permet de réduire la consommation de vSAN, car vSAN est une ressource à capacité limitée dans le cloud privé Azure VMware Solution.

  Serveur de sauvegarde Azure déployé en tant que machine virtuelle IaaS Azure.

  

  Serveur de sauvegarde Azure déployé en tant que machine virtuelle Azure VMware Solution.

  

• Utilisez la Liste de contrôle pour les exigences de performances de l’application pour obtenir la capacité et le type de disque appropriés, par exemple HDD, SSD ou Ultra. Envisagez la référence SKU Machine virtuelle Azure IaaS qui prend en charge le type de disque et la capacité des opérations de sauvegarde.

• Utilisez le planificateur de capacité du serveur de sauvegarde Azure afin de déterminer le nombre de serveurs, le stockage et les IOPS requis pour chacun d’eux. Lorsque vous indiquez la valeur « Taille totale de la charge de travail (en Go)* » dans le planificateur de capacité, utilisez la valeur médiane entre « stockage utilisé » et « stockage alloué » de toutes les machines virtuelles de vCenter que vous souhaitez sauvegarder.

• Utilisez des pools de stockage avec le serveur de sauvegarde Azure pour améliorer les IOPS/le débit du disque. Utilisez le stockage hiérarchisé sur le serveur de sauvegarde pour améliorer les opérations. Définissez la valeur de configuration DisableWriteAutoTiering à 1 sur le volume MABS afin que l’ensemble du niveau de performance soit disponible pour stocker les métadonnées ReFS.

• Identifiez le nombre de travaux de sauvegarde parallèles et d’opérations de restauration à exécuter sur le serveur de sauvegarde Azure. Actuellement, huit travaux de sauvegarde parallèles sont pris en charge. Mesurez le temps nécessaire à la sauvegarde et à la restauration des charges de travail stratégiques sur plusieurs exécutions. Vérifiez que les temps de sauvegarde et de restauration répondent aux exigences RPO et RTO du serveur de sauvegarde Azure. Vérifiez que le magasin de données AVS vSAN a suffisamment de capacité pour conserver la sauvegarde restaurée.

• Ajoutez les exceptions antivirus nécessaires pour les fichiers et dossiers du serveur de sauvegarde Azure, comme indiqué ici, si un logiciel antivirus/anti-programme malveillant s’exécute sur le serveur de sauvegarde Azure. Lorsque vous utilisez l’agent de protection DPM sur n’importe quelle machine virtuelle Azure VMware Solution pour la sauvegarde des applications (par exemple, SQL, Sharepoint, etc.), désactivez la surveillance en temps réel de dpmra.exe.

• Configurez les règles de groupe de sécurité réseau (NSG) appropriées sur le sous-réseau hébergeant Sauvegarde Azure Serveur pour autoriser la communication réseau à partir de l’agent de protection DPM s’exécutant sur une machine virtuelle protégée dans Azure VMware Solution. L’agent de protection DPM communique avec Sauvegarde Azure Server sur n’importe quel port dynamique compris entre 1024 et 65535.

• Actuellement, le serveur de sauvegarde Azure ne prend pas en charge la restauration interrégion pour le cloud privé Azure VMware Solution. Reportez-vous aux sections Solutions de sauvegarde partenaires et Récupération d’urgence lorsque la récupération interrégion d’Azure VMware Solution est requise.

Considérations relatives à la conception de la reprise d’activité après sinistre

• Alignez les exigences métier sur les objectifs de temps de récupération (RTO), la capacité et les objectifs de point de récupération (RPO) pour les applications. Planifiez et concevez de manière à atteindre ces objectifs à l’aide de la technologie de réplication la plus appropriée. Par exemple, répliquez en mode natif des bases de données SQL à l’aide d’un groupe de disponibilité SQL Always On ou utilisez un outil de récupération d’urgence tel que VMware Site Recovery Manager.

• Déterminez le site de récupération d’urgence cible pour le cloud privé Azure VMware Solution protégé. Ce site influence le choix des outils de reprise d’activité après sinistre les plus appropriés à l’environnement. Par exemple, si vous souhaitez récupérer des charges de travail Azure VMware Solution sur des machines virtuelles IaaS natives Azure, vous pouvez envisager Azure Site Recovery ou Zerto.

• Déterminez quel ensemble ou sous-ensemble de charges de travail Azure VMware Solution nécessite une protection en cas de reprise d’activité après sinistre. Envisagez de catégoriser les charges de travail en fonction de leur priorité : P0 pour les charges de travail vitales pour l’entreprise, et P1, P2 et P3 pour les autres charges de travail qui sont importantes, mais pas aussi critiques pour le fonctionnement de l’entreprise. Le plan de continuité d’activité du client définit les niveaux de priorité, ce qui permet de contrôler les coûts associés à l’implémentation de la reprise d’activité après sinistre.

• Dans la plupart des cas, les environnements hors production, comme ceux de développement, de test ou de test d’acceptation utilisateur n’ont pas besoin de basculer vers un site secondaire. Vous devez exécuter le pilote léger sur le site secondaire avec une capacité réduite pour la production et les charges de travail critiques afin d’économiser sur les coûts. Pour plus de capacité, vous pouvez effectuer un scale-out pour ajouter des hôtes ESXi au cluster pendant l’événement de récupération d’urgence.

• Pour les déploiements pilotes légers en particulier, assurez-vous que vous avez sécurisé tout le quota d’hôtes nécessaire dans le site secondaire afin de ne pas avoir à attendre la capacité requise pendant le scale-out complet. Consultez Demander un quota hôte pour Azure VMware Solution.

• Configurez les rôles de domaine opérationnels, par exemple les contrôleurs de domaine Active Directory, dans l’environnement secondaire.

• Des solutions partenaires comme JetStream et Zerto sont généralement disponibles et validées sur Azure VMware Solution. Elles prennent en charge la plupart des scénarios de récupération d’urgence et peuvent fournir une récupération plus rapide avec un objectif de point de récupération proche de zéro.

• VMware Site Recovery Manager, Jetstream et Zerto prennent en charge la migration d’emplacements tiers vers Azure VMware Solution.

• VMware HCX est également une solution de récupération d’urgence économique. Toutefois, elle n’est pas recommandée pour les charges de travail de production volumineuses en raison de l’orchestration manuelle.

• Pour la reprise d’activité après sinistre entre les clouds privés Azure VMware Solution dans des régions Azure distinctes, vous devez activer ExpressRoute Global Reach entre les deux circuits ExpressRoute de back-ends. Ces circuits créent une connectivité de cloud privé principale et secondaire quand cela est nécessaire pour des solutions telles que VMware SRM et VMware HCX.

• Pour la récupération d’urgence entre clouds privés Azure VMware Solution dans la même région Azure, vous devez activer Azure VMware Solution Interconnect. Elle crée un lien de routage entre les réseaux de gestion et de charge de travail des clouds privés Azure VMware Solution pour la communication entre les clouds. Assurez-vous que l’espace d’adressage IP routé dans chaque cloud privé est unique et ne se chevauche pas.

• Quand vous avez recours à la reprise d’activité après sinistre, vous pouvez utiliser le même espace d’adressage IP source dans la région Azure principale et la région Azure secondaire. Toutefois, cela nécessite des efforts supplémentaires en matière de conception et d’ingénierie.

  • Conserver les mêmes adresses IP : les machines virtuelles du site Azure VMware Solution secondaire peuvent être récupérées à l’aide de la même adresse IP source que le site principal. Pour cette méthode, créez des VLAN ou segments NSX-T isolés sur le site secondaire, et vérifiez qu’aucun de ces VLAN ou segments isolés n’est connecté à l’environnement. Modifiez vos routes de reprise d’activité après sinistre pour indiquer que le sous-réseau a été déplacé vers le site secondaire et vers de nouvelles localisations d’adresses IP. Bien que cette méthode fonctionne, elle crée également une surcharge d’ingénierie quand on vise une récupération d’urgence entièrement automatisée.

  • Utiliser des adresses IP distinctes : vous pouvez également utiliser des adresses IP distinctes pour les machines virtuelles récupérées. Si la machine virtuelle est déplacée vers un site secondaire, le plan de reprise d’activité présent dans VMware Site Recovery Manager détaille le mappage IP personnalisé. Sélectionnez ce mappage pour le changement d’adresse IP. Les machines virtuelles sont mises en place dans les nouveaux segments NSX-T, et de nouvelles adresses IP sont affectées. Les outils peuvent différer pour différentes solutions de récupération d’urgence.

• Facteurs importants pour les scénarios de récupération d’urgence partielle et complète :

  • VMware Site Recovery Manager prend en charge la récupération partielle, qui récupère uniquement un sous-ensemble de machines virtuelles, et la récupération d’urgence complète. Entre deux sites Azure VMware Solution dans la région 1 et la région 2, toutes ou certaines machines virtuelles peuvent basculer.

  • L’exigence de conservation des adresses IP sources pour les machines virtuelles récupérées détermine si la récupération d’urgence partielle ou complète est possible.

  • Pour conserver l’adresse IP source tout en effectuant une récupération d’urgence partielle dans Site Recovery Manager, la passerelle de sous-réseau doit se déplacer vers le site secondaire.

  Notes

  La reprise d’activité après sinistre de type actif/passif ne nécessite pas d’élargissement de couche 2.

Recommandations relatives à la conception de la reprise d’activité après sinistre

• Utilisez VMware Site Recovery Manager quand vous employez Azure VMware Solution sur les sites principaux et secondaires. Les sites principaux et secondaires sont également appelés sites protégés et sites de reprise d’activité, respectivement.

  Vue d’ensemble de la réplication vSphere continue.

  

  Exemple détaillé de réplication vSphere continue entre sites principaux et secondaires.

  

• Pour les applications vitales pour l’entreprise, Zerto et JetStream sont disponibles en tant que solutions de récupération d’urgence pour le cloud privé Azure VMware Solution. JetStream et Zerto reposent sur la base de la protection continue des données (CDP), à l’aide de l’infrastructure d’API VMware vSphere pour le filtrage E/S (VAIO), qui permet une perte de données minimum, voire nulle. Cela permet également d’obtenir une récupération d’urgence économique en utilisant des ressources minimales.

• Utilisez Azure Site Recovery ou Zerto si des machines virtuelles Azure IaaS sont la cible de récupération d'urgence pour le cloud privé Azure VMware Solution.

• Réduisez les entrées manuelles à l’aide des plans de reprise d’activité automatisés dans chacune des solutions de récupération d’urgence respectives. Ces plans sont utiles lors de l’utilisation de VMware Site Recovery Manager ou de solutions partenaires. Un plan de reprise d’activité rassemble les machines dans des groupes de reprise d’activité à des fins de basculement. Cela permet ensuite de définir un processus de récupération systématique en créant des unités indépendantes pouvant faire l’objet d’un basculement.

• Configurez des tests d’acceptation de build ou des exercices de récupération d’urgence au moins une fois par an pour vous assurer que les plans de récupération fonctionnent comme prévu. Les fonctionnalités d’orchestration de l’outil de récupération d’urgence choisi déterminent le niveau d’effort appliqué lors de ces exercices.

• Utilisez des paires géopolitiques régionales comme environnement de récupération d’urgence secondaire. Certains des avantages des paires régionales sont la récupération de région prioritaire, les mises à jour séquentielles, l’isolation physique et la résidence des données.

• Conservez des espaces d’adressage différents pour éviter les chevauchements d’adresses IP entre les deux sites. Par exemple, vous pouvez utiliser 192.168.0.0/16 pour la région 1 et 10.0.0.0/16 pour la région 2.

• Utilisez la connectivité ExpressRoute Global Reach entre les clouds privés principal et secondaire dans différentes régions. Pour plus d’informations sur les considérations et recommandations relatives au réseau, consultez la zone de conception appropriée.

Étapes suivantes

Découvrez les considérations et recommandations relatives au déploiement initial d’Azure VMware Solution ainsi que les conseils d’aide relatifs à l’automatisation opérationnelle.

Automatisation de plateforme pour Azure VMware Solution