Au fil du temps, le traitement des données a pris une place de plus en plus prédominante au sein des entreprises. Alors que le volume des données a littéralement explosé – et continue à le faire -, les systèmes de gestion de bases de données ont su s’adapter et offrent aujourd’hui des solutions performantes en termes de gestion de la mémoire, des accès-disque,… Il reste un élément d’infrastructure à ne pas négliger : la haute disponibilité.

En effet, sans haute disponibilité, tout système subissant une défaillance hardware ou software devient immédiatement inaccessible pour ses « clients », avec les conséquences que l’on imagine. Dans le contexte du plan de contingence, les techniques de HA (High Availability) permettent de réduire fortement l’indisponibilité des systèmes, voire de la rendre imperceptible pour ses « clients ».

Microsoft SQL Server, dans sa version 2012, introduit d’importantes nouveautés de type HA : les solutions AlwaysOn se déclinent en deux nouvelles fonctionnalités implémentant à la fois la haute disponibilité au niveau des bases données elles-mêmes ainsi qu’au niveau des instances SQL Server.

Les groupes de disponibilité AlwaysOn

En cas d’incident technique, la mise en œuvre des « Groupes de disponibilité AlwaysOn » réduit l’indisponibilité d’un ensemble de base de données, sans nécessiter l’achat de matériel spécifique. La force de MS-SQL 2012 tient en la mise en miroir des bases de données par l’utilisation, comme fondation, de la définition en cluster de serveurs Windows. Ainsi, le système de bases de données tire profit de la mise en miroir tout en bénéficiant d’un accès facilité aux données et d’une centralisation de l’interface de gestion.

Contrairement à la mise en miroir seule, l’implémentation de la technologie éprouvée du cluster Windows fournit aux applications clientes un identifiant unique (nom réseau et adresse IP) pour accéder aux bases du Groupe de disponibilité. Les applications ne doivent donc plus nécessairement utiliser des librairies spécifiques ou mettre en œuvre des solutions de contournement pour garantir la continuité du service après un basculement entre réplica primaire et secondaire. De plus, l’état de santé du Groupe sera évalué par le cluster lui-même et non plus par un serveur SQL supplémentaire exécutant un rôle de « Witness ».

Un des atouts des Groupes de disponibilité en tant qu’amélioration de la mise en miroir, permet d’avoir plusieurs réplicas (ou copies) des bases du Groupe dont certains accessibles en lecture seule. Cela autorise, par exemple, l’exécution de rapports gourmands en ressources sur un serveur dédicacé ; optimisant, de la sorte, l’utilisation des ressources des serveurs primaire et secondaires, les performances globales du système s’en trouvent améliorées.

Déplacer l’exécution des requêtes en lecture seule sur un réplica n’est pas le seul moyen de décharger le serveur primaire (dit aussi « actif »). En effet, avec les Groupes de disponibilité, les sauvegardes peuvent être effectuées sur n’importe quel réplica de bases de données. En cas d’indisponibilité du réplica choisi, le processus de sauvegarde sélectionnera automatiquement un autre réplica en suivant un algorithme personnalisable. De plus, les fichiers de sauvegardes peuvent être envoyés sur un partage réseau pour centralisation et sécurisation. Lors de la restauration, le système récupérera automatiquement l’historique en appliquant les sauvegardes dans l’ordre adéquat indépendamment du serveur les ayant effectuées.

Par ailleurs, les groupes de disponibilité héritent du mécanisme de réparation automatique de pages corrompues de SQL 2008 (« automatic page repair »). En effet, chaque transaction SQL est exécutée séparément sur chacun des réplicas ce qui limite la réplication d’une éventuelle corruption. Lorsqu’un serveur (primaire ou secondaire) détecte une corruption au niveau d’une de ses pages, il est capable de récupérer la page non corrompue sur un réplica.

En termes de gestion, la version 2012 offre une toute nouvelle interface unique regroupant l’ensemble des opérations de configuration et de paramétrage pour une gestion simplifiée.

Instances de cluster de basculement AlwaysOn

Les instances de cluster de basculement de SQL Server existaient déjà dans les versions précédentes. Des nouveautés et améliorations y ont été apportées.

Dans un environnement SQL Server, la vitesse d’accès à la base de données système temporaire (tempDB) est importante. En effet, SQL Server utilise cette base pour stocker les informations temporaires qu’il ne peut laisser en mémoire. Les accès en lecture/écriture y sont donc très importants. Avec SQL Server 2012, il est maintenant possible de placer la base de données temporaire sur un disque local, comme par exemple un disque SSD.

Avec les versions précédentes, lorsqu’une instance SQL Server devait être basculée sur un autre serveur, il n’était pas toujours possible de prédire le temps nécessaire au basculement. Aujourd’hui, SQL Server 2012 est capable de fournir une estimation de ce temps. De plus, il est possible de personnaliser les conditions entraînant la bascule d’une instance, ce qui permet d’affiner les conditions qui la déclenchent.

Vous voulez en savoir plus ?

Devoteam présentera plus en détail la technologie AlwaysOn ainsi qu’une démonstration de ces nouvelles fonctionnalités à l’occasion d’un séminaire petit-déjeuner organisé par Devoteam le vendredi 29 juin prochain dans ses locaux à Windhof.

8 :30 – Accueil & petit-déjeuner

9 :00 – Introduction : Olivier Michot – Managing Director Operations – Devoteam

9 :15 – 10 :00 – « AlwaysOn » avec Pierre Destrée – Practice Director Infrastructure services – Devoteam

10 :00 – Questions/réponses