Nutanix Leap – Disaster Recovery
Atteignez vos objectifs RPO et RTO sans effort grâce à Nutanix, que vous répliquiez vers un site de reprise après sinistre ou dans le cloud.
Les solutions Nutanix de Reprise après désastre
Les snapshots Nutanix sont un premier élément essentiel d’une stratégie globale de protection des données. Prism Element sur chaque cluster offre nativement le Protection Domain (PD), qui est un regroupement de machines virtuelles. Lors d’un événement de basculement, toutes les entités du domaine de protection sont activées sur le site distant en tant que groupe. Chaque VM doit être placée manuellement dans un PD, soit via Prism, soit via l’API.
L’une de leurs limites est qu’ils ne fournissent pas de contrôles supplémentaires autour des machines virtuelles associées à un basculement à grande échelle, comme l’orchestration de la reprise ou la modification de l’adresse IP de la machine virtuelle en raison d’un changement de site.
Prism Central a introduit une fonctionnalité appelée Leap, qui permet des constructions plus avancées relatives à la réplication et au basculement. Des stratégies de protection permettent de configurer le regroupement de réplication à l’aide de catégories.
Nutanix Leap entre deux sites « On-Prem »
Leap protège les VMs et orchestre leur reprise après vers d’autres clusters Nutanix lorsque des événements provoquant une interruption de service se produisent dans la zone de disponibilité principale (AZ ou site physique). Pour protéger les VMs, des stratégies de protection avec des planifications de réplication asynchrone, NearSync ou synchrone génèrent et répliquent des points de récupération vers d’autres zones de disponibilité (sites) sur site.
Les machines virtuelles qui correspondent à une catégorie sont automatiquement protégées en fonction de l’engagement de service.
Leap fournit également les plans de récupération qui permettent de contrôler le processus de basculement.
Ils permettent de spécifier :
- La mise sous tension
- Le mappage des réseaux lors de l’utilisation de DHCP
- La modification des adresses IP statiques pour les sites qui n’ont pas accès au même réseau de niveau L2 étendu,
- Les scripts à exécuter dans les actions d’invité dans le cadre du basculement (si nécessaire)
- Des tests de basculement et la validation de la configuration sans temps d’arrêt dans un environnement réseau isolé
Une organisation en mode cloud et en niveau de service
Le design Nutanix classique fournit une protection complète de reprise après sinistre pour les applications des deux zones de disponibilité dans une seule région. On peut considérer le site primaire comme une zone (AZ01) et le second site comme une seconde zone (AZ02).
Les applications peuvent tirer parti de l’infrastructure sous-jacente pour fournir une résilience de reprise après sinistre basée sur trois niveaux de protection différents avec une réplication bidirectionnelle entre les zones de disponibilité, de la même manière que le produit de sauvegarde tier HYCU.
Les catégories utiles à Leap peuvent être représentés sous la forme de trois niveaux de protection des données différents :
- Bronze : RPO = 1 heure et plus
- Argent : RPO = 15 minutes
- Or : RPO = 0 minutes
Le nombre maximal de machines virtuelles dans chaque catégorie dépend du niveau de protection des données. L’éditeur propose d’utiliser des catégories dans Prism Central (PC) pour automatiser le placement des machines virtuelles dans la stratégie de protection cible. Pour simplifier le basculement et le retour arrière, il faudra affecter les machines virtuelles à une catégorie locale (par exemple, les machines virtuelles qui s’exécutent sur AZ02 à une catégorie avec le préfixe AZ02). L’infrastructure n’est plus composée de deux sites, mais d’un Cloud privé.
Conception de l’infrastructure : workloads mélangés
La décision de mélanger les workloads au sein d’un cluster ou de dédier un cluster pour chaque type de workload est généralement une question d’échelle.
Par exemple, quand un client dispose de 200 VMs, d’un petit serveur Exchange et de 10 VMs moyennes dédiées à la BDD, le mélange des workloads sur un seul cluster est courant et peut être facilement géré. Cependant, si l’une ou l’ensemble de ces charges de travail augmentent de 5 à 10 fois, la complexité du dimensionnement et de l’exploitation de l’environnement mixte augmente considérablement.
Conception de l’infrastructure : architecture en POD
La recommandation sur des infrastructures HCI importantes oriente vers la conception d’une architecture en POD. Elle présente les caractéristiques suivantes :
- Deux centres de données actifs-actifs dans des zones de disponibilité distinctes avec moins de 5 ms de latence entre les sites.
- Un petit cluster de gestion dans chaque site qui héberge des services tels que Prism Central et AD.
- Une instance de Prism Central hébergée dans le cluster de gestion de chaque centre de données (double déploiement Prism Central par POD).
- Un ou plusieurs clusters dédiés aux différents types de workload dans chaque centre de données qui héberge les VMs des différents environnements de production.
- Une infrastructure de sauvegarde sur chaque site, que nous répliquons entre les sites pour la reprise après sinistre.
Chaque paire de POD peut ainsi évoluer de façon indépendante en fonction des contraintes et des besoins des workloads hébergés (ressources, criticité, architecture applicative, licences).
Adapter la récupération après sinistre au business
Lors de la conception d’une nouvelle solution PCA/PRA, assurez-vous de référencer les exigences métiers et les contraintes techniques.
Même si Nutanix fournit une gamme de mécanismes de protection pour aider à la protection des données, il faut appliquer cette recommandation :
- Si une application dispose de mécanismes de protection des données natifs (par exemple, Exchange DAG, MS SQL AlwaysOn, Oracle RAC), exploitez-les pour assurer la protection des données de l’application.
- Si une application ne fournit pas de mécanisme de protection des données, utilisez les mécanismes de protection intégrés Nutanix.
De là, la classification des applications selon les RPO/RTO et les exigences métiers pourront se faire, et leurs placements dans les catégories Or, Argent ou Bronze.
L’architecture réseau en fonction des besoins
Il est important de faire la différence entre le RPO=0 et le « Zero downtime » :
- RPO=0 signifie qu’il n’y aura pas de perte de données, mais n’engage en rien sur le RTO qui peut-être beaucoup plus long.
- Zero downtime ou l’absence d’interruption de service implique que les moyens matériels et logiciels mis en œuvre permettent à l’application de fonctionner en permanence, peu importe le désastre.
L’architecture réseau qui découlera des besoins exprimés sera complètement différente et impliquera des charges différentes :
- En cas de RPO supérieur ou égal à 0, le réseau étendu L2 n’est pas obligatoire. Cela implique que les équipes Ops et réseaux devront préparer le ré-adressage lors des bascules entre les sites. La charge reposera donc sur la mise en place des scripts qui permettront ce changement de réseau.
- En cas de Zero downtime, le réseau étendu L2 devient obligatoire. La charge repose alors sur l’équipe réseau, qui devient plus complexe à maintenir avec une vision multi-site.
Pour étendre les VLAN L2 aux centres de données connectés via un réseau de couche 3 (L3), la technologie VXLAN (Virtual eXtensible Local Area Network) est déployée, qui superpose le VLAN L2 sur le réseau de sous-couche L3. Le VXLAN est un mécanisme de tunneling qui permet aux hôtes/machines virtuelles d’être placés n’importe où dans l’infrastructure et de communiquer comme s’ils se trouvaient sur le même VLAN.
Pour répondre à l’ensemble des contraintes liées aux réseaux et à leur latence, Mikadolabs utilise les solutions Nvidia Networking (Anciennement Mellanox).
Contactez-nous directement pour adresser vos projets de Virtualisation avec Nutanix
