NetApp Tech OnTap
     

Table ronde : Reprise sur incident pour les applications Microsoft avec VMware SRM et NetApp

L'édition de février 2010 de Tech OnTap contenait un article sur la virtualisation des applications Microsoft via les technologies VMware®, NetApp® et Cisco. Suite à la publication de cet article, Tech OnTap, Wen Yu de VMware et Larry Touchette de NetApp se sont réunis pour discuter des détails de la reprise sur incident pour les applications Microsoft® et déterminer pourquoi le taux d'adoption de cette dernière est plus élevé dans les environnements VMware/NetApp.

Tech OnTap : les utilisateurs hésitent encore massivement à utiliser la reprise sur incident en ligne dans les environnements applicatifs Microsoft. À votre avis, quels sont les facteurs qui contribuent à ce phénomène ?


Wen Yu (VMware) : Chez VMware, nous pensons qu'il existe trois raisons principales expliquant ce phénomène. Tout d'abord, et ce qui est probablement le facteur déterminant, le prix de la reprise sur incident qui est prohibitif. Il ne suffit pas de disposer d'une deuxième installation, un certain nombre de serveurs supplémentaires, un équipement réseau et deux fois plus de stockage sont également nécessaires. Ces coûts peuvent être prohibitifs indépendamment du type de serveurs (physiques ou virtuels) avec lesquels vous travaillez.

Ensuite, l'exécution d'une reprise sur incident implique souvent un haut degré de complexité, plus particulièrement dans les environnements de serveurs physiques et d'autant plus lorsque vous tentez d'implémenter la reprise sur incident au niveau de plusieurs applications. Vous pouvez alors vous trouver face à une combinaison complexe de produits et technologies censés permettre l'exécution de cette tâche. De nombreux produits existants requièrent également une configuration pratiquement identique des deux côtés, ce qui gonfle encore le prix d'une telle intervention.

Enfin, la bande passante réseau requise pour atteindre un objectif RPO adéquat peut représenter un obstacle pour beaucoup. De nombreux parcs informatiques Windows® ne disposent pas de la bande passante nécessaire pour les opérations de réplication et les responsables peuvent hésiter à investir pour y remédier.

La solution combinée de NetApp, Cisco et VMware résout bon nombre de ces problèmes.

Larry Touchette (NetApp) : Pour rebondir sur ce que vient d'affirmer Wen, NetApp et VMware diminuent considérablement le coût et la complexité de la reprise sur incident et ce afin que vous puissiez déployer une solution couvrant un nombre bien supérieur d'applications, voire votre environnement VMware tout entier si vous le souhaitez. Certains clients communs ont pu couvrir voire totalement financer le stockage pour un environnement de reprise sur incident grâce aux économies générées par l'utilisation de la déduplication NetApp sur le stockage VMware primaire. Toute personne suivant régulièrement les actualités Tech OnTap connaît les avantages de la déduplication NetApp lorsqu'elle est utilisée avec VMware. [Cet article constitue un bon point de départ pour en savoir plus sur la reprise sur incident et la déduplication VMware. - Éditeur TOT]

En ce qui concerne les économies de bande passante, la technologie NetApp SnapMirror®, lorsqu'elle est utilisée en combinaison avec la déduplication NetApp, réplique seulement des blocs uniques, ce qui est très efficace en termes de bande passante. NetApp a récemment ajouté la fonctionnalité de compression SnapMirror à Data ONTAP® pour l'accélération WAN, ce qui améliore encore plus le travail dans les environnements dotés d'une bande passante limitée, diminuant ainsi son utilisation de 70 % en fonction du taux de compression de vos données. [La compression SnapMirror a été abordée en détail dans un article Tech OnTap récent. - Éditeur TOT]

Le niveau d'adoption de la reprise sur incident dans les environnements VMware/NetApp communs est plutôt élevé. Je pense que ces facteurs sont responsables de ce niveau d'adoption plus élevé.

TOT : Pourquoi choisir d'utiliser VMware Site Recovery Manager (SRM) dans une configuration de reprise sur incident VMware/NetApp ?


