Imaginons que vous disposiez d’un groupe de disponibilité (AG) SQL Server dans votre centre de données virtualisé. Cet AG SQL Server héberge de nombreuses bases de données au service d’applications stratégiques. Le volume total de données stratégiques s’élève aujourd’hui à un demi-téraoctet, mais il augmente rapidement. Vous vous inquiétez de la disponibilité de ce serveur SQL Server, et c’est d’ailleurs pour cette raison que vous l’avez configuré dès le départ en tant que groupe de disponibilité AlwaysOn. De plus, vous savez pertinemment qu’un groupe de disponibilité ne protège pas contre les dysfonctionnements logiciels, les corruptions de données et les failles de sécurité ; vous souhaitez donc sauvegarder ce demi-téraoctet ailleurs, de préférence dans un environnement physiquement isolé du site de production. Dans le cas malheureux d’une perte de données, quel est le meilleur délai de Recovery (RTO) que votre fournisseur de sauvegarde peut vous proposer ?
Vous entendrez sans doute les fournisseurs de solutions de sauvegarde sur site vanter les mérites de la « restauration instantanée » des machines virtuelles. Le délai de reprise d’activité (RTO) promis se situe entre quelques secondes et quelques minutes. Mais lorsqu’il s’agit de restaurer une machine virtuelle (VM) à son niveau opérationnel de production, cette soi-disant « restauration instantanée » n’a rien d’« instantané ».
Ce que l’on appelle la « restauration instantanée » consiste à mettre à disposition les fichiers disque de la machine virtuelle à partir du système de sauvegarde via NFS et à laisser VMware vSphere exécuter la machine virtuelle à partir de ces fichiers disque. Il est vrai que le processus de démarrage d’une machine virtuelle à partir d’une sauvegarde de cette manière ne prend que quelques minutes. Il est vrai que le stockage flash des systèmes de sauvegarde peut servir de mécanisme de mise en cache pour les E/S d’écriture. Cependant, pour que la machine virtuelle soit pleinement opérationnelle en environnement de production, l’administrateur doit planifier et exécuter avec soin une opération de Storage vMotion au moment opportun. Ce processus permet de migrer les disques de la machine virtuelle du stockage de sauvegarde vers le stockage de production alors que la machine virtuelle est en cours d’exécution. Ce processus est souvent ralenti par vSphere afin de ne pas perturber le fonctionnement de la machine virtuelle en service. Il faut compter plusieurs heures, voire une journée entière, avant qu’une machine virtuelle volumineuse puisse être migrée et soit opérationnelle avec des performances de niveau production. Voilà pour le caractère « instantané » de la restauration instantanée !
Ainsi, dans l’exemple ci-dessus concernant le groupe de disponibilité (AG) de SQL Server, les nœuds doivent être desservis par un seul système de stockage de sauvegarde, ce qui va à l’encontre de l’intérêt même d’un AG. Le groupe de disponibilité est censé être configuré avec des systèmes de stockage dédiés à chaque nœud pour garantir la disponibilité. Dans ce cas, le cluster AG aurait du mal à se mettre en service, car la synchronisation serait extrêmement lente en raison des lectures d’E/S provenant du stockage de sauvegarde. Notez que le groupe de disponibilité est indisponible pendant cette période et qu’il n’y a donc pas vraiment de « Recovery instantanée ». Pour aggraver encore la situation, le groupe de disponibilité fonctionnerait au ralenti tandis que le vMotion de stockage nécessaire devrait s’effectuer depuis le stockage de sauvegarde surchargé vers le stockage de production.
Le problème lié à cette restauration instantanée ne s’arrête pas là. La sauvegarde se trouve toujours sur le même site que l’environnement de production et est donc exposée aux risques de perte de site et aux failles de sécurité. Vous ne pouvez pas utiliser le stockage dans le cloud comme destination de sauvegarde viable pour la reprise opérationnelle à partir de ces solutions. De plus, la restauration instantanée devient inutile dès lors que vous envisagez de migrer des charges de travail vers VMware Cloud on AWS, car le stockage NFS tiers n’est pas pris en charge.
Clumio Rapid Recovery – RTO opérationnel optimal
Assurez la Backup and Recovery sécurisée de vos données, où qu’elles se trouvent. Rapid Recovery est un ensemble de solutions innovantes proposées par Clumio qui permet des restaurations opérationnelles rapides à partir d’un stockage dans le cloud, même lorsque vous protégez des charges de travail sur site. Grâce à Rapid Recovery avec Clumio SaaS, il n’a fallu que 5 minutes pour restaurer un environnement SQL Server AG actif contenant 500 Go de données, comme indiqué dans l’exemple ci-dessus. Il s’agit du temps nécessaire à la restauration de bout en bout et au retour des données à un état pleinement opérationnel. Comment y sommes-nous parvenus ? Deux innovations de Rapid Recovery jouent ici un rôle clé.
Réhydratation évolutive :
La réhydratation évolutive de Clumio élimine complètement la perte de performances liée à la réhydratation des systèmes traditionnels de type « bricks and blocks ». La réhydratation est effectuée par Clumio à l’aide d’une infrastructure sans serveur (serverless) et tire parti de la capacité de calcul illimitée du cloud tout en exécutant des opérations d’E/S en parallèle sur tous les blocs concernés par une requête donnée. Résultat : le débit de restauration du service de sauvegarde Clumio surpasse celui d’un système de déduplication traditionnel installé dans le centre de données.
Suivi inversé des blocs modifiés :
Lorsque vous restaurez une machine virtuelle en production à partir d’une sauvegarde, vous essayez en substance de remonter le temps afin de revenir à un dernier état connu pour être correct. Le suivi inversé des blocs modifiés de Clumio vous aide à faire exactement cela sans avoir à passer par une restauration complète. Le service de sauvegarde Clumio récupère les blocs modifiés (régénérés via la réhydratation par extension horizontale décrite précédemment) et les applique directement dans le stockage de production afin de ramener la machine virtuelle à un instant antérieur. Résultat : le temps nécessaire pour restaurer une machine virtuelle à partir du service de sauvegarde Clumio et la rendre opérationnelle en production est plus court que celui requis pour une restauration à partir du stockage local !
Ces deux fonctionnalités de Recovery rapide proposées par Clumio éliminent TOUTES les limites de la Recovery instantanée proposée par les fournisseurs traditionnels.
Résumons les principaux avantages offerts aux clients par la solution « Rapid Recovery » de Clumio :
- Aucune intervention humaine n’est nécessaire : l’administrateur de sauvegarde ou l’administrateur de machine virtuelle n’a rien à faire pendant la sauvegarde ou la restauration pour bénéficier de la fonctionnalité « Rapid Recovery ». Clumio SaaS détecte automatiquement si le point de restauration demandé répond aux critères de restauration et lance automatiquement la procédure lors de la restauration.
- La Recovery RTO est plus performante que la Recovery instantanée : vous ne transférez que les données nécessaires à la restauration de la machine virtuelle, et la restauration est terminée. Le temps nécessaire à cette opération est inférieur à la durée totale requise pour effectuer une Recovery instantanée suivie d’un Storage vMotion.
- Protégez-vous contre la perte de données et les ransomwares : contrairement aux solutions de sauvegarde physiques sur site, nécessaires à une restauration instantanée, les sauvegardes Clumio sont physiquement isolées de votre centre de données de production. Clumio vous aide à vous protéger contre la perte de site et les vulnérabilités au niveau du site.
- Préparez-vous à migrer vers VMware Cloud on AWS : la fonctionnalité « Instant Recovery » ne fonctionne pas dans les environnements VMware Cloud on AWS, car elle repose sur le protocole NFS. Rapid Recovery vous accompagne lors de votre migration vers VMware Cloud on AWS.
Vous souhaitez essayer Rapid Recovery ? Contactez-nous.
