Vue d’ensemble des clusters étendus

  • Article

S’applique à : Azure Stack HCI, versions 22H2 et 21H2

Une solution de cluster étendu Azure Stack HCI pour la récupération d’urgence fournit un basculement automatique pour restaurer la production rapidement et sans intervention manuelle. Le réplica de stockage assure la réplication des volumes entre les sites pour la reprise d’activité, tous les serveurs restant synchronisés.

Le réplica de stockage prend en charge les réplications synchrones et asynchrones :

  • La réplication synchrone met en miroir les données entre des sites situés dans un réseau à faible latence avec des volumes cohérents en cas de plantage, ce qui permet d’éviter toute perte de données au niveau du système de fichiers durant une défaillance.
  • La réplication asynchrone met en miroir les données sur les sites au-delà des plages métropolitaines sur des liaisons réseau avec des latences plus élevées, mais sans garantie que les deux sites disposent de copies identiques des données au moment d’une défaillance. Si la réplication se termine avant l’échec, le volume de destination est automatiquement mis en ligne après le basculement. Si la réplication est en cours au moment de l’échec, vous devez mettre manuellement le volume de destination en ligne.

Il existe deux types de clusters étendus : actif/passif et actif/actif. Dans une réplication de site en mode actif/passif, vous indiquez un site et une direction pour la réplication. Dans une réplication en mode actif/actif, la réplication peut être bidirectionnelle entre les deux sites. Cet article traite uniquement du mode actif/passif.

Pour faire simple, un site actif est doté de ressources et fournit des rôles et des charges de travail auxquelles les clients se connectent. Un site passif ne fournit aucun rôle ni aucune charge de travail aux clients et attend un basculement du site actif pour assurer la reprise d’activité.

Les sites peuvent se trouver dans des régions différentes, des villes différentes, des étages différents ou des pièces différentes. Les clusters étendus utilisant deux sites fournissent une reprise d’activité et une continuité d’activité en cas de panne ou de défaillance d’un site.

Prenez quelques minutes pour visionner la vidéo sur le clustering étendu avec Azure Stack HCI :

Cluster étendu actif-passif

Dans le diagramme suivant, le site 1 est le site actif et la réplication est unidirectionnelle vers le site 2.

Scénario de cluster étendu actif/passif.

Cluster étendu actif/actif

Dans le diagramme suivant, le site 1 et le site 2 sont actifs et la réplication est bidirectionnelle entre les deux sites.

Scénario de cluster étendu actif/actif

Considérations relatives au basculement IP d’invité

Quand on parle de clustering étendu, les considérations à prendre en compte incluent les machines virtuelles et les adresses IP utilisées. Les centres de données qui résident à des emplacements différents ont généralement des sous-réseaux IP différents. Les adresses IP utilisées par les machines virtuelles peuvent être adéquates pour un centre de données, mais inaccessibles dans un autre. La planification de la gestion des changements d’adresse IP doit donc être prise en compte. Dans la plupart des cas, vous pouvez gérer le changement d’adresse IP sur la machine virtuelle lors du basculement de quatre façons différentes. Il existe peut-être d’autres méthodes, mais ce document traite des quatre principales.

La première et la plus simple consiste à utiliser DHCP. Quand vous déplacez une machine virtuelle d’un site à un autre, l’une des étapes du processus est la demande d’une adresse DHCP. Tant qu’un serveur DHCP est disponible, vous obtenez l’adresse IP du site dans lequel se trouve la machine virtuelle.

L’étape suivante est d’utiliser une adresse statique. Toutefois, contrairement à un réplica Hyper-V, il n’est pas possible de spécifier une autre adresse IP. Un script doit donc être créé afin d’affecter l’adresse IP appropriée pour la machine virtuelle en fonction du site où elle se trouve. Par exemple, SiteA utilise un réseau 1.x et SiteB un réseau 156.x. Ce script doit détecter le réseau sur lequel se trouve la machine virtuelle et définir un schéma d’adresse IP 1.x si elle se trouve dans SiteA ou 156.x si elle se trouve dans SiteB. Les services DNS (Domain Name Services) devront également être avertis de la modification et répliqués entre les sites.

Une autre option consiste à utiliser un périphérique réseau intermédiaire qui fournit une seule adresse IP pour la machine virtuelle pour la connectivité client, ce qui permet d’acheminer le trafic à destination de la machine virtuelle vers le site où elle se trouve actuellement. Les clients et le système DNS ont toujours la même adresse pour la machine virtuelle, et le périphérique intermédiaire doit effectuer le suivi de l’adresse IP et de l’emplacement de la machine virtuelle afin que les clients soient correctement dirigés vers la machine virtuelle.

La dernière option consiste à utiliser un vLAN étendu. Avec un vLAN étendu, les machines virtuelles peuvent conserver la même adresse IP, quel que soit le site où elles se trouvent. Toutefois, en raison de la complexité de la configuration et de la maintenance d’un vLAN étendu, cette option n’est pas recommandée par Microsoft.

Quelle que soit l’option que vous choisissez parmi celles listées ci-dessus, des considérations supplémentaires (DNS, caches ARP, TTL, etc.) doivent être prises en compte en ce qui concerne la connectivité client et faire l’objet d’une réflexion approfondie. Demandez à votre équipe réseau d’identifier la meilleure option en fonction de vos besoins.

Étapes suivantes