Wen : La partie la plus critique de la reprise sur incident pour les serveurs d'applications virtualisés est l'exécution des étapes nécessaires à la connexion, l'inventaire, la reconfiguration et l'alimentation des ordinateurs virtuels au niveau de votre site de reprise sur incident. L'exécution manuelle de ces tâches peut être compliquée et sujette à erreurs, particulièrement lorsque vous possédez des dépendances requérant le démarrage d'un ordinateur virtuel avant un autre. Des scripts peuvent être écrits pour tenter d'automatiser les processus de reprise sur incident et de résoudre ces problèmes, mais leur implémentation est souvent coûteuse et leur maintenance difficile.

Site Recovery Manager simplifie la gestion de l'intégralité du processus de reprise sur incident, notamment la découverte et la configuration, le basculement et les tests de reprise sur incident. Le plan de reprise que vous créez durant la phase de configuration de SRM vous permet de préconfigurer votre plan dans son intégralité. Les fonctionnalités de découverte intégrées et l'intégration étroite avec vCenter accélèrent le processus.

Une fois le plan créé, il peut être exécuté automatiquement, avec une intervention minimale de la part de l'utilisateur. SRM permet d'exécuter toutes les étapes nécessaires et de démarrer tous les ordinateurs virtuels dans le bon ordre. Par exemple, les ordinateurs virtuels prenant en charge les infrastructures telles qu'Active Directory® (AD) et les serveurs DNS peuvent être démarrés en premier, suivis des serveurs de bases de données, des serveurs d'applications puis des serveurs Web.

La possibilité d'effectuer des tests constitue un autre avantage important. Avec la plupart des solutions de reprise sur incident, il est pratiquement impossible de réaliser un test sans interrompre les opérations de production normales et la réplication continue. SRM et NetApp facilitent les tests de reprise sur incident et les rendent plus efficaces. Par exemple, vous devez créer un réseau de test isolé (afin de ne pas avoir deux instances actives de chaque ordinateur virtuel sur votre réseau d'entreprise par inadvertance). SRM automatise le processus afin que vos tests restent isolés.

Larry : En utilisant la technologie NetApp FlexClone® avec les tests de reprise sur incident SRM, vous pouvez afficher votre site de reprise sur incident et y exécuter des tests sans utiliser une quantité importante de stockage supplémentaire et sans interrompre la réplication continue entre les sites ou les opérations sur le site principal. Voilà un moyen facile d'exécuter des tests de validation de reprise sur incident sans que cela ait une quelconque incidence sur le site de production ou les contrats de niveau de service approuvés.

Certaines solutions de réplication requièrent deux fois plus de capacité pour la création de répliques de stockage au niveau du site de reprise sur incident, et ce afin que la réplication puisse continuer pendant l'exécution du test. La durée de l'opération est excessive et cela réduit le temps d'utilisation de l'environnement de test ou la fréquence à laquelle les tests peuvent être exécutés. Grâce à FlexClone, vous pouvez réduire de manière significative la quantité de stockage nécessaire et accélérer le processus.

 

Exigences du stockage incrémentiel pour les tests de reprise sur incident avec FlexClone.

Figure 1) Exigences du stockage incrémentiel pour les tests de reprise sur incident avec FlexClone.

TOT : Quels sont les principaux points à prendre en compte lorsque l'on souhaite déployer une solution de reprise sur incident avec VMware SRM et le stockage NetApp ?


Wen : Du point de vue de SRM, un certain nombre de facteurs est à prendre en compte. Tout d'abord, vous devez disposer d'un serveur VMware vCenter sur chaque site, ainsi que d'un serveur Microsoft SQL Server pour stocker la base de données SRM et de serveurs exécutant les versions prises en charge d'ESX.

Le site principal et le site de reprise sur incident doivent être connectés via un réseau IP fiable, et le site de reprise doit disposer d'un accès aux mêmes réseaux publics et privés que le site principal. Enfin, le site de reprise sur incident doit disposer de serveurs Active Directory et DNS à jour.

En ce qui concerne la réplication en elle-même entre les sites, SRM exploite le stockage, dans ce cas précis, NetApp, pour effectuer cette opération. Les clients utilisant des applications de niveau 1 peuvent atteindre un objectif RPO de zéro en configurant SnapMirror pour qu'il effectue une réplication synchronisée. En plus de la réplication, le maintien de la cohérence au niveau du système d'exploitation et des applications est primordial.

