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.
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 des Solutions Cloud & Services Managés Simplifiés
Comment capitaliser sur son existant tout en bénéficiant, dès à présent, des promesses de flexibilité et de scalabilité du cloud ? Découvrez les bonnes pratiques pour répondre aux défis de simplification du Cloud dans ce nouveau TOP 5.
