Modifier

Utiliser des clusters étendus Azure Stack HCI pour la reprise d’activité

Stockage Blob Azure
Sauvegarde Azure
Azure Monitor
Azure Stack HCI

L’architecture de référence suivante illustre la conception et l’implémentation de la récupération d’urgence d’Azure Stack HCI à l’aide de clusters étendus.

Architecture

Diagramme illustrant un cluster étendu Azure Stack HCI actif/actif et actif/passif, avec les volumes de stockage et l’historique des performances du cluster répliqués via le réplica de stockage.En mode actif/actif, le trafic de réplication est bidirectionnel, avec les deux sites hébergeant les machines virtuelles Azure Stack HCI. En mode actif/passif, la réplication est unidirectionnelle, avec le site actif hébergeant les machines virtuelles Azure Stack HCI.

Téléchargez un fichier Visio de cette architecture.

Components

L’architecture intègre les fonctionnalités et composants suivants :

  • Azure Stack HCI (20H2) . Azure Stack HCI est une solution de cluster d’infrastructure hyperconvergée qui héberge des charges de travail Windows et Linux virtualisées et leur stockage dans un environnement local hybride. Le cluster étendu peut comporter entre 4 et 16 nœuds physiques.
  • Réplica de stockage . Le réplica de stockage est une technologie Windows Server qui permet la réplication de volumes entre des serveurs ou des clusters pour la récupération d’urgence.
  • Migration dynamique. La migration dynamique est une fonctionnalité Hyper-V de Windows Server qui vous permet de déplacer facilement des machines virtuelles en cours d’exécution d’un ordinateur hôte Hyper-V vers un autre, sans temps d’arrêt perçu.
  • Témoin de cloud . Un témoin de cloud est un type de témoin de quorum de cluster de basculement qui utilise le stockage Blob Microsoft Azure pour fournir un vote sur le quorum du cluster.

Détails du scénario

Cette architecture sert en général à la récupération d’urgence avec basculement automatique des machines virtuelles Azure Stack HCI et des partages de fichiers entre deux emplacements physiques dans une plage de 5 ms de latence réseau aller-retour.

Recommandations

La suggestion suivante s’applique à la plupart des scénarios. Suivez cette suggestion, sauf si vous avez un besoin spécifique qui vous oblige à l’ignorer.

Utilisez des clusters étendus pour implémenter la récupération d’urgence automatisée pour les charges de travail virtualisées et les partages de fichiers hébergés sur Azure Stack HCI

Pour améliorer la résilience intégrée d’Azure Stack HCI, implémentez un cluster étendu Azure Stack HCI qui se compose de deux groupes de nœuds, avec un groupe par site. Chaque groupe doit contenir au moins deux nœuds. Le nombre total de nœuds dans un cluster ne peut pas dépasser le nombre maximal de nœuds pris en charge par un cluster Azure Stack HCI. Les nœuds doivent correspondre à la configuration matérielle HCI standard.

Les clusters étendus Azure Stack HCI s’appuient sur le réplica de stockage pour effectuer une réplication de stockage synchrone entre les volumes de stockage hébergés par les deux groupes de nœuds dans leurs sites physiques respectifs. Si une défaillance affecte la disponibilité du site principal, le cluster transfère automatiquement ses charges de travail vers les nœuds du site survivant pour réduire le temps d’arrêt potentiel. Pour les temps d’arrêt planifiés ou attendus sur le site principal, vous pouvez utiliser la migration dynamique Hyper-V pour transférer en toute transparence des charges de travail vers l’autre site, évitant ainsi les temps d’arrêt. Pour ce scénario, vous devez être attentif à l'emplacement de stockage. Vous devez d'abord inverser le sens de réplication du réplica de stockage, puis effectuer la migration en direct des machines virtuelles. Cela aura un impact sur les performances jusqu'à ce que la migration en direct soit terminée.

Notes

La réplication synchrone garantit la cohérence des incidents sans aucune perte de données au niveau du système de fichiers pendant le basculement.

Attention

L’exigence de réplication synchrone applicable aux clusters étendus impose une limite de 5 ms de latence réseau entre deux groupes de nœuds de cluster dans les sites répliqués. En fonction des caractéristiques de connectivité du réseau physique, cette contrainte se traduit généralement par environ 30-40 kilomètres de distance.

Notes

La fonctionnalité de signature et de chiffrement du réplica de stockage protège automatiquement le trafic de réplication.

Considérations

