NetApp Tech OnTap
     

Protection intégrée des données NetApp :
Les bons choix en matière de protection des données

L'un des points forts de la solution de stockage NetApp® est l'intégration étroite de l'ensemble des fonctionnalités de protection de vos données stratégiques au matériel NetApp et au système Data ONTAP®. Bien souvent, seule une clé de licence est nécessaire. Vous n'avez pas à acheter de dispositif spécialisé ni à effectuer d'installation logicielle compliquée ; de plus, toutes nos solutions de protection des données sont dotées de fonctions intégrées de gestion des données.

L'approche traditionnelle de la protection des données génère complexité et coût

Figure 1) L'approche traditionnelle de la protection des données génère complexité et coût.

Les principes de base de la protection intégrée des données NetApp ont fait l'objet d'un article Tech OnTap précédent. Dans le présent article, je souhaite examiner certains aspects de nos technologies de réplication. La majorité des éléments importants de la protection des données NetApp, tels que SnapMirror® volume, SnapMirror qtree, SnapVault® et MetroCluster™, utilisent soit la mise en miroir, soit la réplication. Comprendre le fonctionnement de ces technologies, et ce qui les différencie, facilite le choix d'une stratégie de protection des données adaptée. Après avoir évoqué les différentes technologies, je vous proposerai des conseils pour choisir les options correspondant à vos exigences.

Options de réplication NetApp

Au fil des années, Tech OnTap a consacré de nombreux articles à SnapMirror, SnapVault et MetroCluster. Cependant, il me semble que certaines fonctionnalités majeures de ces produits, ainsi que certaines différences importantes entre ces derniers, n'ont jamais été approfondies dans un seul article. Nous allons tout d'abord nous attarder sur SnapMirror, puis le comparer aux deux autres produits. (Ne vous affolez pas si l'explication de SnapMirror vous paraît très longue. SnapVault et MetroCluster ne feront pas l'objet d'une description aussi détaillée.) Je vous proposerai également des tableaux comparatifs qui devraient répondre à toutes vos questions.

SnapMirror
Vous savez probablement tous que SnapMirror a été conçu principalement pour créer des miroirs sur des sites distants pour la reprise après incident. Ce que vous savez moins, c'est qu'il existe deux modes de fonctionnement de SnapMirror.

SnapMirror volume fonctionne au niveau du bloc physique. Il réplique le contenu d'un volume entier et tous les attributs du volume, du volume source (primaire) sur le volume cible (secondaire). Par conséquent, le système de stockage cible doit exécuter une version de Data ONTAP similaire ou ultérieure à celle du système source. Si la déduplication ou la compression des données NetApp (fonctionnalité ajoutée dans Data ONTAP 8.0.1) est exécutée sur le système primaire, le volume de destination hérite de ces économies, car le volume est identique et les économies se retrouvent également sur le réseau WAN.

SnapMirror qtree réplique les qtrees individuels. Les qtrees étant des sous-ensembles d'un volume, SnapMirror qtree fonctionne à un niveau logique. Un qtree ne doit pas être répliqué tel quel, car des informations importantes sur son suivi au niveau du volume manqueraient sur le système cible.

La réplication s'effectuant au niveau logique, elle diffère de celle de SnapMirror volume à bien des égards. Tout d'abord, SnapMirror qtree n'hérite pas des économies résultant de la déduplication. Cela paraît cohérent si on se replace dans le contexte de la source et de la cible. Sur la source, un qtree peut contenir un bloc dédupliqué qui est un simple pointeur vers un bloc situé hors du qtree. Ce bloc n'existera pas sur la cible et doit donc être répliqué avec le qtree et pas uniquement le pointeur. Dans ce cas de figure, SnapMirror qtree est moins efficace au niveau réseau et capacité que SnapMirror volume.

Par défaut, SnapMirror qtree réplique uniquement la dernière copie Snapshot créée, ce qui maintient un nombre asymétrique de copies Snapshot aux emplacements source et cible. (Par définition, SnapMirror volume a le même nombre de copies Snapshot sur la source et la cible.) SnapMirror qtree conserve uniquement la paire de copies Snapshot nécessaire aux mises à jour de réplication. En d'autres termes, SnapMirror qtree n'a pas les capacités de conservation des snapshots.

Les deux modes de SnapMirror commencent par une copie de base dans laquelle toutes les données du volume ou du qtree sont répliquées de la source vers la cible. Lorsque la configuration de base est terminée, la réplication se produit de façon régulière. SnapMirror volume prend en charge la réplication asynchrone, semi-synchrone et synchrone, alors que SnapMirror qtree prend uniquement en charge la réplication asynchrone.

En mode asynchrone, les copies Snapshot du volume ou du qtree sont régulièrement créées sur la source. Seuls les blocs ayant été modifiés ou nouvellement créés depuis le dernier cycle de réplication sont transférés vers la cible, ce qui rend cette méthode très efficace en termes de capacité de stockage et de bande passante réseau.

Le mode synchrone envoie des mises à jour de la source vers la cible au fur et à mesure, et non pas selon un planning prédéfini. Ainsi, les données enregistrées sur le système source sont protégées au niveau de la destination, même en cas de défaillance de l'ensemble du système source. Les transferts NVLOG et par point de cohérence aident à maintenir la cible à jour. Le transfert NVLOG permet aux données du journal, généralement mises en cache dans la mémoire NVRAM sur une solution de stockage NetApp, d'être synchronisées avec la cible. Le transfert par point de cohérence permet aux images du système de fichiers sur disque de continuer à être synchronisées.

Le mode semi-synchrone se différencie du mode synchrone par deux éléments. Les écritures sur la source n'ont pas à attendre la reconnaissance de la cible avant d'être validées et reconnues, et le transfert NVLOG n'est pas utilisé. Ces deux éléments contribuent à accélérer la réponse des applications avec seulement un très petit argument en termes d'objectif de point de restauration (RPO).

Pour en savoir plus sur ces modes, vous pouvez consulter les documents TR-3446: SnapMirror Async Overview and Best Practices Guide (Guide des meilleures pratiques et présentation du mode asynchrone SnapMirror) et TR-3326: SnapMirror Sync and SnapMirror Semi-Sync Overview and Design Considerations (Présentation et réflexion sur la conception des modes synchrone et semi-synchrone SnapMirror).

SnapMirror

Figure 2) SnapMirror.

