> Data > Sauvegarde et restauration avec Split Mirror

Sauvegarde et restauration avec Split Mirror

Data - Par iTPro.fr - Publié le 24 juin 2010
email

par Ron Talmage - Mis en ligne le 10/06/2002
SQL Server 2000 peut sauvegarder de très grandes bases de données (VLDB, very large databases) rapidement et sollicitant très peu le serveur de base de données. Mais en restaurant à  partir de ces sauvegardes, on risque de réduire la disponibilité de la base de données.

En effet, l'un des principaux inconvénients de la restauration d'une VLDB est de la rendre indisponible pendant cette opération, c'est-à -dire pendant plusieurs heures. Pour résoudre le problème de l'indisponibilité de la base de données pendant une restauration, Microsoft s'est unie avec trois importants fournisseurs de SAN (Storage Area Network) - Compaq, EMC, et Hitachi Data Systems (HDS) - pour permettre la sauvegarde et la restauration en mode split-mirror. La restauration split-mirror peut se faire en quelques secondes, réduisant donc considérablement le temps d'indisponibilité de la base de données. Pour tous ceux qui veulent une grande disponibilité de la base de données et ne peuvent pas se permettre le temps d'interruption qu'impose la restauration, la technologie split-mirror offre une solution simple fondée sur le hardware.

Toutes les éditions de SQL Server 2000 possèdent la fonction splitmirror. Contrairement à  l'interface de sauvegarde et de restauration bien connue de SQL Server 2000, le procédé split-mirror a besoin de matériel spécialisé et de logiciel tierce partie. Pour effectuer une sauvegarde ou une restauration split-mirror, il faut stocker le contenu de la base de données sur des jeux de lecteurs en miroir, en configuration SAN. Les opérations de sauvegarde et de restauration se déroulent dans le sous-système de stockage sur disque, et donc concernent peu le serveur de base de données SQL Server 2000.

Les deux types de sauvegarde diffèrent également par leur mécanismes sous-jacents. Dans une sauvegarde SQL Server 2000 classique, SQL Server écrit des pages de données sur l'unité de sauvegarde, qui peut être un fichier disque ou un lecteur de bande. En revanche, dans une sauvegarde splitmirror, SQL Server laisse au logiciel et au matériel du fournisseur du sous-système disque la responsabilité du stockage des données.

La sauvegarde split-mirror préserve la disponibilité de la base de données car elle la sauvegarde en quelques secondes. On peut donc se permettre des sauvegardes plus fréquentes. Et la restauration d'une base de données à  partir d'une sauvegarde split-mirror est tout aussi rapide. La sauvegarde split-mirror permet pratiquement de se dispenser des ressources du serveur de base de données pour cette opération. De plus, on peut initialiser un serveur secondaire beaucoup plus rapidement qu'avec la méthode de sauvegarde et de restauration SQL Server standard.

Mais n'oubliez pas que la sauvegarde split-mirror demande du matériel et du logiciel spécialisés. Il faut que la base de données soit stockée sur un sous-système disque avec miroir - en principe RAID 10 sur un SAN. En outre, elle nécessite un utilitaire logiciel de gestion de volumes spécialisé pour communiquer avec SQL Server 2000. Il faut donc mettre en balance les avantages de la technologie split-mirror et le coût du logiciel et du matériel système disque qui l'accompagnent.

Sauvegarde et restauration avec Split Mirror

Pour comprendre le mode de fonctionnement
de la sauvegarde split-mirror,
commencez par considérer trois
volumes en miroir distincts illustrés figure
1. Supposez que vous les ayez
configurés comme RAID 10 dans un
SAN. La base de données originale a été créée sur deux volumes en miroir
pour la tolérance aux pannes.
Supposez encore que, depuis lors,
vous ayez ajouté un troisième jeu de
lecteurs en miroir, que vous avez synchronisé
avec les deux premiers miroirs,
et que vous gardez une copie
complète de toutes les données courantes
sur le troisième jeu également.
Tous les jeux en miroir se trouvent
dans le même sous-système disque,
donc les écritures disque de SQL
Server vont simultanément vers les
trois jeux de lecteurs. Avec tout cela en
place, vous pouvez instaurer une sauvegarde
split-mirror.

Pour faire une sauvegarde splitmirror,
on utilise le logiciel et le matériel
du fournisseur de SAN pour séparer
ou diviser le troisième jeu de
lecteurs en miroir des deux jeux de lecteurs
en miroir primaires de la base de
données. Cette division quasi-instantanée
crée une sauvegarde de la base de
données sur le jeu de lecteurs divisé à 
un moment précis. (Notons que la copie copie
des données se produit avant la division,
pendant le processus de synchronisation
initial.) Le jeu de lecteurs
qui est divisé est appelé BCV (Business
Continuance Volume) ou clone. Les
jeux en miroir qui restent derrière assurent
la tolérance aux pannes du système
disque pour le contenu de la base
de données.

La sauvegarde split-mirror s’effectue
à  l’aide d’un utilitaire logiciel fourni
par le fournisseur de stockage ou le
fournisseur de logiciel de sauvegarde
tierce partie. Au moment de la sauvegarde,
le logiciel utilitaire split-mirror
envoie une commande de sauvegarde
l’AP VDI (Virtual Device Interface) de
sauvegarde de SQL Server. Le logiciel
utilitaire de sauvegarde reçoit les métadonnées
du jeu de sauvegarde de SQL
Server et les stocke sur le jeu de lecteurs
cloné.

Pendant la division, un point de
contrôle survient et, bien que SQL
Server puisse encore accepter des écritures
vers la base de données, selon la mise en oeuvre de la technologie splitmirror
par le fournisseur, les écritures
sur les volumes disque physiques sont
suspendues. Si les écritures disque ont
été autorisées pendant la division, il se
peut qu’une portion seulement des
blocs de disques appartenant à  une
page de données de SQL Server soit
écrite sur le troisième jeu de lecteurs.
Ce résultat est appelé torn page (page
déchirée). La suspension des écritures
sur disque empêche le clone de capturer
potentiellement une page de données
déchirée pendant l’opération de
division. Pendant cette opération de division,
les lectures disque ne sont pas
affectées et donc SQL Server peut encore
y lire des données. L’opération de
division dure une poignée de secondes
– la durée exacte dépend du fournisseur
de stockage et de la configuration
matérielle du sous-système de stockage.

Aussitôt après la division, l’activité d’écriture de la base de données vers le
sous-système de stockage reprend,
mais uniquement en direction des
deux jeux de lecteurs en miroir,
comme l’illustre la figure 2. On peut
utiliser split-mirror pour faire une copie
rapide d’une grande base de données
sur un autre serveur. En utilisant
le BCV résultant comme jeu de sauvegarde,
vous pouvez le restaurer sur un
autre serveur de base de données sur
le SAN, ou bien archiver le BCV sur
bande.

Téléchargez cette ressource

Guide de cybersécurité en milieu sensible

Guide de cybersécurité en milieu sensible

Sur fond de vulnérabilités en tout genre, les établissements hospitaliers, pharmacies, laboratoires et autres structures de soin font face à des vagues incessantes de cyberattaques. L’objectif de ce livre blanc est de permettre aux responsables informatiques ainsi qu’à l’écosystème des sous-traitants et prestataires du secteur médical de se plonger dans un état de l’art de la cybersécurité des établissements de santé. Et de faire face à la menace.

Data - Par iTPro.fr - Publié le 24 juin 2010

A lire aussi sur le site

Revue Smart DSI

La Revue du Décideur IT