Le cadre de référence Microsoft Azure Well-Architected Framework est un ensemble de principes directeurs qui sont suivis dans cette architecture de référence. Les considérations suivantes s’inscrivent dans le contexte de ces principes.

Fiabilité

La fiabilité permet de s’assurer que votre application tient vos engagements auprès de vos clients. Pour plus d’informations, consultez la page Vue d’ensemble du pilier de fiabilité.

  • Domaines d’erreur au niveau du site. Chaque site physique d’un cluster étendu Azure Stack HCI représente des domaines d’erreur distincts qui offrent une résilience supplémentaire. Un domaine d’erreur est un ensemble de composants matériels qui partagent un point de défaillance unique. Pour bénéficier d’une tolérance de panne à un niveau particulier, vous avez besoin de plusieurs domaines d’erreur à ce niveau.

Notes

Si chaque emplacement correspond à un site AD DS distinct, le processus d’approvisionnement du cluster configure automatiquement l’attribution de site. S’il n’existe aucun site de AD DS distinct représentant les deux emplacements, mais que les nœuds se trouvent sur deux sous-réseaux différents, le processus d’approvisionnement du cluster identifie les sites en fonction des attributions de sous-réseau. Si les nœuds se trouvent sur le même sous-réseau, vous devez définir explicitement l’attribution de site.

  • Connaissance du site. La connaissance du site vous permet de contrôler le positionnement des charges de travail virtualisées en désignant leurs sites préférés. La spécification du site préféré pour un cluster étendu offre de nombreux avantages, notamment la possibilité de regrouper des charges de travail au niveau du site et de personnaliser les options de vote de quorum. Par défaut, lors d’un démarrage à froid, toutes les machines virtuelles utilisent le site préféré, bien qu’il soit également possible de configurer le site préféré au niveau du rôle ou du groupe de clusters. Cela vous permet d’allouer des machines virtuelles à leurs sites respectifs en mode actif/actif. Du point de vue du quorum, le choix du site préféré affecte l’allocation des votes de manière à privilégier ce site. Par exemple, si la connectivité entre les deux sites hébergeant des nœuds de cluster étendu échoue et que le témoin du cluster n’est pas accessible, le site préféré reste en ligne, tandis que les nœuds de l’autre site sont supprimés.

  • Amélioration de la vitesse de réparation des volumes des espaces de stockage direct. Storage Spaces Direct permet une resynchronisation automatique après des événements qui affectent la disponibilité des disques dans son pool de stockage, tels que l’arrêt d’un des nœuds du cluster ou une panne matérielle localisée. Azure Stack HCI met en œuvre un processus de resynchronisation amélioré à une granularité beaucoup plus fine que Windows Server 2019. Ce processus réduit considérablement la durée de l’opération de resynchronisation et réduit l’impact potentiel de plusieurs défaillances matérielles simultanées.

  • Limites de la résilience. Azure Stack HCI offre plusieurs niveaux de résilience, mais en raison de son architecture hyperconvergée, cette résilience est soumise à des limites imposées non seulement par le quorum du cluster, mais également par le quorum du pool.

  • Intégration à une gamme de services Azure qui offrent d’autres avantages en termes de résilience. Vous pouvez intégrer les charges de travail virtualisées s’exécutant sur les clusters Azure Stack HCI avec des services Azure tels que Sauvegarde Azure et Azure Site Recovery.

  • Basculement accéléré. Vous pouvez optimiser l’infrastructure réseau et sa configuration pour accélérer un basculement au niveau du site. Par exemple, vous pouvez tirer parti des réseaux locaux virtuels (VLAN) étendus, des périphériques d’abstraction réseau et des valeurs de durée de vie plus courtes dans les enregistrements DNS représentant les ressources en cluster. En outre, envisagez de réduire la période de résilience par défaut, qui détermine la durée pendant laquelle une machine virtuelle en cluster est autorisée à s’exécuter dans un état isolé.

Attention

L’utilisation de clusters étendus avec SDN est considérée comme une configuration avancée et vous devez contacter votre intégrateur système ou le support Microsoft pour obtenir de l’aide.

Sécurité