Pour terminer, il est également très important de savoir que SnapMirror volume et SnapMirror qtree fournissent des cibles qui sont inscriptibles. Ainsi, en cas de défaillance des systèmes source ou primaires, vous pouvez faire basculer les opérations et passer à l'écriture sur la cible. Lorsque la panne est résolue, vous pouvez effectuer une resynchronisation de restauration qui permet de copier les modifications delta sur la source et de reprendre un fonctionnement normal. Cette fonctionnalité représente un avantage important par rapport à SnapVault.

SnapVault
SnapVault est conçu principalement pour la sauvegarde disque à disque. Comme SnapMirror en mode asynchrone, SnapVault tire parti de la technologie NetApp Snapshot pour sauvegarder et restaurer des systèmes au niveau du bloc. De plus, SnapVault identifie et copie uniquement les blocs modifiés sur un système (et non les fichiers modifiés) vers un système de stockage secondaire. Ceci permet non seulement d'accroître les performances en limitant la quantité de données transférées lors des opérations de sauvegarde et de restauration, mais aussi de limiter la capacité requise pour stocker les sauvegardes, dont la fréquence peut être augmentée.

Sur le plan de son fonctionnement de base, SnapVault est assez semblable à SnapMirror qtree : il effectue des réplications sur une base logique au niveau du qtree. Comme SnapMirror qtree, il ne s'agit donc pas d'une réplique exacte du volume source, et il hérite de la déduplication ou de l'état de compression des données à partir de la source. (Vous pouvez procéder à la déduplication et/ou à la compression des données sur la cible comme avec n'importe quel autre volume NetApp.)

De plus, vous ne pouvez pas rendre un volume SnapVault inscriptible (pour récupération immédiate) comme avec SnapMirror ; les durées de restauration peuvent donc s'avérer bien plus importantes avec SnapVault qu'avec SnapMirror si vous transférez beaucoup de données sur un réseau. Si vous possédez SnapMirror, vous pouvez rendre un volume SnapVault inscriptible. Mais n'oubliez pas que SnapVault est unidirectionnel : il n'est pas doté de la fonction de resynchronisation de restauration qui permet de mettre à jour la source.

SnapVault. Open Systems SnapVault (non développé dans ce document) permet d'intégrer du stockage tiers à la structure de sauvegarde.

Figure 3) SnapVault. Open Systems SnapVault (non développé dans ce document) permet d'intégrer du stockage tiers à la structure de sauvegarde.

Les armes clés de l'arsenal SnapVault, qui découlent de son fonctionnement au niveau logique, sont la conservation et la fusion des snapshots. Vous pouvez conserver jusqu'à 255 copies Snapshot par volume SnapVault et configurer l'expiration de ces copies en fonction d'un planning. Grâce à la fusion, vous pouvez exécuter plusieurs processus SnapVault à partir de plusieurs sources vers une cible unique, puis créer une seule copie Snapshot, contenant les différentes sources, sur la cible. Vous réduisez ainsi le nombre de copies Snapshot enregistrées. Si vous procédez à une déduplication sur le système cible, vous pouvez ensuite dédupliquer les blocs identiques sur tous les qtrees de la sauvegarde.

