La haute disponibilité▲
La notion de haute disponibilité doit être établie par rapport à l'exigence de permanence de la solution informatique.
La question fondamentale est :
quelles sont les données que l'on accepte de perdre en fonction du contexte de survenance d'un incident ?
La question sous-jacente est :
Quel coût financier de la solution de continuité doit être envisagé en regard de la perte de production ?
Elle pose directement le problème d'un retour sur investissement, même si l'investissement a des chances de ne jamais être consommé (absence d'incident). C'est donc a un calcul de probabilité calqué sur les modèles des compagnies d'assurance qu'il faut se prêter.
La perte d'exploitation▲
La mesure de la perte se chiffre généralement en termes de durée d'exploitation perdue. À une durée d'exploitation perdue peut correspondre une durée de remise en état beaucoup plus longue afin de rétablir le système comme à l'origine.
Par exemple, à une perte d'exploitation des trois dernières minutes de production peut correspondre une durée de remise en état d'une heure.
Contexte de l'incident▲
Il convient de prendre en compte la force et la gravité de l'incident comme critère à intégrer dans le processus de haute disponibilité. Il n'est pas toujours possible de prendre en compte tous les incidents sans tenir compte du coût ou de la logistique globale de mise en œuvre de la solution de dépannage.
Par exemple en cas d'incendie on doit considérer le redémarrage « global » du système : nouveaux locaux, information du personnel… autant de préalables qui finalement font du coût de la solution de haute disponibilité, un élément presque anecdotique.
On comprend donc qu'assurer une haute disponibilité avec une perte nulle de la production et pour tous les types d'incidents relève d'une gageure financière pas toujours en adéquation avec les budgets informatiques.
Ce document présente donc différentes approches pour ce faire en détaillant les avantages et les inconvénients de chacune des méthodes. Il ne s'occupe pas du volet « sécurité » qui relève du domaine des administrateurs de systèmes informatiques et des stratégies de l'entreprise.
Avant tout se prémunir de la défaillance▲
Se prémunir de la défaillance consiste à utiliser un serveur configuré de telle façon que les principaux incidents n'aient que peu ou pas d'influence sur la continuité de la production.
Dans ce cadre, il faut considérer au niveau matériel, un serveur configuré de la sorte :
- une alimentation redondante ;
- mémoire RAM autocorrective ;
- disque RAID hot plug avec trois agrégats (un RAID niveau 5 et deux RAID niveau 1) ;
- onduleur online.
On veillera de plus à stocker un disque hot plug en « spare » de façon à pallier immédiatement la panne.
En outre il faut entretenir un serveur de secours capable de reprendre les mêmes disques hot plug que le serveur principal. Le serveur de secours étant configuré à l'identique au niveau hard et soft (OS + SQL Server).
Les fichiers seront répartis comme suit afin de réparer les défaillances :
- RAID 5 : fichiers contenant les données des bases (DATA) ;
- RAID 1 (grappe 2) : fichiers contenant les journaux des bases (LOG) ;
- RAID 1 (grappe 2) : autres fichiers (OS, exe, mémoire virtuelle…).
|
Pannes possibles |
Remède |
|---|---|
|
Coupure réseau électrique |
Onduleur |
|
Défaut de RAM |
Auto correction soft |
|
Défaut du sous-système de contrôle disque (RAID, SCSI, SATA…) |
Enficher * les disques DATA et LOG du serveur en panne dans le serveur de secours. Copier les fichiers nécessaires au redémarrage. Lancer les procédures adéquates pour reprendre la main sur SQL Server et la base de production. |
|
Défaillance d'un disque |
Remplacement à chaud du disque |
|
Défaillance d'un fichier |
Si fichier OS ou exe : enficher * les disques DATA et LOG du serveur en panne dans le serveur de secours. Copier les fichiers nécessaires au redémarrage. Lancer les procédures adéquates pour reprendre la main sur SQL Server et la base de production. |
|
Défaillance processeur |
Enficher * les disques DATA et LOG du serveur en panne dans le serveur de secours. Copier les fichiers nécessaires au redémarrage. Lancer les procédures adéquates pour reprendre la main sur SQL Server et la base de production. |
* cette pratique n'est pas garantie par Microsoft. En effet, les fichiers des données comme ceux des journaux peuvent ne pas pouvoir être repris tels quels parce qu'ils sont ouverts à l'usage exclusif de MS SQL Server tant que le serveur SQL tourne (en principe 24h/24).
Bien entendu il est toujours possible de repartir d'une sauvegarde, mais la perte de production dans ce cas est liée au delta entre deux sauvegardes.
NOTA : MS SQL Server est capable de sauvegardes très légères (différentielles, JT) que l'on peut programmer à fréquences plus ou moins élevées (jusqu'au 1/4 d'heure par exemple).
La solution de clusterisation▲
C'est la seule solution actuellement garantie par MS en termes de reprise d'exploitation sans perte de données.
Pour cela il faut :
- deux serveurs identiques, choisis dans une liste des matériels approuvés par Microsoft ;
- une baie de disques partagés, (SAN) choisie dans une liste des matériels approuvés par Microsoft ;
- la solution MS Windows 2003 Server Clustering.
Cette solution est couteuse en deux endroits :
- le matériel approuvé par MS est très limité et ce sont des serveurs haut de gamme (cette exigence disparait avec la version 2005 sous Windows Server 2003) ;
- l'installation du clustering nécessite des compétences étendues au niveau système.
Néanmoins il s'agit d'une solution simple en exploitation, car elle est transparente et permet un basculement automatique sans même qu'aucune intervention humaine ne soit nécessaire.
Le seul inconvénient technique de cette solution est un temps de latence du basculement qui est de quelques dizaines de secondes.
Article en français expliquant les principes du clustering :
Document en anglais de la solution MS :
|
Avantages |
Inconvénients |
|---|---|
|
|
Mais à bien y regarder, cette solution n'est pas toujours aussi couteuse qu'on le croit parce qu'un SAN économise du disque. En revanche, le SAN reste le talon d'Achille, car en cas de sérieux problèmes sur ce dispositif, c'est l'ensemble du système qui est en panne !
Les solutions logiques▲
Basculement avec sauvegardes▲
La solution de basculement avec sauvegarde consiste à mettre en exploitation sur un serveur de secours la plus récente sauvegarde de la base de données et repartir de cette sauvegarde pour commencer une nouvelle exploitation.
Les pertes engendrées dépendent donc :
- du temps de latence des sauvegardes pour la perte des données ;
- des points de reprise fonctionnels pour la perte d'exploitation (vague en cours ?).
Pour réduire la perte des données, on peut augmenter la fréquence des sauvegardes. Dans ce cas un plan de sauvegarde alternant des sauvegardes complète la nuit, des différentielles en production et des sauvegardes du journal de transaction au fil de l'eau peuvent réduire considérablement les temps de latence et faire en sorte que la perte des données soit réduite à une moyenne de quelques minutes d'exploitation.
|
Avantages |
Inconvénients |
|---|---|
|
|
Log Shipping▲
Le log shipping (littéralement « envoi de journaux ») est une technique qui consiste à envoyer de manière planifiée et régulière la partie du journal de la base qui contient les dernières transactions achevées.
En quelque sorte, le Log Shipping introduit de manière automatique la solution vue précédemment.
Les scripts de mise en œuvre de cette technique figurent dans le CD de l'édition Entreprise de MS SQL Server et sa simplicité fait qu'elle peut être mise en œuvre sur n'importe quel serveur de n'importe quelle édition.
Il est possible de descendre le temps de latence entre deux envois de journaux à quelques minutes, afin de minimiser les pertes.
|
Avantages |
Inconvénients |
|---|---|
|
|
Dans la version SQL Server 2000, le Log Shipping constitue souvent la solution de meilleurs compromis entre le coût à tous niveaux et la perte possible.
Réplication▲
La réplication consiste à dupliquer des informations d'une base à une autre. La granularité de la réplication permet de descendre jusqu'à la donnée unitaire (une colonne d'une ligne d'une table). Le système repose donc sur des articles qui sont des parties de tables (filtrage horizontal et vertical), qui sont mis à disposition sur un distributeur que les abonnés viennent reprendre.
Suivant les différents modèles de réplication, la reprise des données se fait par « push » ou « pull ».
La réplication nécessite en fait trois serveurs SQL : le répliqué (éditeur), le serveur de publication et le serveur abonné. Mais en fait le serveur de publication peut être l'un des deux serveurs, et dans le cas de solution de continuité, le mieux est que le serveur de publication soit aussi le serveur abonné.
Les différents modèles de réplications sont les suivants :
- capture instantanée ;
- transactionnelle ;
- fusion.
Ces réplications peuvent être combinées avec une mise à jour immédiate de l'abonnée ou différées.
Dans le cas qui nous préoccupe (solution de continuité), il convient de choisir la solution de réplication dont le temps de latence peut être le plus court. Dans ce cadre il convient donc de préférer la réplication transactionnelle avec mise à jour immédiate. Le gros inconvénient dans ce cas est que les modifications du schéma ne sont pas prises en compte et nécessitent un script à jouer simultanément sur les deux serveurs ainsi qu'une modification de la définition des objets répliqués.
|
Avantages |
Inconvénients |
|---|---|
|
|
Cette solution est celle qui minimise les pertes après le clustering, mais son coût, lié à sa complexité est très élevé, en particulier dans les bases de données dont la structure est sujette à modification.
Mirroring▲
Le mirroring est un concept nouveau introduit avec la version 2005 de MS SQL Server. Ce technique de mise en miroir est simple et pratique. Elle consiste avant tout à dupliquer intégralement une base de données en temps réel, base qui sera alors accessible en lecture seule tant que le miroir est actif et en lecture écriture si le miroir est brisé. Comme dans le cas du clustering, la reprise peut être automatisée et en pratique le basculement s'opère en quelques dizaines de secondes, à condition d'avoir mis en place un serveur de scrutation, qui peut être constitué par une machine bas de game (simple PC) avec le run time SQL Server (Express 2005).
Cette solution n'exige en outre aucun matériel spécifique.
En termes de richesse, souplesse et coût, cette solution s'avère la mieux adaptée pour la haute disponibilité d'un faible nombre de bases de données (quelques unités).
|
Avantages |
Inconvénients |
|---|---|
|
|
S'il y avait une solution à retenir dans le cadre d'epsilon, ce serait certainement celle-là qui possède tous les avantages, mais nécessite la validation de notre logiciel dans la version MS SQL Server 2005.
Solutions externes▲
Diverses solutions externes plus ou moins couteuses sont disponibles afin d'assurer une haute disponibilité avec reprise automatique. Les plus éprouvées sont dans l'ordre :
Double Take
Never Fail :
WANSyncHA :
SQL backup de redGate software :
Seule une étude comparative poussée permettrait d'en présenter avantages, inconvénients et coûts.
De plus amples informations vous sont nécessaires ?▲
Venez en discuter sur le forum public français de Microsoft SQL Server :
news://msnews.microsoft.com/microsoft.public.fr.sqlserver
Ou sur le forum SQL Server de developpez.com :
https://www.developpez.net/forums/forumdisplay.php?f=49