La sécurité fournit des garanties contre les attaques délibérées, et contre l’utilisation abusive de vos données et systèmes importants. Pour plus d’informations, consultez Vue d’ensemble du pilier Sécurité.

  • Protection des données en transit. Le réplica de stockage offre une sécurité intégrée pour le trafic de réplication, notamment la signature des paquets, le chiffrement AES-128-GCM Full Data Encryption, la prise en charge de l’accélération de chiffrement Intel AES-NI et l’intégrité de pré-authentification pour la prévention des attaques de l’intercepteur. Le réplica de stockage utilise également le protocole Kerberos AES256 pour l’authentification entre les nœuds de réplication.

  • Chiffrement au repos. Azure Stack HCI prend en charge le chiffrement de lecteur BitLocker pour ses volumes de données, ce qui facilite la conformité avec les normes FIPS 140-2 et HIPAA.

  • Intégration à une gamme de services Azure qui offrent d’autres avantages en termes de sécurité. Vous pouvez intégrer les charges de travail virtualisées s’exécutant sur les clusters Azure Stack HCI à des services Azure tels que Microsoft Defender pour le cloud

  • Configuration conviviale du pare-feu. Le trafic du réplica de stockage nécessite un nombre limité de ports ouverts entre les nœuds de réplication.

Attention

Le réplica de stockage et les clusters étendus Azure Stack HCI doivent fonctionner dans un environnement AD DS. Lors de la planification de votre déploiement de clusters étendus Azure Stack HCI, assurez la connectivité aux contrôleurs de domaine AD DS dans chaque site hébergeant des nœuds de cluster.

Optimisation des coûts

L’optimisation des coûts consiste à examiner les moyens de réduire les dépenses inutiles et d’améliorer l’efficacité opérationnelle. Pour plus d’informations, consultez Vue d’ensemble du pilier d’optimisation des coûts.

  • Configuration active/active et active/passive. Les clusters étendus Azure Stack HCI prennent en charge les modes actif/passif et actif/actif. En mode actif/passif, le site principal désigné est répliqué de manière unidirectionnelle vers un autre site qui assure la fonctionnalité de récupération d’urgence. En mode actif/actif, les deux sites répliquent leurs volumes respectifs de manière unidirectionnelle entre eux, ce qui offre la possibilité de basculement en cas de défaillance de l’un ou l’autre site. Le mode actif/actif permet de réduire les coûts de continuité des activités en éliminant le besoin d’un site de récupération d’urgence dédié.

  • Témoin de cloud et témoin de partage de fichiers. La ressource témoin est un composant obligatoire dans les clusters Azure Stack HCI. Pour l’implémenter, choisissez un témoin de cloud Azure ou un témoin de partage de fichiers. Le témoin de cloud Azure s’appuie sur un objet blob dans un compte de stockage Azure que vous désignez comme point d’arbitrage pour empêcher les scénarios de fractionnement. Le témoin de partage de fichiers repose sur un partage de fichiers SMB (Server Message Block) pour ce même objectif.

Notes

Azure Cloud Witness est le choix recommandé pour les clusters étendus Azure Stack HCI, à condition que tous les nœuds serveur du cluster disposent de connexions Internet fiables. Les frais Azure correspondants sont négligeables. Ils sont basés sur le prix d’un petit objet blob avec des mises à jour peu fréquentes correspondant aux modifications apportées à l’état du cluster. Dans les scénarios qui impliquent des clusters étendu, le témoin de partage de fichiers doit se trouver sur un troisième site, ce qui peut augmenter considérablement les coûts d’implémentation, sauf si le troisième site est déjà disponible et dispose de connexions existantes et fiables aux sites hébergeant les nœuds de cluster étendus.

  • Déduplication des données. Azure Stack HCI et le réplica de stockage prennent en charge la déduplication des données. À compter de Windows Server 2019, la déduplication est disponible sur les volumes formatés avec le système de fichiers résilient (ReFS), qui est le système de fichiers recommandé pour Azure Stack HCI. La déduplication permet d’augmenter la capacité de stockage utilisable en identifiant les portions de fichiers en double et en les stockant une seule fois.

Attention

Bien qu’il soit recommandé d’installer le service de rôle serveur de déduplication des données sur les serveurs source et destination, n’activez pas la déduplication des données sur les nœuds de destination au sein d’un cluster étendu Azure Stack HCI. Étant donné que la déduplication des données gère les écritures, elle doit s’exécuter uniquement sur les nœuds du cluster source. Les nœuds de destination reçoivent toujours des copies dédupliquées de chaque volume.

Excellence opérationnelle