Pour en savoir plus sur SnapVault, consultez le guide des meilleures pratiques SnapVault.

Tableau 1) Comparaison de SnapMirror et SnapVault.

Fonctionnalité

SnapMirror volume

SnapMirror qtree

SnapVault

Type de réplication

Physique

Logique

Logique

Réseau de réplication

FC ou IP

FC ou IP

IP uniquement

Chemins multiples pour la réplication

Oui

Oui

Non

Sensible à la version de Data ONTAP

Oui

Non

Non

Compression réseau

Oui

Oui avec approbation

Non

RPO (Quel volume de données puis-je me permettre de perdre ?)

1 minute1

1 minute2

1 heure

Capacité de reprise après incident

Oui

Oui

Oui, en combinaison avec SnapMirror

Conservation des snapshots en vue d'une sauvegarde

Non

Possible mais fastidieux

Oui

Fusion des snapshots

N/A

Non

Oui

Resynchronisation de restauration

Oui

Oui

Non

Déduplication

Le volume de destination hérite des économies de déduplication et de bande passante

Le volume de destination n'hérite pas des économies de déduplication

SnapVault et la déduplication sont intégrés ; le volume de destination n'hérite pas des économies de déduplication

 

1Même si les mises à jour de 1 minute sont possibles, NetApp ne les recommande pas. Utilisez le mode semi-synchrone SnapMirror pour un objectif de point de restauration faible (<3 minutes).

2Même si les mises à jour de 1 minute sont possibles, NetApp ne les recommande pas. Le mode semi-synchrone SnapMirror ne peut être utilisé sur les qtrees autonomes.

MetroCluster
La solution NetApp pour la disponibilité continue des données est MetroCluster. Cette solution est un parent éloigné de SnapMirror et de SnapVault car elle fonctionne de façon très différente. Cependant, son concept est très simple à comprendre. Comme son nom l'indique, MetroCluster offre une mise en cluster étendue. À partir d'une paire haute disponibilité NetApp standard, vous pouvez séparer les nœuds jusqu'à 100 km. MetroCluster utilise une configuration entièrement clonée active/active qui conserve deux copies complètes de toutes les données en miroir, une de chaque côté du cluster. Ces copies sont appelées « plexes » et sont continuellement mises à jour de manière synchrone à chaque fois que Data ONTAP enregistre des données sur le disque.

Chaque contrôleur est doté de volumes de stockage (plexes) sur les deux nœuds. Ceci permet non seulement la déduplication sur les deux nœuds, mais aussi la séparation des opérations de lecture sur les deux ensembles de disques, ce qui augmente les performances de lecture jusqu'à 80 %. Davantage d'informations sur MetroCluster sont disponibles dans une étude de cas Tech OnTap récente ainsi que dans une vidéo très complète.

Tableau 2) Comparaison de MetroCluster et SnapMirror synchrone.

 

SnapMirror synchrone

MetroCluster

Réseau de réplication

IP ou FC

FC

Limite sur les transferts simultanés

Oui

Aucune limite

Distance maximale

200 km
(>200 km pour mode semi-synchrone)

100 km

Réplication entre paires haute disponibilité

Oui

Non

Reprise après incident

CLI

CLI (une seule commande), System Center

Utilisation de réplique

Oui

 

Prise en charge de la déduplication primaire

 

Oui



Quelle option choisir ?

Les tableaux 1 et 2 de la section précédente vous permettent de choisir l'option de réplication la mieux adaptée à vos besoins spécifiques. Certaines considérations sur les technologies abordées précédemment sont également à prendre en compte. En premier lieu, vous devez déterminer si vos besoins concernent la sauvegarde ou la reprise après incident.

Sauvegarde
Si vos besoins s'orientent vers la sauvegarde, il faut savoir que la plupart des utilisateurs sont satisfaits d'un programme régulier de snapshots sur le système de stockage primaire (en général toutes les heures), éventuellement combiné à une copie SnapVault nocturne sur le système de stockage secondaire (local ou distant). La plupart des restaurations de fichiers peuvent être effectuées à partir de copies Snapshot sur le système de stockage primaire ; SnapVault offre la possibilité de revenir davantage en arrière et de procéder à des restaurations conséquentes en cas de défaillance plus grave.

Consultez l'encadré pour accéder à la vidéo relative à NetApp Syncsort Integrated Backup, qui combine les avantages de la gestion de données Syncsort avec la réplication NetApp pour toute une gamme d'environnements d'applications majeurs.