Larry : NetApp utilise un certain nombre de composants permettant d'obtenir une réplication cohérente pour les ordinateurs virtuels eux-mêmes et pour les applications Microsoft (Exchange, SQL Server et SharePoint Server). Le point le plus important à prendre en compte pour les ordinateurs virtuels et les applications est le suivant : il ne suffit pas de répliquer les données régulièrement ; les répliques doivent se trouver dans un état cohérent avec les applications, à partir duquel chaque composant peut être redémarré. Nous avons décrit l'approche globale en détail dans un rapport technique récent. Wen Yu a révisé ce rapport pour s'assurer que les informations relatives à VMware étaient exactes.

Les ordinateurs virtuels résident dans des datastores partagés, de type VMFS (LUN FC ou iSCSI) ou NFS. NetApp SnapManager pour infrastructure virtuelle propose des copies Snapshot et une réplication cohérentes pour les données d'ordinateur virtuel.

L'un des éléments de conception clés est la séparation des données d'applications des datastores d'ordinateurs virtuels via leur stockage dans des LUN RDM en mode physique (iSCSI ou FC). Cela nous permet d'utiliser la suite de produits NetApp SnapManager pour créer des points de restauration cohérents pour chaque application. Nous pouvons également mettre en place différents calendriers de réplication pour chaque application afin de concilier plusieurs RPO en créant des quantités variées de points de restauration.

 

Architecture de réplication.

Figure 2) Architecture de réplication.

TOT : Nous avons énormément travaillé pour que la création de plusieurs points de restauration à partir desquels redémarrer les applications soit possible. Pouvez-vous en dire plus à nos lecteurs à ce sujet ?


Larry : Les produits NetApp SnapManager pour SQL Server, Exchange et SharePoint augmentent la flexibilité en permettant la création et la vérification de points de restauration multiples répliqués sur le site de reprise sur incident. Les applications SnapManager permettent de créer des sauvegardes complètes, dont la cohérence avec les applications est vérifiée, ainsi que des sauvegardes plus fréquentes comprenant uniquement les fichiers journaux incrémentiels des changements survenus entre deux sauvegardes complètes. Ces sauvegardes incrémentielles sont appelées sauvegardes de points de restauration fréquents (FRP, Frequent Recovery Points). L'ajustement du temps entre les sauvegardes FRP offre la flexibilité nécessaire à la définition de l'objectif RPO souhaité pour chaque application, séparément.

Si des problèmes sont détectés au niveau des données d'applications récupérées sur le site de reprise sur incident, les applications individuelles peuvent être rétablies à n'importe quel point de restauration précédemment créé. SnapManager peut effectuer une restauration par progression de tous les fichiers journaux de bases de données non validés si les applications sont ramenées à un point de restauration précédent afin d'empêcher la perte de toutes les nouvelles données écrites sur le site de reprise sur incident après basculement.

SRM vous permet d'insérer des commandes personnalisées dans votre plan de reprise sur incident. Nous utilisons cette fonctionnalité pour exécuter une commande dans le plan de reprise sur incident qui configure SnapDrive® pour qu'il active les ordinateurs virtuels en cours d'exécution sur le site de reprise sur incident, et ce afin d'afficher l'historique complet des sauvegardes répliquées à partir du site de production. Pour les utilisateurs disposant d'un accès au site NetApp NOW (NetApp on the Web), ce processus est décrit plus en détail dans l'article KB56952.

TOT : L'un de vous peut-il expliquer l'importance d'Active Directory dans un environnement SRM ?


Wen : Les applications Microsoft sont extrêmement dépendantes d'Active Directory et DNS pour fonctionner correctement. Il est donc crucial que leur configuration soit correcte au niveau du site de reprise sur incident. Lors de l'exécution d'un test de reprise sur incident, vous devez également vous assurer que le serveur Active Directory est configuré correctement et qu'il est à jour sur le réseau de test isolé. Lorsque vous basculez en sens inverse vers le site principal, vous devez à nouveau vous assurer que les serveurs Active Directory/DNS sont gérés de manière appropriée. Dans le cas contraire, vous pourriez faire l'objet de problèmes de restauration du nombre de séquences de mise à jour (USN, Update Sequence Number) et de corruption de la base de données Active Directory. Ces problèmes sont décrits plus en détail dans l'article de la Base de connaissances Microsoft 875495.

