Résumé : le clustering de basculement sql server, qui inclut la prise en charge des configurations de basculement locales et multisite, fait partie de la suite d'implémentation sql server 2012 AlwaysOn,
télécharger 58.35 Kb.
|
  SQL Server 2012 AlwaysOn : Instance de cluster de basculement multisite Article technique SQL Server Auteurs : Mike Weiner, Sanjay Mishra, Min He Contributeurs : Lingwei Li, Mike Anderson (EMC Corporation) Relecteurs techniques : Shaun Tinline-Jones, Steve Howard, Prem Mehra, Paul Burpo, Mike Ruthruff, Jimmy May, Matt Neerincx, Dan Benediktson, Michael Steineke (Edgenet Inc.), David P. Smith (ServiceU Corporation) Date de publication : décembre 2011 S'applique à : SQL Server 2012 Résumé : le clustering de basculement SQL Server, qui inclut la prise en charge des configurations de basculement locales et multisite, fait partie de la suite d'implémentation SQL Server 2012 AlwaysOn, conçue pour fournir la haute disponibilité et la récupération d'urgence pour SQL Server. La technologie de clustering de basculement multisite a été considérablement améliorée dans SQL Server 2012. Ce document traite essentiellement de l'architecture de cluster de basculement multisite, des améliorations apportées par SQL Server 2012 à la technologie, et des meilleures pratiques de déploiement. Copyright Ce document est fourni « en l'état ». Les informations et les opinions exprimées dans ce document, y compris les adresses URL et les autres références à des sites Internet, peuvent faire l'objet de modifications sans préavis. Vous assumez tous les risques liés à son utilisation. Certains exemples mentionnés dans ce document ne sont fournis qu'à titre indicatif et sont fictifs. Toute ressemblance ou similitude avec des éléments réels est purement fortuite et involontaire. Ce document ne vous concède aucun droit de propriété intellectuelle portant sur les produits Microsoft. Vous pouvez copier et utiliser ce document à titre de référence pour un usage interne. © 2011 Microsoft. Tous droits réservés. SommaireIntroduction 4 Cluster de basculement multisite SQL Server 2012 - Architecture 4 Composants requis pour créer un cluster de basculement multisite 6 Matériel serveur et système d'exploitation 6 Stockage 6 Réseau 7 Modèle de quorum du cluster de basculement Windows Server (WSFC) 7 Tests de labo des clients SQL Server et améliorations du cluster de basculement multisite 8 Problèmes, limitation des risques, et leçons tirées 10 Contrôle de la validation du stockage 10 Configuration des adresses IP dans le gestionnaire du cluster de basculement avec une dépendance OR 11 Modèle de quorum approprié 11 Inscription du réseau et connectivité client après le basculement d'une instance FCI SQL Server à plusieurs sous-réseaux 12 Conclusion 14 Annexe 15 Environnement matériel et logiciel en laboratoire 15 Serveurs 15 SQL Server 15 Stockage 15 Logiciel de stockage 16 IntroductionCe livre blanc présente les améliorations et les éléments à prendre en considération en ce qui concerne la technologie de cluster de basculement multisite dans SQL Server 2012. Il traite des sujets suivants :