Reprise après incident
Pour la protection à l'échelle du site et la continuité de l'activité, votre choix se portera soit sur MetroCluster, soit sur SnapMirror. L'alternative la plus répandue en termes de nombre de déploiements est SnapMirror volume avec réplication asynchrone. Les utilisateurs ont adopté cette solution car elle est simple et permet des économies substantielles grâce à une utilisation efficace des ressources de stockage et de réseau. NetApp a investi des efforts de développement importants dans SnapMirror et a mis au point des fonctionnalités telles que l'accélération de bande passante, la compression réseau et l'intégration à la suite de solutions d'intégration d'applications SnapManager.

SnapMirror qtree et SnapMirror volume peuvent atteindre des objectifs de durée de restauration (RTO) de quelques secondes à quelques minutes, et des objectifs de point de restauration (RPO) aussi faibles qu'une minute (ce qui implique la réplication de données toutes les minutes). NetApp ne recommande généralement pas la réplication asynchrone toutes les minutes. Pour des durées de restauration d'une à trois minutes, nous recommandons SnapMirror en mode semi-synchrone. (Si vous n'êtes pas familiarisé avec les termes RPO et RTO, consultez l'encadré.)

Si vous avez besoin d'un objectif RPO plus agressif que ne le propose le mode asynchrone SnapMirror, vous avez le choix entre MetroCluster et SnapMirror synchrone. N'oubliez pas que les solutions synchrones demandent en général beaucoup plus de bande passante et un équipement réseau spécialisé pour l'implémentation, ce qui les rend plus onéreuses.

MetroCluster est la solution adaptée aux distances allant jusqu'à 100 km, car elle offre une disponibilité continue des données ainsi qu'une reprise après incident et une restauration automatiques. Le mode synchrone SnapMirror a une portée atteignant 200 km, et le mode semi-synchrone SnapMirror peut aller encore plus loin si votre exigence est le plus petit objectif RPO possible sur une distance plus grande.

Cas spécifiques
Les différentes approches évoquées jusque-là devraient couvrir la grande majorité des situations ; cependant, on trouve toujours des cas spécifiques. Certaines personnes utilisent SnapMirror pour la sauvegarde, en général pour sa capacité à rendre inscriptible un volume de sauvegarde en cas de besoin. D'autres utilisent SnapVault pour la reprise après incident, car cette solution leur permet d'effectuer une reprise au point souhaité. SnapVault seul ne peut pas rendre inscriptibles les volumes SnapVault, mais ceci est possible en utilisant à la fois SnapVault et SnapMirror (comme indiqué précédemment).

Mise en route

Bien entendu, de nombreux utilisateurs NetApp combinent les différentes solutions évoquées dans cet article pour répondre à leurs besoins de sauvegarde et de reprise après incident. Parmi les scénarios les plus courants, on peut citer SnapMirror pour les volumes stratégiques vers un site distant avec, à des fins de sauvegarde, un programme SnapVault régulier sur le site distant. Certains sites déploient même une combinaison de MetroCluster, SnapMirror et SnapVault pour leurs besoins de protection des données.

Figure 4) Gamme de solutions de protection intégrée des données de NetApp (inclut des fonctionnalités non abordées dans le présent article).

Vous trouverez des informations supplémentaires sur les configurations avancées, les sujets évoqués dans cet article, ainsi que sur d'autres thèmes que je n'ai pas eu le temps de développer (par exemple la planification de la protection des données) dans NetApp Data Protection Handbook (Manuel NetApp sur la protection des données). Vous pouvez également consulter les autres ressources mentionnées dans cet article. NetApp a développé une grande expertise avec de nombreuses solutions de protection des données. N'hésitez pas à vous adresser à la communauté NetApp en ligne ou à poser des questions à votre équipe NetApp afin de prendre les bonnes décisions.

Communauté NetApp
 Vos opinions sur la protection intégrée des données

Posez vos questions, échangez des idées et partagez vos points de vue directement en ligne via les communautés NetApp.

Jason Blosil

Srinath Alapati
Ingénieur marketing et technique
NetApp

Srinath a rejoint NetApp en 2004 et est membre du groupe sur la protection des données depuis plus de quatre ans. Il a une expérience de plus de 10 ans dans l'informatique, plus particulièrement la gestion des serveurs et des infrastructures de stockage. Srinath est auteur ou co-auteur de nombreux rapports techniques sur SnapMirror, MetroCluster, VMware® et Exchange, et intervient régulièrement lors de conférences techniques. Il fait également partie de l'équipe chargée de l'implémentation de la reprise après incident NetApp IT.

 
Explorer
 
TRUSTe
Nous contacter   |   Choisir un partenaire   |   Commentaires   |   Offres d'emploi  |   Abonnements   |   Déclaration de confidentialité   |   © 2011 NetApp