Guide de Clustering et mise en miroir de bases de données

Votre environnement en cluster pourrait être configuré afin de prendre en charge des vues partitionnées chargées de traiter les besoins en évolutivité. Windows Server 2008 a réalisé des avancées dans le clustering multi-sites et a même supprimé la restriction du « même sous-réseau ».

Guide de Clustering et mise en miroir de bases de données

Malheureusement, les serveurs SQL Server 2008 en cluster restent soumis à cette restriction, d’où la contrainte d’une approche de VLAN pour une base de données en cluster géographiquement disséminée. Si vous avez des MCSE compétents dans votre équipe, un environnement en cluster multi-sites pourrait constituer la solution idéale pour gérer les besoins de reprise après sinistre, de haute disponibilité et d’évolutivité de vos bases de données.

Avec l’ajout de la mise en miroir de base de données dans SQL Server 2005, la haute disponibilité est devenue extrêmement accessible. Elle est facile à implémenter et à administrer, et le coût supplémentaire induit est, dans la majorité des cas, symbolique.

Si vous avez plusieurs bases de données, vous pouvez obtenir une dose homéopathique d’évolutivité en les configurant de telle sorte qu’une moitié soit active sur le premier serveur et que l’autre moitié soit passive sur le deuxième serveur. Cette solution n’est pas parfaite, mais a le mérite d’être efficace et utile. L’expérience montre que le processus de mise en miroir ajoute une charge négligeable de 1 à 2 pour cent sur le serveur, ce qui est plus que compensé par les avantages procurés.

La technologie de mise en miroir dans SQL Server repose sur deux approches fondamentales très différentes : la sécurité élevée et les hautes performances. La sécurité élevée fournit l’approche de mise en miroir synchronisée que vous attendez généralement de miroirs de base de données. Sur un LAN, elle fournit la haute disponibilité recherchée, mais sans disposition pour la reprise après sinistre ou l’évolutivité. Du point de vue technique, vous pouvez déployer le mode à sécurité élevée sur un WAN, mais si vous employez un outil de surveillance de pulsations pour le miroir, vous devez prendre des décisions difficiles concernant l’emplacement de l’outil en question, ainsi que l’incidence de défaillances du WAN sur votre configuration de miroir.

La deuxième approche est le mode hautes performances asynchrone. Dans ce cas, la notion « asynchrone » constitue la clé. Le serveur actif transfère en continu les transactions au serveur passif, mais il n’attend pas de confirmation de la part du miroir passif. L’approche hautes performances est idéale pour les scénarios de reprise après sinistre, comme l’atteste la documentation en ligne de SQL Server.

Pour être réaliste, il s’agit plutôt d’une approche améliorée de l’envoi de journaux, l’envoi ne se situant dans ce cas au niveau des transactions. Malheureusement, vous devez choisir entre la sécurité élevée et les hautes performances. Si vous souhaitez combiner une configuration de miroir à sécurité élevée sur un LAN avec un miroir hautes performances sur un WAN, vous obtiendrez une configuration de haute disponibilité et de reprise après sinistre saine et facile à implémenter, à condition qu’elle soit supportée. Cela peut faire partie des doléances pour les futures versions de SQL Server.

Dans ce scénario, l’évolutivité reste largement ouverte et dépendante de l’approche verticale. Si vous employez le basculement en mode à sécurité élevée, la base de données est transférée d’un serveur à l’autre, d’où une approche relativement facile pour le passage à des matériels plus conséquents. Pour ce qui de la reprise après sinistre, vous pouvez vous rabattre sur l’envoi de journaux.

Une autre option pour la mise en miroir est proposée avec la gamme de produits de Neverfail Ltd. Alors que les miroirs SQL Server fonctionnent au niveau base de données, Neverfail préfère la mise en miroir au niveau serveur. Elle peut être locale ou via un WAN pour la reprise après sinistre. Comme les bases de données sont transactionnelles, une rapidité digne de ce nom est critique pour être certain que la mise en miroir au niveau serveur capture toutes les transactions en cas de basculement.

Avant l’introduction des miroirs, l’envoi de journaux était quasiment le seul outil disponible pour gérer la haute disponibilité et la reprise après sinistre. Comme son nom le suggère, le processus envoie les journaux des transactions de base de données vers un ou plusieurs autres serveurs de base de données de secours (secondaires).

L’envoi des journaux des transactions à un serveur de secours local et à un serveur de secours distant propose une solution de reprise après sinistre et de haute disponibilité relativement robuste. En l’espace de quelques minutes, un des serveurs de base de données de secours peut être récupéré et être placé en ligne avec des pertes de données transactionnelles réduites au minimum. Un facteur clé de l’étendue de la perte de données est la fréquence des sauvegardes des journaux des transactions et la vitesse à laquelle ils sont transmis sur le réseau jusqu’aux serveurs de secours. Néanmoins, comme pour la mise en miroir, l’évolutivité est généralement traitée par une approche verticale.