Haute disponibilité avec Microsoft SQL Server 2005
Date de publication : 18.5.2007
Par
ylarvor (Yann Larvor) (Blog)
Diverses solutions de haute disponibilité pour Microsoft SQL Server 2005
I. Introduction
II. Types de pannes et solution techniques
III. Capture instantanée de bases de données
IV. Mise en miroir de bases de données ( disponible en SP1)
V. Mise en oeuvre de l'envoi de journaux
VI. Gestion de la réplication.
VI-A. La réplication de capture instantanée
VI-B. La réplication transactionnelle s'appliquent
VI-C. La réplication de fusion
VI. Microsoft SQL Server et Microsoft Cluster Services
I. Introduction
Afin de vous permettre de choisir une technologie en fonction de vos besoins, je vous présente les différentes solutions technologiques disponible sur sql serveur 2005 pour répondre aux problème de haute disponibilité.
II. Types de pannes et solution techniques
- Panne d'unité de disque : les pannes de disques sont les plus fréquentes. On utilise un système RAID externe ou interne pour parer aux pannes de disques.
- Pannes de composant matériel : Les pannes de matériel, souvent dûes à la chaleur, peuvent se produire. La mise en miroir de bases de données est une bonne solution pour parer aux risques de pannes de matériel. La mise en cluster est une autre solution pour répondre aux problèmes de matériel.
- Pannes de composant logiciel : certains défaut n'apparaissent que rarement. De plus, l'ajout d'un nouveau logiciel peut entraîner une panne pour des raisons de compatibilité.
- Pannes externe : coupure de courant.
- Erreurs humaines : suppression d'une table ou d'un fichier de bases de données. La capture instantanée de bases de données est une solution hautement disponible pour répondre à des problèmes d'erreur humaines.
III. Capture instantanée de bases de données
Une capture instantanée de bases de données est une copie de base de données figé dans le temps. Toute transformation ultérieur que subit la base original ne se répercute pas sur la capture. Jusque là, rien d'extraordinaire, une simple restauration permet d'obtenir le même résultat.
L'avantage de la création d'une capture se situe au niveau de la disponibilité de la base de données. Contrairement à un backup et une restauration, qui nécessite une interruption du fonctionnement courant de la base de données, la capture est transparente aux utilisateurs.
Lorsque l'on crée la capture, aucune données n'est transporté dans la nouvelle base, qui pèse rien sur le disque dur. Un catalogue de pages modifiées gère les différences entre la base d'origine et la capture instantanée de bases de données. Ce catalogue est employé pendant l'exécution des requêtes pour déterminer si les données doivent être récupérées des pages de données écrites dans la capture instantanée de base de données ou depuis la base de données source. A chaque transformation d'une table sur la base source, une copie des données à l'instant t de la capture est copie sur la base de capture instantanée.
Il existe une opération de restauration spécifique qui permet de ramener une base de données source à l'état de la capture instantanée. c'est très utile pour réparer un dommage humain, suppression accidentelle d'une table par exemple.
IV. Mise en miroir de bases de données ( disponible en SP1)
Il s'agit d'une base de données de secours, qui permet un basculement à chaud, en cas d'indisponibilité de la base de données source. Dans la situation normal, toute transaction effectué sur la base de données principale se voit effectuée sur la base de données miroir, image parfaite de la base principale. En cas de défaillance de la base de données principale, détectée par un troisième serveur nommé serveur témoin, les requêtes basculent sur la base de données miroir. En situation normal, la base de données miroir, dans l'état "en récupération" est inaccessible à aucune connexion. Elle enregistre en "temps réel" les modifications de la base source. Toute transaction a valide sur la source se voit d'abord validé sur la cible : La mise en miroir de bases de données à une action sur les performances de la bases de données. Pour détecter une défaillance de la base principale, le serveur témoin utilise la commande ping.
V. Mise en oeuvre de l'envoi de journaux
L'envoi de journaux est un automatisme, basé sur le service sql agent, qui permet de copier le journal d'une principale sur une ou plusieurs base secondaire. Cette base secondaire, légèrement décalé dans le temps, peut être utilisé pour distribuer les requêtes de la base principale ou être utilisé comme base de secours.
VI. Gestion de la réplication.
La réplication est une technologie de copie et de distribution d'une base de données source vers une ou plusieurs bases de données cibles. Cela permet d'augmenter la disponibilité, de permettre une distribution des requêtes clients, ou de mettre à disposition une base de données à des clients distants en limitant les risques réseau par une décentralisation des données. La réplication est à la fois une technologie de haute disponibilité et de l'informatique distribué.
La réplication s'appliquent à un sous ensemble d'une base de données nommé publication.
La réplication est un ensemble de technologie qui comprend :
VI-A. La réplication de capture instantanée
Elle s'applique pour un volume de donnée faible. Il s'agit d'une opération planifiée de réécriture chez les abonnés de la publication. Comme il y a écrasement par l'ensemble de la publication, on utilisera cette réplication pour un sous ensemble réduit de la base de données. On peut comparer la réplication de capture instantannée à une opération de backup/restauration sur la seule publication.
VI-B. La réplication transactionnelle s'appliquent
Elle s'applique en cas de mise à jour fréquente des données de l'éditeur ( source ). La réplication transactionnel effectue une première mise à jour complète des données suivi d'opérations de transfert des seuls données modifiées entre la source et la cible. La réplication transactionnelle utilise pour ce faire le journal des transactions. La réplication transactionnelle est à sens unique, elle reporte les modifications de la source vers la cible. Pour mettre en place une remontée des modifications de la cible vers la source, il est nécessaire de mettre en place un processus indépendant de la réplication transactionnelle
VI-C. La réplication de fusion
Elle s'applique en cas de mise à jour des données sur l'éditeur et sur l'abonné. La réplication de fusion transfert les modifications de données dans les deux sens. Contrairement à la réplication transactionnelle qui utilise le journal de transaction pour publier les modifications, la réplication de fusion s'appuie sur des transformations profonde ( tables, triggers ) du schéma de bases de données pour mettre en place une réplication bidirectionnelle.
VI. Microsoft SQL Server et Microsoft Cluster Services
Microsoft Cluster Services ( MSCS ) est un service intégré à Windows 2000 Advanced server.
Il permet de créer un cluster de serveur.
Si l'un des serveur du cluster est indisponible, les ressources et applications passent sur un autre noeud du cluster.
MSCS assure la continuité de service grâce à un logiciel, à deux serveurs reliés par une liaison haut débit et des disques partagés scsi souvent montés en RAID.
La technologie de cluster permet de palier une panne de serveur mais n'est d'aucune utilité lorsque l'intégrité de la base de données est touchée par une erreur humaine, un problème matériel, ou un bug non répertorié.
En effet, le cluster partage les mêmes données.
L'élaboration d'un plan de reprise après incident est obligatoire dans ce cas.
Ce document est issu de http://www.developpez.com et reste la propriété exclusive de son auteur.
La copie, modification et/ou distribution par quelque moyen que ce soit est soumise à l'obtention préalable de l'autorisation de l'auteur.
