> Data > Clustering de SQL Server

Clustering de SQL Server

Data - Par iTPro.fr - Publié le 24 juin 2010
email

par Brian Knight - Mis en ligne le 16/03/2005 - Publié en Avril 2004

6 étapes vers la haute disponibilité de SQL Server

Pour l'administrateur de bases de données (DBA), la mise en cluster d'un SQL Server est source d'inquiétude, un peu parce que cet exercice était déjà  difficile dans SQL Server 7.0 et les releases antérieures. Heureusement, dans SQL Server 2000, le clustering est moins intimidant. Les six étapes que je couvre dans cet article constituent un canevas de base permettant d'établir un environnement en cluster pour SQL Server 2000 ...Le failover clustering est le meilleur moyen d'instaurer la haute disponibilité dans un environnement SQL Server. Pour mettre en cluster des serveurs Windows, on utilise le service Microsoft Cluster pour relier entre eux plusieurs serveurs. Avec le service Cluster, si une panne survient dans un composant matériel crucial ou dans le service SQL Server, les lecteurs, SQL Server, et les services associés, basculent tous sur un serveur secondaire. Ce basculement généralisé est automatique et prend entre 30 et 60 secondes. Avec d'autres solutions haute disponibilité de SQL Server, comme le log shipping ou la réplication, en cas de défaillance du serveur principal, quelqu'un doit changer manuellement les rôles sur le serveur secondaire. Bien que le log shipping offre une bonne solution de redondance, il s'appuie sur la maintenance manuelle et il peut être difficile à  instaurer.
Avant de commencer l'opération de clustering, il faut bien comprendre que la seule fin du clustering Windows est la haute disponibilité. En effet, le clustering n'améliore pas la performance de SQL Server puisqu'un seul serveur travaille à  la fois - les serveurs reliés ne traitent pas les requêtes ensemble. Pour voir comment le clustering trouve sa place dans le puzzle de la haute disponibilité de SQL Server, voir l'article de Michael Hotek « Solutions haute disponibilité », dans ce numéro.

Clustering de SQL Server

La figure 1 montre une architecture
cluster simplifiée dans laquelle deux
serveurs Windows, appelés noeuds,
partagent une matrice de disques ou
un SAN (storage area network). Vous
pouvez avoir entre deux et huit noeuds
dans un cluster, selon les versions et
éditions de SQL Server et Windows en
place. Par exemple, un cluster exécutant
la version 32 bits de SQL Server
peut comporter jusqu’à  quatre noeuds.
Bien que certains clusters puissent
prendre en charge deux noeuds actifs,
l’architecture de la figure 1 n’en comporte
qu’un : l’autre noeud est passif,
c’est-à -dire en standby. Toutes les
quelques secondes, le service Cluster
adresse une requête simple à  SQL
Server pour s’assurer que le serveur
standby est encore online. Les applications
Client, comme Enterprise Manager
ou une application de votre cru, se
connectent à  SQL Server par l’intermédiaire
d’un nom virtuel ou d’une
adresse VIP (virtual IP) au lieu de le
faire par le nom du serveur et l’adresse
IP réels. En cas de basculement, le serveur
standby s’approprie l’adresse VIP,
de sorte que vous n’avez pas besoin de
changer la chaîne de connexions pour
que l’application fonctionne.
Vous avez le choix entre deux types
de clustering : clustering à  instance
unique ou clustering à  instances multiples
(dans SQL Server 7.0, connus
sous le nom de clustering actif/passif et
clustering actif/actif, respectivement).
Une configuration à  instance unique
n’a qu’une instance SQL Server installée
dans le cluster de deux noeuds ou
plus. Un cluster à  instances multiples a
plusieurs instances SQL Server installées
dans le cluster – en principe, une
instance sur chaque noeud. Quand
vous optez pour le clustering à  instances
multiples, vous devez vous assurer
que le ou les serveurs participant
au cluster ont suffisamment de puissance
de processeur et de RAM pour
assumer les instances multiples de SQL
Server.
Dans un cluster à  instance unique,
il suffit d’acheter une licence pour le
seul noeud actif. Exception : quand
vous avez un contrat de licence SQL
Server par processeur et qu’il y a davantage
de processeurs sur le ou les
noeuds passifs que sur le noeud actif.
Dans un tel cas, vous devez acquérir la
licence des processeurs supplémentaires.
Dans un cluster à  instances multiples,
vous devez acquérir la licence
pour tous les noeuds actifs sur lesquels
SQL Server est installé.

Téléchargez cette ressource

SD-WAN de confiance : guide de mise en œuvre

SD-WAN de confiance : guide de mise en œuvre

Ce livre blanc décrit les différents aspects indispensables pour la mise en place d’une approche SD-WAN sécurisée et de confiance. Ce document s’adresse aux consultants et responsables sécurité des systèmes d’information pour bien comprendre les enjeux du Trusted SD-WAN à l’heure de la transformation numérique des entreprises.

Data - Par iTPro.fr - Publié le 24 juin 2010

A lire aussi sur le site

Revue Smart DSI

La Revue du Décideur IT