Partager via

Vue d’ensemble des clusters étendus

  • Article

S’applique à : Azure Local, version 22H2

Important

Azure Stack HCI fait désormais partie d’Azure Local. Le changement de nom de la documentation produit est en cours. Toutefois, les versions antérieures d’Azure Stack HCI, par exemple 22H2, continueront de référencer Azure Stack HCI et ne reflèteront pas la modification du nom. Plus d’informations

Important

Les clusters étendus ne sont pas encore pris en charge dans Azure Stack HCI version 23H2.

Une solution de cluster étendu Azure Stack HCI pour la récupération d’urgence fournit un basculement automatique pour restaurer rapidement la production 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 reflète les données entre 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 ont des 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 mis en ligne automatiquement après le basculement. Si la réplication est en cours au moment de l’échec, vous devez mettre en ligne manuellement le volume de destination.

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é si un site subit une panne ou une défaillance.

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. En règle générale, il existe quatre façons différentes de gérer la modification de l’adresse IP sur la machine virtuelle lors du basculement. Il peut y avoir d’autres, mais cet article couvre les quatre premiers.

La première et la plus simple consiste à utiliser DHCP. Lors du déplacement d’une machine virtuelle d’un site vers un autre, la machine virtuelle demande une adresse DHCP. Cela obtient l’adresse IP appropriée pour le site dans la mesure où un serveur DHCP est disponible.

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. Par conséquent, un script doit être créé pour affecter l’adresse IP appropriée pour la machine virtuelle en fonction du site sur lequel il 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 la machine virtuelle est activée et définir un schéma d’adresse IP 1.x s’il se trouve dans SiteA ou dans un schéma d’adresses IP 156.x s’il se trouve dans SiteB. Les services dns (Domain Name Services) doivent également être alertés sur la modification et répliqués entre les sites.

Une autre option est l’utilisation d’un périphérique réseau intermédiaire qui fournit une adresse IP unique pour la machine virtuelle pour la connectivité du client, qui peut acheminer le trafic vers la machine virtuelle. Les clients et DNS ont toujours la même adresse pour la machine virtuelle, et l’appareil intermédiaire doit suivre l’adresse IP et l’emplacement réels de la machine virtuelle afin que les clients soient dirigés vers la machine virtuelle de manière appropriée.

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