Il y a un petit centre de données près d'une entreprise manufacturière dans une petite ville assez loin de Moscou. Il est nécessaire 24 heures sur 24. Il se trouve qu'il n'y a qu'une seule entrée du secteur, mais il n'y a pas de groupe électrogène diesel. Parce que l'entreprise n'est pas une entreprise informatique, mais une entreprise de production, ils n'ont pas conçu correctement. Parce qu'une fois que tout a fonctionné.
Le rayon de puissance a commencé à jouer des farces. Chaque semaine, la lumière était coupée pendant plusieurs heures, et de manière loto: cela pouvait durer une heure ou plus. Il n'y a pas de modèles.
L'administrateur a suggéré d'acheter un diesel, mais l'entreprise a déclaré qu'il ne s'agissait pas d'une entreprise d'administration. Son travail consiste à prévoir des temps d'arrêt d'une heure au maximum. Ils ont simplement injecté beaucoup d'argent dans l'équipement, vous ne pouvez donc pas partir pour le cloud, et il n'y a pas de centre de données commercial pour transporter l'équipement là-bas.
Et que faire?
C'est avec cette tâche que le client est venu nous voir. Il n'y a pas beaucoup de budget, il faut chercher une solution valable.
Le cas normal (à l'exception de l'apparition de la deuxième entrée, du transfert d'équipement ou de l'apparition d'un générateur diesel) consiste à déployer la deuxième instance de la même instance exacte dans le cloud et à y basculer si quelque chose tombe soudainement. Il s'appelle Disaster Recovery. Certaines personnes construisent un deuxième centre de données pour elles-mêmes, il fait froid et attend que le principal tombe, ou il fonctionne en mode actif-actif, prenant 50% de la charge.
Mais il n'y a pas d'argent pour un deuxième centre de données complet.
Ils sont venus avec ceci:
Il y a un serveur physique lourd avec une base de données dans le centre de données du client. Et il existe des applications fonctionnant avec cette base de données, qui sont un ensemble de machines virtuelles sur ESXi.
Pour répliquer la base de données, ils ont installé le logiciel Carbonite Availability (anciennement connu sous le nom de Double-Take Availability) dans le cloud, qui fonctionne au niveau du système d'exploitation. Et pour la réplication des machines virtuelles sur lesquelles ils ont installé Zerto, ce logiciel fonctionne au niveau de l'hyperviseur. Les deux solutions fonctionnent à peu près de la même manière: tout d'abord, elles répliquent l'intégralité du volume des données du serveur vers le cloud, puis interceptent tous les enregistrements sur les disques du site principal et les dupliquent sur les disques vers le cloud. Le délai dans ce cas est spécifiquement de 10 secondes, c'est-à-dire que nous avons toujours une nouvelle copie des données il y a 10 secondes.
Les machines virtuelles ne sont pas incluses. En utilisant le bouton du panneau de configuration Zerto, nous pouvons démarrer toutes les machines virtuelles à la fois. Cela se produit dans environ 28 minutes (les machines démarrent en parallèle), SLA pendant 1 heure avec nous au repos. Le lancement se fait en appelant l'administrateur de service. Le client décide quand cela est nécessaire.
Les VM récupèrent la base et commencent à travailler.
Lors de la mise sous tension de l'installation, le client comprend lui-même son infrastructure. Traite les pannes, puis active manuellement la réplication inverse. La quantité de changements dans la base de données accumulée pendant le fonctionnement des applications est renvoyée. Répliqué - commutateur. Dans cet exemple spécifique, le trafic s'accumule pendant environ 5 minutes de rechargement pour chaque heure de machines virtuelles. Plus la durée de fonctionnement de l'instance d'urgence est longue, moins le trafic est partagé, car les enregistrements vont souvent aux mêmes tables de base de données et nous n'envoyons que la différence.
Après le retour dans le cloud, les machines virtuelles s'arrêtent. Le client ne paie pas les ressources désactivées. Nous quantifions par l'horloge.
Le paiement concerne uniquement la quantité de données stockées, le canal et la licence logicielle pour la réplication (Zerto et Carbonite). Nous travaillons sur le principe de "Disaster Recovery as a Service", nous donnons SLA pour cela. Et financièrement responsable de ce SLA.
Le client reproduit tout, une machine virtuelle avec les mêmes paramètres que sa physique, tous les disques durs sont mis en miroir.
Voici ce que fait Zerto:
Il a une réplication sans agent, il a un mode asynchrone, les machines virtuelles sur la plate-forme DR sont désactivées, la réplication de journal, l'optimisation WAN, la réplication inter-hyperviseurs, l'octroi de licences pour les machines virtuelles protégées.
Carbonite est une réplication d'agent, donc quel que soit l'hyperviseur, il existe un mode de fonctionnement asynchrone, il existe un support pour les instantanés, la compression des données transmises, l'octroi de licences pour les machines virtuelles protégées.
L'installation a appliqué les deux solutions à la fois. C'était donc nécessaire en raison d'un certain nombre de fonctionnalités. Habituellement, ils offrent une chose.
Vous pouvez également résoudre un problème similaire avec la solution domestique Veeam Cloud Connect (nous l'utilisons généralement si vous avez déjà une sauvegarde Veeam).
Résumé
Nous comprenons tous que le problème pourrait être résolu différemment en pompant l'installation côté serveur d'un générateur diesel. Cependant, l'entreprise a réduit les exigences relatives à l'organisation de la réserve. Nous avons fourni un service et cela a fonctionné. Il s'est avéré être un bon exemple de la façon dont vous pouvez déployer une plate-forme DR correctement et à peu de frais.
Les références