Brève description de la solution
Stratus everRun® SplitSite®
Protection de la disponibilité à l'échelle du métro
Les catastrophes, qu'elles soient d'origine naturelle ou humaine, peuvent entraîner la perte totale d'un data center physique, ce qui peut empêcher votre entreprise de fonctionner pendant des jours, voire des semaines. Dans les secteurs réglementés, un problème à l'échelle d'un site peut entraîner une perte de données qui risque de compromettre la conformité, ce qui augmente considérablement vos coûts d'immobilisation. C'est pourquoi les entreprises des secteurs réglementés comme les produits pharmaceutiques, la fabrication et les services financiers utilisent la protection de everRun SplitSite pour garantir que toutes les données sont répliquées en toute sécurité et restent disponibles à tout moment. Bien que de nombreuses entreprises continuent de remettre à plus tard la mise en œuvre d'une solution de récupération, craignant des coûts élevés et des demandes de ressources, vous n'avez plus besoin de supporter ce risque.
everRun SplitSite étend la protection de votre entreprise contre les pannes de courant localisées et les problèmes à l'échelle du bâtiment aux machines physiques situées dans différents bâtiments ou centres de données. Avec everRun SplitSite, si une catastrophe survient à un endroit, les applications et les données sont immédiatement disponibles, à jour et pleinement opérationnelles à l'autre endroit, sans qu'il soit nécessaire de faire appel à du personnel informatique sur le second site. Une configuration SplitSite relie deux machines physiques (PM) dans deux sites géographiquement séparés. SplitSite assure la disponibilité des applications grâce à une réplication synchrone. La capacité de SplitSite de everRunpermet à un client d'exécuter ses applications efficacement, mais avec des latences plus élevées lorsque les serveurs de everRun sont séparés géographiquement ou par des commutateurs de réseau. Les niveaux de protection HA (haute disponibilité) et FT (tolérant aux pannes) peuvent être utilisés, sans modification des caractéristiques ou de la disponibilité. Comme dans une configuration à site unique, everRun détecte automatiquement les défaillances des disques et du réseau et se configure en conséquence. Et pour les machines virtuelles (VM) avec protection FT, everRun maintiendra les VM en fonctionnement sans aucun temps d'arrêt, même en cas de défaillance d'une PM ou d'un site. Lorsqu'un site ou une MP défaillant est remis en service, everRun resynchronisera automatiquement les lecteurs de disque et la mémoire des VM.
Le SplitSite deeverRunsoutient les déploiements tolérants aux catastrophes qui maintiennent la redondance du matériel, ainsi que la redondance des salles informatiques physiques et des bâtiments qui les contiennent. En prenant en charge la séparation géographique, cette puissante solution de tolérance aux catastrophes protège davantage votre entreprise contre les interruptions majeures dues à des événements potentiellement catastrophiques tels que les inondations et les pannes de courant. everRun SplitSite élimine le coût et le chaos associés aux produits de récupération réactifs habituels. Stratus voit souvent SplitSite utilisé dans les grands campus ou les zones métropolitaines comme une alternative en temps réel à la récupération multi-sites.
Exigences relatives aux sites partagés et octroi de licences
Il n'y a pas de limitation de distance universelle pour SplitSite, car un certain nombre de facteurs entrent en jeu. Tout commutateur réseau intervenant ajoute à la latence et augmente la possibilité de perdre la connexion entre les nœuds, ce qui entraîne un "split brain" - une situation où aucun des serveurs ne peut vérifier que l'autre fonctionne toujours, ce qui fait que deux copies de la même VM fonctionnent indépendamment. Pour toutes les configurations de SplitSite, Stratus exige que vous utilisiez également le service de quorum car une configuration SplitSite augmente la probabilité de scénarios supplémentaires de défaillance de type "split brain".
Les configurations SplitSite sont soumises à des spécifications de latence maximale : Latence maximale de 10 ms aller-retour sur le lien A pour les VM HA et de 2 ms aller-retour sur le lien A pour les VM FT. La séparation jusqu'à 10 km (en utilisant une fibre de 1 Gbps) est une topologie de réseau A-Link commune qui peut répondre aux exigences de latence. Les performances des applications individuelles, même dans le cadre de ces spécifications de latence, peuvent dépendre de l'application spécifique.
Seule une licence d'utilisation du quorum et le respect des exigences de latence sont nécessaires pour le support de Stratus. Sinon, tout équipement de réseau et toute topologie sont pris en compte. Dans un réseau classique typique, la distance entre les serveurs est de 5 à 10 km. Toutefois, Stratus a des clients qui utilisent avec succès SplitSite aujourd'hui dans des scénarios où les PM sont distants de 50 km ou plus.
Une configuration SplitSite nécessite une planification minutieuse du placement des composants, afin de minimiser ou d'éliminer les pannes qui nécessitent l'arrêt des VM. Une formation spécifique ou l'assistance de services professionnels sont très probablement nécessaires pour déployer correctement SplitSite. Si un client utilise SplitSite, il est obligé d'acheter une licence ; cependant, Stratus n'applique pas SplitSite par l'activation de fonctionnalités. Une licence SplitSite est cependant nécessaire pour bénéficier d'une assistance technique sur une configuration SplitSite. Stratus a choisi une séparation physique de 10 m comme point de démarcation à distance raisonnable pour exiger une licence SplitSite.
Serveurs SplitSite et Quorum
L'utilisation du quorum est nécessaire pour les configurations de SplitSite afin de se protéger contre la perte de données (due à un "split-brain") et de permettre aux VM de démarrer automatiquement en toute sécurité si un deuxième everRun PM ou site a échoué. Dans une configuration SplitSite, vous utiliserez au moins un, et idéalement deux, serveurs de quorum. Ces serveurs sont utilisés pour se protéger contre les défaillances du réseau qui pourraient faire perdre la communication entre les deux nœuds everRun et faire fonctionner le split-brain. La disponibilité du quorum est améliorée, et les scénarios d'arrêt obligatoire des machines virtuelles sont réduits au minimum si le quorum est placé à un troisième endroit et si une conception appropriée de réseau de quorum est mise en œuvre.
Si aucun serveur de quorum n'était configuré, une défaillance du réseau pourrait entraîner la perte de toute communication entre les deux serveurs everRun . Dans la même situation avec des serveurs de quorum configurés, les VM redondantes sur les deux nœuds demanderaient au serveur de quorum le statut de leur pair et prendraient les mesures appropriées en fonction de la réponse. Si le serveur de quorum ne répond pas, une VM isolée s'éteindra d'elle-même. Chaque fois que la VM du pair sur l'autre serveur reste en contact avec le serveur de quorum, elle continue à fonctionner. Les deux VM s'accordent sur le serveur de quorum utilisé (élu) avant toute défaillance. Si le serveur de quorum primaire tombe en panne, les nœuds s'accordent pour élire le serveur de quorum alternatif jusqu'à ce que le primaire reprenne du service. Pendant la gestion active d'une défaillance, les nœuds ne peuvent pas changer de serveur de quorum.
Les serveurs de quorum sont particulièrement importants dans les configurations SplitSite. La meilleure pratique pour SplitSite consiste à placer un serveur de quorum préféré dans un troisième site et un autre serveur de quorum dans un quatrième site. Toutefois, vous pouvez également placer le serveur de quorum alternatif avec le serveur de quorum préféré et obtenir un service satisfaisant. Les serveurs de quorum assurent l'intégrité des machines virtuelles contre le "split brain" et permettent le démarrage sans surveillance des machines virtuelles après des pannes spécifiques. La communication entre les serveurs de quorum se fait par l'intermédiaire du réseau de gestion.
Les serveurs de quorum ne nécessitent pas de matériel dédié ou n'ont pas de besoins spécifiques en matière de latence réseau. Ils fonctionnent comme un service Windows qui peut être installé sur presque tous les postes de travail ou serveurs Windows utilisés à d'autres fins, à condition que l'ordinateur reste opérationnel 24 heures sur 24. Cependant, il ne faut jamais faire fonctionner le service quorum dans une VM du même système everRun qui l'utilise.
En savoir plus sur les serveurs de quorum
Un service de quorum est un service basé sur le système d'exploitation Windows et déployé sur une machine Windows distincte du système everRun . Les serveurs de quorum offrent des garanties d'intégrité des données et des capacités de redémarrage automatique en cas de défaillance spécifique dans un environnement everRun . Vous pouvez configurer une paire de everRun PM avec 0, 1 ou 2 serveurs de quorum. Stratus recommande fortement de configurer deux serveurs de quorum : un serveur de quorum préféré et un autre - en particulier pour le fonctionnement de SplitSite. Si seulement deux sites sont disponibles, le quorum peut être placé sur l'un des sites sans risque de split-brain. Cependant, si un PM tombe en panne et que le PM survivant est incapable de communiquer avec le serveur de quorum (par exemple, parce qu'il est inaccessible sur le même site que le PM en panne), les VM du site survivant sont automatiquement arrêtées pour éviter un éventuel scénario de dédoublement de la charge de travail.
Dans une configuration SplitSite, les meilleures pratiques pour le déploiement du quorum comprennent :
- Un serveur de quorum privilégié situé dans un troisième site, et un suppléant situé dans un quatrième site (ou soigneusement placé dans le troisième)
- Les serveurs de quorum doivent être aussi isolés que possible. Si les deux doivent être placés sur un site commun (troisième), assurez-vous qu'ils ne dépendent pas de sources d'alimentation ou de commutateurs de réseau communs
- La connectivité physique entre un PM everRun et les serveurs de quorum ne doit pas passer par le site de l'autre PM
- Le fait de placer un serveur de quorum sur le même site que l'un des MP de everRun garantit l'intégrité des données. Toutefois, les défaillances de ce site exigent que les VM soient arrêtées (pour éviter les erreurs) jusqu'à ce qu'elles soient récupérées manuellement.
- Le réseau de gestion relie physiquement les MP et les serveurs de quorum. Configurez chaque PM de everRun pour qu'il utilise une passerelle différente pour atteindre les serveurs de quorum afin d'assurer la meilleure disponibilité des VM. Si les deux MP utilisent la même passerelle pour atteindre les serveurs du quorum, certaines défaillances du site entraîneront une panne de la passerelle et obligeront les VM à s'éteindre jusqu'à ce qu'elles soient récupérées manuellement
Considérations relatives au serveur de quorum
- Le logiciel du service Quorum peut être installé sur tout ordinateur ou portable à usage général fonctionnant sous Windows Server 2016, Server 2012, Server 2008, Windows 10 ou Windows 7 ; toujours sous tension et avec un espace disque minimum de 100 Mo et une carte d'interface réseau avec une connectivité à la configuration everRun via le réseau de gestion
- Les serveurs de quorum ne doivent pas résider sur le même site que l'un ou l'autre PM lors du déploiement dans un SplitSite. Si les serveurs de quorum préférés et alternatifs tombent en panne pour une raison commune, les VM déclasseront gracieusement la redondance, puis continueront à fonctionner avec un seul PM, en attendant la récupération d'un serveur de quorum. Chaque fois qu'un PM et le serveur de quorum élu tombent en panne pour une raison commune, les instances de VM fonctionnant sur le PM survivant doivent s'éteindre
- Si les serveurs de quorum préférés et alternatifs doivent résider sur un site commun, les alimenter à partir de sources d'alimentation en courant alternatif (phases) distinctes ou les configurer sur des dispositifs UPS distincts, et réduire au minimum la mise en réseau commune nécessaire au système everRun pour y accéder
Exigences relatives au réseau A-Link
- Les NIC doivent avoir au moins 1 Go et être en duplex intégral ; utilisez 10 Go, si possible
- Les commutateurs et/ou les convertisseurs de fibre à cuivre connectés au réseau privé doivent être non routés, non bloquants et supporter IPv6
- Pour les systèmes utilisant des VM protégées par FT, des A-Links sont nécessaires :
- Une bande passante minimale de 1 Gbps par VM
- Une latence intersite* maximale de 2 ms, aller-retour
- Pour les systèmes qui ne fonctionnent qu'avec des VM protégées par des HA, des A-Links sont nécessaires :
- Une bande passante minimale de 155 Mbps par VM
- Une latence inter-site* maximale de 10 ms, aller-retour
- Ne pas utiliser une carte commune (NIC multiport) pour plusieurs A-Links
- Les A-Links peuvent être des connexions fibre optique point à point dédiées ou sur un VLAN. Les VLAN utilisés pour connecter les ports A-Link ne doivent pas filtrer les communications entre les deux nœuds everRun
Exigences en matière de réseau privé
- Les NIC doivent être d'au moins 1 Go et en duplex intégral
- Le réseau privé ne doit pas être partagé avec un A-Link lors du déploiement d'une configuration SplitSite
- Le réseau privé peut être une connexion fibre optique point à point dédiée. Si ce n'est pas le cas, il doit être configuré sur un VLAN privé. Les VLAN utilisés pour connecter les ports du réseau privé doivent supporter IPv6 et ne pas filtrer les communications entre les deux nœuds everRun
Exigences en matière de réseau d'entreprises
- Un système everRun nécessite au moins un réseau d'entreprises. Configurez le réseau d'entreprise pour les deux nœuds du même VLAN
- Les nœuds doivent se trouver dans le même domaine de multidiffusion de couche 2
- Connectez les réseaux d'entreprises de chaque nœud à un commutateur distinct de celui de l'autre nœud. Les VLAN utilisés pour connecter les ports des réseaux d'entreprise doivent supporter IPv6 et ne pas filtrer les communications entre les deux nœuds everRun
Exigences du réseau de gestion
- Par défaut, le réseau de gestion est partagé avec un réseau d'entreprises. S'il n'est pas partagé, toutes les exigences relatives à un réseau d'entreprise continuent de s'appliquer
- Configurer les passerelles vers un réseau local d'entreprise pour la gestion à distance
* Calculer la latence à 1 ms pour chaque 100 miles de fibre, plus toute latence ajoutée par des commutateurs ou convertisseurs de fibre non routés et non bloquants.