Le moyen le plus simple de s'assurer de la configuration correcte d'Active Directory au niveau du site de reprise sur incident est de garder au moins un serveur Active Directory du site de reprise synchronisé avec le site principal.

Vous devez cloner ce serveur Active Directory juste avant l'exécution du test de reprise sur incident. Une fois le clonage terminé, mais avant de mettre l'ordinateur virtuel en marche, assurez-vous que le serveur Active Directory cloné est connecté uniquement au réseau de test de reprise sur incident. Après la mise en marche de l'ordinateur virtuel Active Directory dans le réseau de test, cinq rôles FSMO (Flexible Single Master Operation) de la forêt Active Directory doivent être pris selon la procédure décrite dans l'article de la Base de connaissances Microsoft 255504.

Ce processus de clonage n'est pas nécessaire lorsqu'un véritable basculement a lieu, mais la prise des rôles FSMO est toujours requise et doit être effectuée manuellement. Après la reprise sur incident (quel qu'il soit) et avant la restauration, vous devez rétablir les services Active Directory sur le site d'origine. Cette opération peut être effectuée en récupérant les serveurs Active Directory sur ce site et en les forçant à se resynchroniser avec les serveurs Active Directory plus récents sur le site de reprise sur incident ou en en établissant de nouveaux.

Toutes ces actions sont décrites en détail dans le guide NetApp TR-3822, mentionné précédemment par Larry Touchette.

TOT : Pour conclure, pouvez-vous tous les deux nous parler brièvement des méthodes disponibles pour la restauration vers le site d'origine ?


Wen : Comme je viens de le suggérer, la première étape à suivre dès que votre site d'origine est opérationnel est la mise en route d'Active Directory. SRM ne permet pas encore d'inversion ni de restauration entièrement automatisée, mais nous vous recommandons tout de même d'utiliser SRM pour la restauration en reconfigurant le logiciel pour qu'il effectue un basculement en sens inverse.

Larry : Afin d'effectuer ce basculement en sens inverse, vous devez synchroniser les données entre le site de reprise sur incident et le site d'origine. Les relations SnapMirror sont faciles à inverser et resynchroniser. Le processus de resynchronisation dépend de la défaillance rencontrée. Si le stockage initial n'a pas été détruit lors de l'incident, SnapMirror doit seulement répliquer les modifications différentielles survenues pendant que le site d'origine était hors ligne. Sinon, une resynchronisation complète est requise. Évidemment, la déduplication NetApp et la compression SnapMirror peuvent réduire l'impact des réseaux WAN dans les deux cas. La déduplication réduit la quantité totale de données dans votre environnement VMware en éliminant la duplication résultant de la présence de nombreuses copies des mêmes systèmes d'exploitation invités, et la compression permet de s'assurer que toutes les données transmises par réseau WAN utilisent le moins de bande passante possible.

Nous espérons que les informations récapitulatives de la table ronde ont été utiles et nous aimerions connaître votre avis sur cet article. Pour plus de détails sur les thèmes abordés, consultez le guide TR-3822.

Centre communautaire
 Vous avez des remarques à faire à propos de la reprise sur incident avec SRM et NetApp ?

Posez vos questions, échangez des idées et partagez vos impressions
en ligne via les communautés NetApp.


Wen Yu

Wen Yu
Responsable technique Alliance
VMware

Wen Yu travaille avec VMware depuis plus de cinq ans et assure le soutien et la promotion des produits de virtualisation pour une disponibilité et une reprise sur incident continues ainsi que des postes de travail accessibles en continu. Il est actuellement membre de l'équipe Infrastructure Alliance Technology.

Larry Touchette

Larry Touchette
Ingénieur marketing et technique
NetApp

Larry Touchette travaille avec NetApp depuis neuf ans, soutenant, implémentant et concevant les solutions de stockage et de reprise sur incident NetApp. Il fait actuellement partie de l'équipe NetApp Server Virtualization Technical Marketing.

 
Explorer