Ce test a été effectué avec la version préliminaire. Toutefois, les fonctionnalités testées en laboratoire étaient proches de leur version définitive dans cette build, c'est pourquoi, aucun changement majeur n'est à prévoir dans la version de produit finale. Cluster de basculement multisite SQL Server 2012 - ArchitectureLorsque vous évaluez des options de haute disponibilité pour un environnement Microsoft SQL Server, plusieurs fonctionnalités SQL Server peuvent vous aider à atteindre les objectifs de disponibilité des applications de votre organisation. La technologie de clustering de basculement SQL Server est disponible dans le produit en tant que stratégie de haute disponibilité depuis plus d'une décennie. En utilisant un clustering de basculement SQL Server, une instance de SQL Server peut s'exécuter sur un seul nœud du cluster à tout moment. Si l'instance de SQL Server ne peut pas s'exécuter sur un nœud pour une raison quelconque (par exemple, une défaillance matérielle) elle peut basculer vers un autre nœud, garantissant une haute disponibilité au niveau de l'instance SQL Server. De nombreuses entreprises ont des centres de données éloignés les uns des autres, ou bien, elles possèdent un centre de données secondaire, qui assure la redondance des sites, et permet la récupération d'urgence. Une telle configuration est essentiellement destinée à se prémunir contre les défaillances d'un site, qu'il s'agisse d'un problème réseau, d'alimentation électrique, d'infrastructure ou d'autre nature. De nombreuses solutions utilisent le clustering de basculement Windows Server et SQL Server avec ce modèle multisite. Un cluster de basculement multisite comprend des nœuds dispersés sur plusieurs sites physiques ou centres de données, dans le but d'assurer la disponibilité des autres centres de données en cas de panne d'un site. Les clusters de basculement multisite sont parfois appelés des clusters de basculement géographiquement dispersés, des clusters étendus, ou des clusters à plusieurs sous-réseaux. Actuellement, pour déployer les clusters de basculement multisite SQL Server 2008 R2, vous devez déployer les technologies suivantes en plus du clustering de basculement SQL Server :
Dans Windows Server 2003, toutes les dépendances de ressource de cluster étaient des dépendances AND. (Remarque : dans Windows Server 2003, les clusters de basculement étaient appelés des « cluster de serveurs ».) Par exemple, si la ressource « SQL Server » dépendait des ressources « IP Address » et « Disk 1 », le cluster Windows pouvait mettre en ligne la ressource « SQL Server » uniquement si les ressources « IP Address » et « Disk 1 » étaient déjà en ligne. Windows Server 2008 introduit la possibilité de spécifier des dépendances OR entre les ressources ; pour plus d'informations, consultez l'entrée de blog Expressions de dépendance de ressource du cluster (http://blogs.msdn.com/b/clustering/archive/2008/01/28/7293705.aspx). Cet ajout signifie que vous pouvez spécifier que la ressource « SQL Server » dépend de « Disk 1 » AND (« IP Address1 » OR « IP Address2 »). Grâce à cette configuration, chaque site dans un cluster comportant plusieurs sous-réseaux peut être inscrit avec une adresse IP différente, tout en offrant la possibilité d'une dépendance de ressource « SQL Server » qui ne requiert qu'une seule adresse IP pour la liaison. Toutefois, SQL Server 2008 R2 ne prend pas en charge les dépendances OR entre les adresses IP de Windows Server 2008. Dans SQL Server 2008 R2 et les versions antérieures, SQL Server itère sur toutes les adresses IP du groupe de ressources de basculement et tente de se connecter à toutes au démarrage. Si une liaison échoue, le démarrage de SQL Server échoue. Par conséquent, dans SQL Server 2008 R2 et les versions antérieures, des VLAN étendus ont été utilisés pour permettre le clustering de basculement multisite de SQL Server. Cependant, de nombreux clients hésitent à déployer des VLAN étendus pour des raisons de sécurité, de coût, de complexité, ou d'incompatibilité avec certaines règles d'entreprise. Cela a considérablement restreint le déploiement des solutions SQL Server multisite et le clustering à plusieurs sous-réseaux. Avec SQL Server 2012 des améliorations ont été apportées à l'implémentation multisite et, plus précisément, au clustering de basculement à plusieurs sous-réseaux. Les deux améliorations majeures, permettant de prendre en charge le clustering à plusieurs sous-réseaux, sont les suivantes :
Dans les labos des clients SQL Server, cette nouvelle fonctionnalité a été testée avec une version préliminaire de SQL Server 2012. La suite de ce document détaille les conditions requises pour configurer un cluster de basculement multisite SQL Server dans SQL Server 2012, et documente l'installation du labo, les tests et les leçons tirées de cette expérience. Composants requis pour créer un cluster de basculement multisiteLorsque vous créez un cluster de basculement multisite SQL Server, vous devez prendre en considération un certain nombre de composants. Les paragraphes suivants abordent ces composants et d'autres éléments. Matériel serveur et système d'exploitationConfiguration matérielle : le matériel du cluster doit correspondre à une configuration prise en charge (Windows Server 2008 R2 ou une version ultérieure), en fonction des recommandations répertoriées ici : Stratégie de prise en charge Microsoft pour les clusters de basculement Windows Server 2008 ou Windows Server 2008 R2 (http://support.microsoft.com/kb/943984). Ces instructions nécessitent l'exécution d'un test de validation sur le cluster ; pour cela, vous pouvez exécuter l'assistant de validation de cluster via le composant logiciel enfichable Gestionnaire du cluster de basculement. Logiciel Microsoft : Windows Server et SQL Server. Chaque édition de Windows Server et de SQL Server propose une prise en charge différente en termes de nombre de nœuds pour un cluster de basculement (instance). En outre, chaque version prend en charge des fonctionnalités différentes pour le clustering de basculement. Pour plus d'informations, consultez Nouveautés des clusters de basculement pour Windows Server 2008 R2 (http://technet.microsoft.com/fr-fr/library/dd621586(WS.10).aspx). Ce document décrit une partie des changements apportés à SQL Server 2012 ; une présentation complète de toutes les modifications est prévue dans la Documentation en ligne de SQL Server et dans d'autres articles, dont la publication est planifiée simultanément au lancement de la version finale de SQL Server 2012. Remarque : l'une des exigences spécifiques à l'implémentation du cluster de basculement Windows Server (WSFC) est que tous les nœuds dans le cluster doivent faire partie du même domaine. StockagePour le stockage, plusieurs composants sont à prendre en considération : Premièrement, la connectivité avec le stockage : La connectivité locale est généralement fournie via des connexions commutées Fibre Channel, où un seul nœud a la propriété exclusive des numéros d'unité logique (LUN) et des lecteurs à un moment donné. Lors du basculement, un autre nœud peut exclusivement prendre possession du stockage. Dans le scénario de cluster multisite, les différents dispositifs de stockage sont généralement situés dans les deux sites. Lorsque les nœuds locaux ont besoin d'accéder au stockage, une connectivité est également fournie entre les unités de stockage utilisées pour relier les nœuds. Le type et les performances du mécanisme de connectivité entre les baies de stockage sont des éléments essentiels de la solution, qui déterminent les performances du basculement et des E/S. Deuxièmement, la technologie de réplication du stockage utilisée pour répliquer les E/S entre les unités de stockage dans les sites. Cette technologie est fournie par le fournisseur de stockage. Enfin, le fournisseur de stockage fournit également un composant logiciel pour automatiser le basculement entre les unités de stockage, et pour déterminer quels disques sont accessibles et montés, dans le cluster, lors d'un basculement. RéseauLe composant réseau est tout aussi important dans un environnement multisite (à plusieurs sous-réseaux). La configuration de l'instance de SQL Server avec une adresse IP valide dans l'un des sous-réseau est une étape essentielle. Il existe quelques différences entre SQL Server 2012 et les versions antérieures. Pour commencer, bien que SQL Server 2012 fournisse la prise en charge intégrée d'une configuration à plusieurs sous-réseaux, en configurant SQL Server de sorte à utiliser un VLAN ou un réseau unique, la configuration est toujours valide et prise en charge. Ensuite, dans SQL Server 2008 et SQL Server 2008 R2, la durée de vie (TTL, Time To Live) et d'autres configurations de réplication DNS étaient essentielles pour les scénarios de basculement et la connectivité client. Or, ces configurations ne sont plus nécessaires dans un clustering de basculement SQL Server 2012, car la configuration réseau et le pilote client ont été améliorés. Pour plus d'informations, consultez « Problèmes, limitation des risques, et leçons tirées » plus loin dans ce document. Enfin, d'autres éléments doivent être pris en compte pour la connexion, par exemple le réseau de pulsation pour le cluster Windows, qui a un rôle important mais qui ne sera pas abordé dans ce document. Modèle de quorum du cluster de basculement Windows Server (WSFC)Avec Windows Server 2008 et Windows Server 2008 R2, quatre types de configuration de quorum sont pris en charge. Ces modèles de quorum sont décrits dans le Guide pas à pas du cluster de basculement : configuration du quorum dans un cluster de basculement (http://technet.microsoft.com/fr-fr/library/cc770620(WS.10).aspx). Il existe également des spécificités en ce qui concerne le modèle de quorum dans un cluster de basculement multisite. Pour plus d'informations à ce sujet, consultez l'article Exigences et recommandations pour un cluster de basculement multisite, (http://technet.microsoft.com/fr-fr/library/dd197575(WS.10).aspx), à la puce « Nombre de nœuds et configuration de quorum correspondante ». Pour résumer les informations contenues dans les liens : Pour le clustering de basculement multisite avec un nombre pair de nœuds, la configuration de quorum Nœud et partage de fichiers majoritaires est une option recommandée. Une ressource de contrôle décisive, que ce soit un disque, un nœud, ou un témoin de partage de fichiers, doit être utilisée. Un témoin de partage de fichiers est généralement recommandé, car il est souvent plus facile de garantir que le partage de fichiers est accessible aux deux sites. Pour les clusters qui ont un nombre impair de nœuds, l'option Nœud majoritaire est conseillée. Toutefois, dans cette configuration, si le site qui possède le plus de nœuds (généralement, le site principal) est en panne, une intervention manuelle est nécessaire pour forcer un cluster à démarrer sur le site secondaire, car le quorum est perdu. Tests de labo des clients SQL Server et améliorations du cluster de basculement multisitePour observer une partie des nouvelles fonctionnalités disponibles pour les topologies à plusieurs sous-réseaux, l'équipe de consultants clients de SQL Server (SQLCAT) a effectué des tests à Redmond, dans l'État de Washington, aux États-Unis. L'objectif principal était de configurer un cluster de basculement à plusieurs sous-réseaux entre deux sites et d'exécuter une charge de travail cliente sur la configuration au fil d'une série de tests. La configuration du laboratoire était la suivante. Configuration matérielle et logicielle :
Stockage : Deux baies de stockage d'entreprise EMC Symmetrix VMAX, une pour chaque site. Les baies ont été configurées avec deux moteurs de stockage VMAX et 240 lecteurs de disques. Les lecteurs comprenaient des disques EFD (Enterprise Flash Drives), Fibre Channel et SATA. Pour les besoins du test, une partie des disques Fibre Channel ont été présentés au cluster de basculement Windows Server 2008 R2 dans une configuration en miroir. Neuf volumes de 112 Go ont été utilisés pour le stockage des données et des journaux. Un volume de 300 Go a été utilisé pour mettre en attente les sauvegardes des données et des journaux. Chaque baie es connectée aux serveurs de test au moyen de connexions Fibre Channel 8 Gbits/s. Les baies de stockage utilisent la fonctionnalité SRDF (Symmetrix Remote Data Facility), qui contient des pointeurs disponibles dans l'annexe, pour envoyer des données de la baie source à la baie cible. Lors du test, les dispositifs de stockage source, appelés volumes R1, envoient des données aux dispositifs de stockage cible, appelés volumes R2. Lors d'un basculement de site, SRDF/CE (Cluster Enabler) détecte l'état de réplication de la baie car il est associé au nœud WSFC actif. SRDF/CE gère également toutes les modifications d'état de la réplication. Les baies communiquent à l'aide de connexions Ethernet 1-Gbits/s. L'utilisation de liaisons Ethernet a permis à l'équipe de test d'utiliser un équipement de génération de latence réseau pour injecter des délais dans le test, simulant ainsi la communication à distance.  Figure 1 : Schéma de la configuration multisite, avec réplication du stockage entre les sites et les unités de stockage Réseau : Pour simuler un réseau multisite, trois sites logiques ont été créés. Le « Site A » hébergeait deux nœuds de cluster de basculement et l'une des baies de stockage. Le « Site A » a été configuré pour son propre sous-réseau. Le « Site B » se trouvait sur un sous-réseau différent qui hébergeait les autres baies et nœuds du cluster. Un troisième site/sous-réseau hébergeait la structure Active Directory, le partage de fichiers pour le quorum Windows Server, et un seul serveur DNS. Bien qu'un troisième site ne corresponde pas à l'architecture courante d'une implémentation réelle, les résultats des tests et les informations tirées de cette topologie peuvent fournir des données valides, que vous pouvez appliquer à l'environnement de votre organisation. Pour plus d'informations sur les éléments à prendre en compte pour la connectivité client et l'inscription du réseau sur un basculement FCI SQL Server, consultez « Problèmes, limitation des risques, et leçons tirées » plus loin dans ce document. Modèle de quorum : Dans notre test, nous avons utilisé le modèle de quorum Nœud et partage avec Partage de fichiers. Nous avons placé le partage de fichiers dans un troisième sous-réseau accessible à tous les autres sous-réseaux. Il s'agit ici d'une option parmi d'autres pour le modèle de quorum dans un scénario de cluster de basculement à plusieurs sous-réseaux. Vous devez choisir le modèle le plus viable pour l'implémentation globale de votre organisation. Pour plus d'informations sur les modèles de quorum, consultez « Modèle de quorum du cluster de basculement Windows Server (WSFC) » plus haut dans ce document. Charge de travail Pour un scénario de test plus réaliste, nous avons exécuté une charge de travail très orientée écriture (plus de 90 %) et comportant environ 2 000 traitements par seconde, pour placer une charge d'E/S sur l'environnement de cluster de basculement. L'E/S étaient relativement réduites, simulant une application OLTP à haut débit. Nous avons testé de nombreux scénarios de basculement, y compris le basculement manuel (Déplacer le groupe) et la panne de courant, au moyen de différents mécanismes, sur le serveur hébergeant l'instance FCI de SQL Server. Le comportement du basculement, avec et sans exécution de la charge de travail, a été tel que prévu. Nous avons identifié un certain nombre d'éléments clés et de facteurs à considérer à l'issue du test. Nous vous les communiquons dans la section suivante. Problèmes, limitation des risques, et leçons tiréesDans nos tests et autres expériences de clustering de basculement multisite avec les versions préliminaires de SQL Server 2012, nous avons identifié un certain nombre éléments que nous estimons importants pour les clients qui s'apprêtent à créer et déployer leurs propres solutions de clustering de basculement avec SQL Server 2012. Contrôle de la validation du stockageDans un environnement de cluster multisite avec réplication SAN, il est prévu que les volumes de stockage sur un site soient visibles uniquement aux nœuds du même site, et que les volumes de stockage de l'autre site soient visibles uniquement aux nœuds de ce site. Par conséquent, tous les volumes du stockage ne sont pas visibles par tous les nœuds à la fois, et les contrôles de validation peuvent ne pas passer, ou générer des avertissements. Si vous ignorez les tests de validation du stockage, un message s'affiche, vous demandant de confirmer que vous n'avez pas besoin de l'assistance de Microsoft : « Non. Je n’ai pas besoin de l’assistance de Microsoft pour ce cluster, et par conséquent, je ne souhaite pas exécuter les tests de validation. Lorsque je clique sur Suivant, poursuivre la création du cluster. ». Dans cet environnement, les tests de validation du stockage peuvent être ignorés, car une solution de cluster multisite ne requiert pas ces tests pour être entièrement prise en charge. Pour plus d'informations, consultez « Clusters dispersés géographiquement » dans l'article de la Base de connaissances Stratégie de prise en charge Microsoft pour les clusters de basculement Windows Server 2008 ou Windows Server 2008 R2 (http://support.microsoft.com/kb/943984). Remarque : seul le contrôle de validation du stockage peut être ignoré. Si toutes les validations sont ignorées, ou s'il y a des avertissements ou des erreurs dans le rapport de validation, le programme d'installation de SQL Server le détecte et bloque l'installation. Configuration des adresses IP dans le gestionnaire du cluster de basculement avec une dépendance ORLorsque vous configurez un cluster de basculement à plusieurs sous-réseaux, une seule adresse IP doit être en ligne. Les autres peuvent rester hors connexion jusqu'au basculement vers ce sous-réseau. Étant donné que cela peut apparaître comme une mauvaise configuration, nous avons fourni un exemple pour illustrer la façon dont le gestionnaire du cluster de basculement affiche cette configuration. Notez que selon le sous-réseau qui héberge actuellement l'instance FCI, la colonne État d'une adresse IP indique Hors connexion ou En ligne.  Figure 2 : Exemple dans le gestionnaire du cluster de basculement de la configuration de la dépendance OR pour des adresses IP existantes dans plusieurs sous-réseaux Modèle de quorum appropriéUn cluster de basculement multisite couvre généralement plusieurs régions géographiques et contient des composants de stockage au niveau de chaque site. Par conséquent, le modèle de quorum dans cet environnement doit donner lieu à des remarques spécifiques. Pour plus d'informations sur les éléments à prendre en considération dans ce cas spécifique, consultez « Modèle de quorum du cluster de basculement Windows Server (WSFC) » plus haut dans ce document. Toutefois, lorsque vous exécutez la validation de cluster Windows Server sur le cluster de basculement multisite, un message s'affiche, suggérant le modèle de quorum Nœud et disque majoritaires, comme l'illustre la figure 3.  Figure 3 : Affichage de la sortie de l'outil de validation de la configuration du quorum L'assistant dans l'outil de validation de cluster ne détecte pas si un cluster donné est un cluster multisite. Il est préférable d'ignorer cette recommandation et d'utiliser un modèle de quorum plus approprié, comme Nœud et partage de fichiers majoritaires. Inscription du réseau et connectivité client après le basculement d'une instance FCI SQL Server à plusieurs sous-réseauxDans SQL Server 2012, la propriété RegisterAllProvidersIP est activée pour la ressource Nom réseau (nom de réseau virtuel) du cluster de basculement SQL Server. Cette propriété de l'instance FCI à plusieurs sous-réseaux fait en sorte que toutes les adresses IP que SQL Server est configuré pour utiliser soient inscrites dans DNS avec le nom de réseau virtuel de SQL Server. Étant donné que toutes les adresses IP sont inscrites dans DNS, le basculement entre centres de données ne requiert aucune modification des adresses IP. La suppression de cette mise à jour DNS autorise une résolution plus rapide des connexions clientes sur le cluster de basculement SQL Server (nom de réseau virtuel), après un basculement. De nouveaux pilotes clients SQL Server, dont SQL Server Native Client, offrent la prise en charge du mot clé MultiSubnetFailover. Si le client peut activer l'option de connexion MultiSubnetFailover , toutes les adresses IP que l'instance FCI de SQL Server peut utiliser sont évaluées sur une connexion et résolues par le client. Cette fonctionnalité permet également d'améliorer la connectivité client après un basculement. Si le client n'utilise pas un pilote qui prend en charge le mot clé MultiSubnetFailover (ou s'il n'est pas activé), tenez compte des éléments suivants :
ConclusionSQL Server AlwaysOn 2012 fournit aux clients des choix de conception souples pour la haute disponibilité et la récupération d'urgence. Le clustering de basculement multisite offre une haute disponibilité et la récupération d'urgence au niveau de l'instance, en tant qu'option d'architecture, dans SQL Server AlwaysOn. Des améliorations importantes ont été apportées à la technologie de clustering de basculement multisite, offrant une option viable pour la haute disponibilité et la récupération d'urgence dans de nombreux environnements. L'objectif de ce document est d'aider les utilisateurs à se familiariser avec la technologie, à réussir son déploiement et à connaitre les améliorations apportées au clustering multisite avec SQL Server 2012. Pour plus d'informations et pour consulter les références mentionnées dans ce document :
Avez-vous trouvé ce document utile ? Nous apprécions vos commentaires. Sur une échelle de 1 (faible) à 5 (excellent), quelle note donneriez-vous à ce document ? Expliquez pourquoi. Par exemple :
Vos commentaires nous aident à améliorer la qualité des livres blancs que nous publions. Envoyez vos commentaires. AnnexeEnvironnement matériel et logiciel en laboratoireUn grand merci à nos partenaires pour nous avoir fourni les ressources matérielles et humaines nécessaires à ces tests de laboratoire. Serveurs
1 ordinateur Dell R805 comme client pour exécuter la charge de travail applicative SQL Server
Stockage
EMC et SQL Server : Solutions pour SQL Server et Business Intelligence (http://www.emc.com/solutions/application-environment/microsoft/solutions-for-sql-server-business-intelligence.htm) Microsoft SQL Server sur les systèmes de stockage EMC Symmetrix : (http://www.emc.com/collateral/software/solution-overview/h2203-ms-sql-svr-symm-ldv.pdf) Logiciel de stockage
EMC Symmetrix SRDF (http://www.emc.com/storage/symmetrix/srdf.htm) |
similaire:
 | | ||
| | «Framework php sous iis : Copix Framework» pour l’installation de sql server Express 2008 | |
 | | ||
| | «Polytech’Market» (esql create sql), le script de remplissage de cette base (esql add sql), le script de suppression de la base (esql... | |
| «Framework php sous iis : Copix Framework» pour l’installation de sql server Express 2008 | |