Bonjour à tous !
SQL Server est depuis longtemps rompu à la nécessaire disponibilité des données. Mais quelles sont les différentes solutions proposées, et que peut-on en attendre ?
Je vous propose aujourd'hui un résumé de chaque solution proposée par Microsoft avec SQL Server 2005, et ce que vous pouvez raisonnablement espérer de chacune d'entre elles.
LOG SHIPPING ET MIRRORING - DEUX SOLUTIONS, UNE FINALITEBeaucoup ont entendu parler de Log Shipping, nombreux sont ceux qui ont entendu parler de mirroring... Mais pour quel résultat, quel impact sur l'existant, quelle maintenance ?
Le Log Shipping est reconnu depuis longtemps comme une solution peu onéreuse, simple à mettre en oeuvre, mais assez délicate à exploiter, en particulier lors d'un basculement de serveur. En effet, le basculement est manuel, la perte des dernières données probable, car le temps d'indisponibilité fluctue en fonction de la réactivité du DBA.
Le Mirroring peut être vu comme une solution de Log Shipping évoluée. Si le mode SAFETY OFF est sélectionné, le Mirroring se comporte en effet comme le Log Shipping, recopiant le journal de transaction au fil de l'eau. Le temps de latence reste globalement plus faible que dans le cas du Log Shipping, et la mise en oeuvre est totalement automatisée.
En revanche, si l'on sélectionne le mode SAFETY FULL, le Mirroring permet de garantir à l'utilisateur une parfaite synchronisation des bases de données, ce que ne permet pas le Log Shipping.
De plus, l'utilisation d'un WITNESS permet d'automatiser le processus de basculement des serveurs en cas d'erreur.
Qu'il s'agisse de Log Shipping ou de Mirroring, l'initialisation des bases de données s'effectue par Backup/Restore.
Devant ces similitudes, je privilégie donc largement le Mirroring sous SQL Server 2005, qui permet un temps de latence bien plus faible que son copain le Log Shipping.
De plus l'utilisation d'un WITNESS assure un basculement automatique des plus appréciables, et qui plus est l'un des plus rapides du marché avec un temps d'absence de service inférieur à 5 secondes.
REPLICATION ET DISTRIBUTION DES DONNEESL'utilisation de la distribution des données comme moyen de haute disponibilité est une méthode couramment utilisée.
Il existe de nombreux moyens de distribuer ses données. Le plus simpliste reste la copie par batch des données à intervalle régulier. Cette méthode très simple à mettre en oeuvre s'apparente dans les applications à du Log Shipping, même si son procédé est radicalement différent. De plus, il est possible d'utiliser la base de données ainsi obtenue en lecture par exemple.
Pour les bases de faible volumétrie et supportant le risque de la perte des données les plus récentes, la réplication snapshot correspond aussi à cette problématique. En revanche, contrairement au batch de recopie, la réplication snapshot supporte difficilement les très grosses volumétries.
Enfin, pour une distribution assurant une plus grande fraîcheur de données, la réplication transactionnelle offre également un compromis intéressant. Là encore, les données sont accessibles en lecture. En revanche, la publication transactionnelle doit être désactivée pour effectuer quelque changement que ce soit dans la structure des données. De plus, la réplication transactionnelle s'avère souvent très fragile dès qu'une opération de maintenance sur le journal de transactions est nécessaire.
La distribution des données, qu'il s'agisse d'un batch ou d'une réplication, aussi faible son temps de latence soit-il, n'est pas à proprement parler une véritable solution de haute disponibilité. En revanche, il peut s'agir d'un compromis efficace pour pallier à une éventuelle défaillance du système tout en conservant l'utilisation de toutes les machines achetées.
CLUSTERING
Le clustering reste la méthode reine de la haute disponibilité, permettant entre autres de ne spécifier qu'une seule adresse réseau pour plusieurs ordinateurs physiques, assurant ainsi un basculement transparent pour les applications clientes.
Pour être mis en oeuvre, le clustering demande des connaissances avancées tant sur la partie SQL Server que sur le système d'exploitation.
Le point noir du clustering proposé par Microsoft reste l'inactivité des serveurs de secours, induisant un coût d'immobilisation supplémentaire. De plus, le clustering n'apporte aucune solution en cas de destruction physique des supports de stockage - incendie par exemple - étant donné que ces ressources physiques sont partagées entre les différents noeuds (je n'évoquerai pas ici les possibilités de géo-cluster pour des raisons de simplification).
Concernant les surcoûts d'immobilisation, il faut tout de même noter que dans le cadre du clustering, tout comme dans le cadre du mirroring, un serveur de secours actif moins de 30 jours par an ne requiert aucune licence.
Le délai de basculement de serveur dans le cas du clustering avoisine les 30 secondes, à mettre en parallèle avec les 5 secondes du mirroring.
Contrairement à son grand concurrent ORACLE, SQL Server ne dispose pas d'une réelle solution de clustering Actif-Actif. Microsoft préfère en effet privilégier l'accroissement des performances monoserveurs. Pour ceux dont l'architecture nécessiterait un scale out, il est possible d'implémenter une solution alternative consistant à créer deux clusters Actif-Passif croisés, simulant de fait le clustering Actif-Actif.
REPLICATION PEER-TO-PEER ET MIRRORING "ACTIF-PASSIF"Microsoft offre également d'autres méthodes permettant d'utiliser les différentes machines tout en limitant les pertes de données potentielles en cas de crash système.
La plus ancienne des deux méthodes que je vous présenterai ici est la réplication Peer-To-Peer. Il ne s'agit ni plus ni moins que d'une réplication transactionnelle bi-directionnelle.
Ce type de réplication est extrêmement utile dans le cadre de sites de sauvegarde délocalisés. De plus, tous les serveurs sont actifs. Si l'on multiplie les noeuds de réplication, cette méthode s'avère très efficace et permet même d'envisager un partage de charge (Load Balancing). En revanche, contrairement au clustering, chaque machine est identifiée individuellement, et par conséquent le partage de charge doit être géré à un niveau plus bas, par exemple à l'aide d'un switch actif.
Une autre technique, s'appuyant sur le mirroring, permet d'avoir accès en lecture aux bases de données. Cette méthode nécessite un partage de ressource à l'aide, par exemple, d'une baie SAN, et un seul serveur accède à la base en écriture. Cette solution peut être très intéressante dans le cas de DataWareHouse nécessitant une grande capacité de calcul lors des lectures. Un des serveurs mirroirs prend le relai en cas de panne du serveur maître.
La réplication Peer-To-Peer est une solution largement répandue, mais souvent utilisée pour ses capacités de rapprochement des données des utilisateurs plus que pour la haute disponibilité ainsi procurée.
EN CONCLUSIONJe concluerai ce post en faisant le constat suivant : le besoin métier pilote évidemment le choix technologique, tant par les aspects financiers que par les aspects de criticité des données. Il est donc primordial de bien prendre en compte tous les éléments avant de définir une architecture de serveurs de bases de données, cela conditionnant également le développement des applications gravitant autour de celle-ci.
A très bientôt !