L’excellence opérationnelle couvre les processus d’exploitation qui déploient une application et maintiennent son fonctionnement en production. Pour plus d’informations, consultez Vue d’ensemble du pilier Excellence opérationnelle.

  • Basculement et récupération automatiques. Toute défaillance du site principal déclenche un basculement automatique. Suite au basculement, le processus d’établissement de la réplication à partir du nouveau site secondaire principal/précédent vers le nouveau site principal secondaire/ancien est également automatique. Pour éviter toute perte de données, le cluster empêche la restauration automatique jusqu’à ce que les volumes répliqués soient entièrement synchronisés.

  • Expérience de configuration et de gestion simplifiée avec Windows Admin Center. L’Assistant Création d’un cluster dans le centre d’administration Windows fournit une interface pilotée par un assistant pour vous guider tout au long du processus de création d’unde cluster étendu Azure Stack HCI. L’Assistant détecte si les nœuds de cluster se trouvent dans deux sites Active Directory Domain Services (AD DS) distincts ou si leurs adresses IP appartiennent à deux sous-réseaux différents. S’ils se trouvent dans deux sous-réseaux différents, l’Assistant crée et configure automatiquement les sites de cluster correspondants, chacun représentant un domaine d’erreur distinct. Il vous permet également de désigner le site préféré. De même, Windows Admin Center simplifie le processus d’approvisionnement des volumes répliqués.

Notes

La création de volumes et de disques virtuels pour les clusters étendus est plus complexe que pour les clusters à site unique. Les clusters étendus nécessitent au minimum quatre volumes, se composant de deux volumes de données et deux volumes de journaux, avec une paire de volumes données/journaux sur chaque site. Lorsque vous créez un volume de données répliqué à l’aide du centre d’administration Windows, le processus provisionne automatiquement le volume du journal dans le site principal, ainsi que les volumes de données et de journaux répliqués sur le site secondaire, garantissant ainsi que la taille et les paramètres de configuration requis sont définis pour chacun d’eux.

  • Prise en charge de l’approvisionnement automatisé des clusters étendus et de la gestion du stockage avec Windows PowerShell. Vous pouvez exécuter PowerShell localement à partir de l’un des serveurs Azure Stack HCI ou à distance à partir d’un ordinateur de gestion.

  • Intégration à une gamme de services Azure qui offrent d’autres avantages opérationnels. Vous pouvez intégrer des charges de travail virtualisées s’exécutant sur des clusters Azure Stack HCI avec des services Azure comme Azure Monitor et les solutions Azure Automation, y compris le suivi des modifications et inventaire et la gestion des mises à jour. Après à une procédure d’inscription obligatoire initiale, les clusters Azure Stack HCI peuvent tirer parti d’Azure Arc pour la surveillance et la facturation. L’intégration Azure Arc offre une meilleure intégration aux autres services hybrides, tels que Azure Policy et Log Analytics. L’inscription déclenche la création d’une ressource Azure Resource Manager pour représenter chaque cluster Azure Stack HCI local, étendant le plan de gestion Azure à Azure Stack HCI.

Efficacité des performances

L’efficacité des performances est la capacité de votre charge de travail à s’adapter à la demande des utilisateurs de façon efficace. Pour plus d’informations, consultez Vue d’ensemble du pilier d’efficacité des performances.

  • Réplication optimisée du trafic. Lors de la conception d’une infrastructure pour les clusters étendus Azure Stack HCI, envisagez un réplica de stockage supplémentaire, la migration dynamique et le trafic de l’historique des performances du cluster de réplication de stockage entre les sites. La réplication synchrone requiert au moins 1 Go de mémoire RDMA ou une connexion Ethernet/TCP entre les sites du cluster étendu. Toutefois, en fonction du volume de trafic de réplication, vous aurez peut-être besoin d’une connexion RDMA plus rapide. Vous devez également approvisionner plusieurs connexions entre les sites, ce qui offre des avantages en matière de résilience et vous permet de séparer le trafic de du réplica de stockage du trafic de migration dynamique Hyper-V.

Attention

L’accès RDMA est activé par défaut pour tout le trafic entre les nœuds de cluster d’un même site sur le même sous-réseau. L’accès RDMA est désactivé et n’est pas pris en charge entre les sites ou entre différents sous-réseaux. Vous devez soit désactiver le SMB direct pour le trafic intersites, soit implémenter des dispositions supplémentaires qui le séparent du trafic entre nœuds au sein du même site.

Notes

Le centre d’administration Windows affecte automatiquement la configuration optimale si vous l’utilisez pour l’approvisionnement des volumes de cluster étendus.

Étapes suivantes