Installation d un groupe de disponibilité avec SQL Server 2012 AlwaysOn (CTP3) qsjdlkqjs

Transcription

1 Installation d un groupe de disponibilité avec SQL Server 2012 AlwaysOn (CTP3) qsjdlkqjs Article Technique Microsoft France - Septembre 2011 La prochaine version de SQL Server, SQL Server 2012, apporte de nombreuses nouvelles fonctionnalités, l'une d'entre elle étant la capacité à délivrer un service de haute disponibilité appelé "AlwaysOn". Derrière ce nom se cache le rapprochement de deux technologies existantes avec SQL Server 2008 R2 : Le cluster pour les solutions de haute disponibilité et le miroir de bases pour la réplication de données. Ces solutions, qui sont toujours disponibles avec SQL Server 2012, mais ne permettent pas d'exploiter le matériel de secours. AlwaysOn, solution qui vient en complément des autres technologies, apporte non seulement la capacité à répliquer les données entre plusieurs nœuds d'un même cluster potentiellement répartis sur plusieurs subnets mais aussi la possibilité de grouper plusieurs bases de données au sein d'un même objet qui maintiendra la cohésion du groupe lors d'une bascule. Pour permettre de tirer le meilleur partit des ressources utilisées par une telle architecture, Subtitle AlwaysOn permet aussi here d'accéder aux bases de données répliquées en lecture, par exemple pour pouvoir effectuer des backups ou des rapports. Dans ce document nous allons voir pas à pas comment mettre en œuvre un cluster AlwaysOn à deux nœuds. 1

2 Architecture, prérequis et création du cluster Windows Le but de cet article est de vous guider pas à pas dans la mise en œuvre d'un cluster HADR (ou AlwaysOn) sur une maquette. Vous pouvez adopter la même configuration ou l'adopter à votre environnement. Le minimum requis pour monter une infrastructure "Always On" est: Un domaine AD (sqldemo.com) qui est hébergé dans notre environnement sur le serveur SQL-DC. Deux serveurs classiques tournant sous Windows 2008 R2 : SQL-SRV-1 et SQL-SRV-2 qui seront utilisés pour créer le cluster HADR. Une baie de disque partagée ou une target iscsi n'est pas nécessaire pour installer un cluster SQL Server 2012 de type AlwaysOn. Nous reviendrons sur ce sujet dans la configuration du cluster. SQL-DC Mo SQL-SRV Go SQL-SRV Go La configuration mémoire des machines est suffisante pour monter une maquette et doit absolument être adaptée dans le cas d'une mise en production ou de la réalisation d'un prototype. Prérequis logiciel Les deux serveurs SQL-SRV-1 et SQL-SRV-2 indiqués ci-dessus doivent être membre du domaine sqldemo.com et respecter les prérequis nécessaire à l'installation de SQL Server 2012, à savoir : Windows Powershell 2.0 (installé par défaut avec Windows 2008 R2) Le Framework.Net 3.51 (via le Add Features de Windows 2008 R2) Windows Failover Clustering (via le Add Features de Windows 2008 R2) Dans le cadre de notre maquette les serveurs tournent avec Windows 2008 R2 x64 SP1 et sont à jour en termes de correctifs de sécurité mais Windows 2008 SP2 est aussi supporté. 2

3 Pour plus de détails sur les prérequis sur l'installation de SQL Server 2012, vous pouvez consulter la page suivante : Nous allons pouvoir créer le cluster Windows qui sera utilisé comme fondation pour la construction du cluster SQL AlwaysOn. Création du cluster Windows Comme nous avons installé la fonctionnalité "Failover Clustering" avec les pré-requis, nous pouvons lancer le "Failover Cluster Manager" dans la liste des outils d'administration. Il faut créer un cluster Windows : Sélectionnez les serveurs membre du domaine qui seront les différents nœuds du cluster SQL Server Donnez ensuite un nom à votre cluster et une adresse IP. Si les deux nœuds du cluster sont sur des subnets différents, il faudra donner une adresse IP par subnet. Il est aussi possible de laisser le cluster en client DHCP si votre configuration réseau le permet. 3

4 Vérifiez bien la configuration de votre cluster avant de valider la création du cluster. L'assistant se termine mais remonte une alerte à la fin indiquant que notre cluster n'est pas viable. Avec uniquement deux éléments pour voter en cas d'incident sur le cluster, il n'est pas possible d'atteindre une majorité de vote qui 4

5 permet de décider quel nœud prend la main. Nous allons voire dans le paragraphe suivant comment créer un cluster viable. Choix du modèle de quorum L'assistant de création du cluster a créé un cluster ou les seuls votant possibles sont les nœuds SQL-SRV-1 et SQL- SRV-2. Dans cette configuration, il n'est pas possible d'avoir une majorité de votant, au mieux chacun aura la moitié des votes et aucune décision ne pourra être prise quant à la possession du cluster. Il faut donc un troisième votant, c'est le modèle de quorum qui va nous permettre de choisir qui est ce troisième votant. Il est alors possible de choisir le modèle de quorum souhaité. : Dans le cas d'une configuration avec un disque partagé, l'option par défaut ("Node and Disk Majority") convient parfaitement, en plus des deux nœuds, l'accès en lecture / écriture sur le disque partagé donne le vote manquant. 5

6 Dans notre maquette, sans disque partagé, nous choisissons la troisième option : "Node and File Share Majority" (si vous avez pris l'initiative de monter un cluster à trois nœuds, restez avec le modèle "Node Majority"). Ce choix d'architecture présente les avantages suivants : Coûts réduits Adhérence limitée entre les serveurs et le matériel de stockage Facilité de mise en œuvre Capacité à supporter des clusters dispersés géographiquement Pour plus d'informations sur les modèles de quorum, vous pouvez consulter les articles suivant de la documentation : Il reste à indiquer le partage de fichier qui servira de témoin pour le cluster. Pour notre maquette, j'ai créé un partage (FSW) sur le contrôleur de domaine (SQL-DC). Attention : Penser à donner les droits d'écriture sur le répertoire qui sera partagé pour les nœuds membres du cluster. Dans le cas d'une maquette, vous pouvez simplifier l'opération en utilisant le groupe "Domain Computers". 6

7 Le cluster que nous venons de créer et configurer ne possède aucune ressource ni services, il peut être comparé à une coquille vide qui servira de base à l'installation de SQL Server 2012 en mode HADR. Nous allons pouvoir procéder à l'installation de SQL Server 2012 à proprement parler. Installation de SQL Server sur chaque nœud Une fois le cluster Windows configuré et vérifié, nous allons procéder à l'installation des binaires de SQL Server. Cette opération doit être effectuée sur tous les serveurs qui seront membres du cluster AlwaysOn. Dans notre cas, il s'agit des serveurs SQL-SRV-1 et SQL-SRV-2. L'installation ci-dessous a été effectuée avec la CTP 3 de SQL Server 2012, les captures d'écran peuvent évoluer avec les prochaines versions du produit. Passons directement dans le deuxième onglet "Installation" pour lancer le setup. Attention: Notez que c'est la première option qui est choisie! L'installation d'un cluster SQL en mode HADR nécessite une installation en mode standalone et non en mode cluster. La deuxième option consiste à installer un cluster à bascule classique avec une base de données sur une baie de disque partagée. L'assistant d'installation vérifie si les prérequis à l'installation de SQL Server 2012 sont remplis. Avec la CTP3, vous n'avez pas besoin de clef de produit, choisissez l'option "Evaluation". 7

8 Acceptez le contrat de licence puis laissez le système chercher les mises à jour sur Internet. Si vous avez accès à Internet, le système téléchargera les mises à jour automatiquement pendant le processus d'installation. 8

9 Si vous n'avez pas accès à Internet, il faudra: 1. Télécharger la mise à jour depuis le catalogue Microsoft Update (KB ) : 2. Relancer le setup de SQL Server 2012 en précisant le répertoire où trouver les mises à jour avec le paramètre /UpdateSource=<repertoire_updates>. Vous trouverez plus d'informations sur le lancement de dans ces deux articles : Nous pouvons continuer l'installation du setup de SQL : Notez l'alerte concernant la présence du parefeu. Pensez à le reconfigurer en accord avec les recommandations indiquées : 9

10 Nous pouvons maintenant passer à l'installation de SQL à proprement parler. L'option à sélectionner est "SQL Server Feature Installation". Dans le cas de notre maquette, nous allons choisir d'installer seulement les fonctionnalités nécessaires pour démontrer la fonctionnalité HADR de SQL, à savoir : Le moteur de base de données : Database Engine Services Les outils d'administration : Management Tools Pour le troubleshooting : Client Tools Connectivity La sélection de fonctionnalités donne donc le résultat suivant : 10

11 Passez sur l'écran "Installation Rules" pour aller sur l'écran de configuration de l'instance : Pour des raisons de simplicité de compréhension, j'ai choisi d'utiliser des instances nommées : DENALI1 sur SQL-SRV-1 DENALI2 sur SQL-SRV-2 Vous pouvez utiliser l'instance par défaut si vous le souhaitez mais cela peut rendre l'analyse en cas de problème plus compliquée. Vérifiez que votre serveur possède assez d'espace disque : 11

12 Indiquez ensuite les comptes de service à utiliser. Dans le but de simplifier la mise en œuvre de cette maquette, nous allons utiliser un compte de service du domaine pour faire tourner le service serveur de SQL Server L'utilisation d'un compte du domaine sera utile lors de la création avec l'assistant du groupe de disponibilité (Availability Group) permettant la mise en haute disponibilité d'un groupement de bases. Vous trouverez quelques informations supplémentaires sur ce sujet dans le paragraphe "Using the New Availability Group Wizard" sur cette page : Pour des raisons de compréhension, j'ai utilisé un compte de service différent pour chaque nœud du cluster. Lors de la configuration du moteur de base de données, pensez à bien ajouter votre compte comme administrateur. 12

13 Validez les étapes suivantes de la procédure d'installation jusqu'à la page "Ready to Install" : En bas de la fenêtre le fichier.ini indiqué est un fichier qui contient une copie de la configuration établie avec l'assistant. Il est possible de réutiliser ce fichier dans une autre installation de SQL Server Par exemple pour l'installation du second nœud de notre cluster. Une fois l'installation terminée, voici le résultat obtenu : 13

14 Il faut suivre la même procédure pour configurer SQL-SVR-2 ou plus généralement tout nœud qui ferait partie du cluster. Pour le moment, nous avons simplement installé SQL en mode autonome sur un serveur qui est membre d'un cluster Windows à bascule (Windows Failover Cluster). Il faut maintenant configurer cette instance pour qu'elle supporte les groupes de disponibilité de type AlwaysOn. Lancer "SQL Server Configuration Manager" Aller dans les propriétés du service "SQL Server (NOM_INSTANCE)" et cocher la case "Enable AlwaysOn Availability Group" Les changements effectués ne seront pris en compte qu'une fois le service redémarré. 14

15 Vous pouvez vérifier si la configuration a bien été prise en compte en interrogeant la propriété SERVERPROPERTY en Transact-SQL: Pour plus d'informations sur ce point, vous pouvez consulter l'article suivant de la documentation en ligne : Il est maintenant possible de créer un groupe de disponibilité et d'y monter une ou plusieurs bases de données. Création du Groupe de Disponibilité (Availability Group) Qu'est-ce qu'un «Availability Group»? Comme nous l'avons vu en introduction, l'availability Group permet de répondre aux besoins suivants : La solution permet d'assurer une bascule simultanée de toutes les bases de données du groupe en cas d'incident. Cette approche permet de répondre aux besoins de disponibilité des applications qui accèdent à plusieurs bases de données en même temps sans avoir à mettre en œuvre des contournements complexes. Répliquer les données sur plusieurs instances (le maximum étant 5 copies au total) tout en permettant aux applications d'y accéder via un nom virtuel unique sans avoir besoin de solution de réplication matérielle. Accéder aux copies répliquées en mode lecture seule pour permettre de décharger l'instance principale de la charge générée par exemple par les sauvegardes ou les rapports. Solution de cluster dispersé géographiquement purement à base de logiciel. Cette solution de disponibilité peut être vue comme une combinaison des bons côtés du mirroring et du cluster à bascule que nous connaissions avec SQL 2008 R2. Avant de créer à proprement parler le groupe de disponibilité, il faut monter une base de données sur l'un des deux serveurs SQL. Prenons par exemple la base de données d'exemple AdventureWorks disponible en téléchargement pour SQL Server 2012 à cette adresse : La procédure pour remonter les bases de données est disponible à cette adresse : Création du Groupe de Disponibilité La création et configuration de l'availability Group se fait dans SSMS (SQL Server Management Studio). Si la fonctionnalité a bien été activée comme indiquée à l'étape précédente, le conteneur "Availability Group" apparait dans SSMS sous le conteneur "Management". 15

16 Il est possible de lancer l'assistant de création d'un Availability Group (AG). Donnez un nom au groupe de disponibilité, par exemple, dans notre cas : AdventureWorksAG et cliquez sur Suivant. Il est alors possible de choisir la ou les bases de données qui feront partie de l'availability Group que nous sommes en train de créer. Si vous choisissez plusieurs bases de données, toutes ces bases basculeront en même temps. Pour notre maquette, nous choisirons uniquement la base "AdventureWorksDW". Vérifiez que le status indique bien "Meets prerequisites". 16

17 Indiquez ensuite les instances SQL qui ont été activée pour supporter AlwaysOn qui possèderont une copie de la base de données. Par défaut l'instance sur laquelle SSMS est connecté est ajouté à la liste des réplicas. Ajoutez le server SQL-SRV-2 à la liste des réplicas possibles de la base AdventureWorksDW. Note: Il faut démarrer le service "SQL Server Browser" si ce n'est déjà fait et mettre le service en démarrage automatique pour le bon fonctionnement du cluster HADR. 17

18 Il est possible de modifier le mode du réplica pour passer du mode 'Automatic failover' (mode proposé par défaut) aux modes 'High performance' (commit asynchrone et bascule forcée avec potentielle perte de données) ou 'High safety' (bascule manuelle seulement). Nous laisserons le mode 'Automatic failover'. Le 'Connection Mode in Secondary role' est plus intéressant. C'est ce paramètre qui autorise ou non les connexions sur la copie de la base de données. Par exemple si vous avez une application de génération de rapport, vous pouvez décharger l'instance primaire, utiliser ses ressources pour servir au mieux les clients et utiliser les ressources de l'instance secondaire pour servir les fonctionnalités de reporting. Les modes autorisés sont : Disallow connections : Aucune connexion n'est autorisée sur l'instance si elle est en mode secondaire. Par exemple, dans le cas où la latence de réplication n'est pas permise. Allow only read-intent connections : Seulement les applications qui indiquent dans la chaine de connexion le mode 'read-intent' pourront se connecter à cette instance en mode secondaire. Allow all connections : Toute application peut se connecter à l'instance, peu importe la chaine de connexion mais seulement des opérations de lecture seront possibles sur la base. Pour les besoins de notre maquette nous allons prendre le dernier mode : "Allow all connections". Dans l'étape suivant nous allons renseigner le nom réseau du Groupe de Disponibilité. C'est ce nom virtuel qui sera utilisé ensuite par les clients pour se connecter à la(les) base(s) du groupe. Ce nom est appelé un Listener. Vous pouvez choisir l'option client DHCP dans le cas où vous avez un serveur DHCP sur le réseau. Cette option est particulièrement intéressante dans le cas de cluster répartit sur plusieurs subnets. Lors de la bascule d'un nœud à l'autre, le cluster prendra une IP du subnet où il se trouve. Dans le cas où vous voudriez ajouter une IP manuellement, sélectionnez l'option "Skip". Vous ajouterez un Listener manuellement depuis SQL Server Management Studio (SSMS) une fois le groupe de disponibilité créé. Il est aussi possible lors de cette étape de changer le port d'écoute. Pour notre maquette, nous laisserons le port par défaut. 18

19 Pour le moment la base de données est sur le serveur SQL-SRV-1. La mise en œuvre du Groupe de Disponibilité autorise plusieurs modes pour la copie initiale des données vers SQL-SRV-2 : SQL Server 2012 effectue la synchronisation initiale des données avec une mécanique de sauvegarde / restauration automatisé. Cette opération nécessite l'utilisation d'un partage sur le réseau et peut ne pas être appropriée dans le cas de manipulations de gros volumes de données. Pour les scénarios manipulant des gros volumes de données ou dans le cas où une copie existe déjà sur la ou les instances cible, le système laisse la main au DBA pour mettre les copies en place. Dans ce cas, le système ne procède pas à la synchronisation initiale. Dans le cas de notre maquette, pour des raisons de simplicité, nous allons choisir la première option. Le partage peut être sur n'importe quel serveur sur le réseau mais il faut qu'il soit accessible par tous les nœuds du cluster pour pouvoir procéder à la restauration des données. 19

20 La configuration du groupe de disponibilité est maintenant terminée. Laissez l'assistant vérifier que tout est bon. Si vous souhaitez scripter cette opération, vous pouvez obtenir le script au moment du résumé. Et le résultat de l'opération : 20

21 Il reste à vérifier que notre cluster fonctionne! Test et validation du fonctionnement d'un Groupe de Disponibilité AlwaysOn Une fois que nous avons fini de construire notre cluster SQL Server 2012 AlwaysOn, dans le cadre de notre maquette, nous allons vérifier son bon fonctionnement. Commençons par faire un état des lieux au niveau du dashboard du groupe de disponibilité dans SSMS. Voici ce que nous voyons sur l'instance qui possède le groupe de disponibilité : 21

22 Le serveur SQL-SRV-1 est bien indiqué comme "primary", et SQL-SRV-2 est bien indiqué comme "Readable Secondary". Les deux copies sont dans l'état "Synchronized". Si on regarde le même tableau de bord en étant connecté sur SQL-SRV-2, voici ce que l'on obtient. Ce premier indicateur est rassurant concernant l'état de santé de notre groupe de disponibilité. Si vous préférez obtenir des informations concernant l'état de santé du groupe de disponibilité, vous pouvez utiliser un script T-SQL disponible à cette adresse : Regardons maintenant si le groupe de disponibilité bascule correctement. Deux options sont possibles avec la CTP3 de SQL Server 2012: 22

23 Powershell Transact-SQL Dans les deux cas, il faut se connecter sur le nœud cible, c est-à-dire celui qui va recevoir le groupe. En Transact-SQL la commande est assez simple : ALTER AVAILABILITY GROUP AdventureWorksAG FAILOVER; Vérifiez sur le tableau de bord que le group est bien pris en main par SQL-SRV-2. Le rafraichissement du dashboard peut prendre quelques instants alors que la bascule a déjà été effectuée. Vous pouvez faire revenir le groupe sur le serveur SQL-SRV-1 avec une commande en Powershell. Pour cela, lancez Powershell depuis SSMS sur SQL-SRV-1 comme ci-dessous. Saisissez ensuite la commande suivante : Switch-SqlAvailabilityGroup Path SQLSERVER:\SQL\SQL-SRV- 2\DENALI2\AvailabilityGroups\AdventureWorksAG Vous trouverez plus d'informations sur les bascules manuelles dans cette page de la documentation en ligne : Le dernier point à vérifier est que les clients se connectent bien à la base pendant ces opérations. Pour cela, j'utilise un client qui insère des lignes aléatoires dans une des tables de la base de données. Pour le premier test la chaine de connexion pointe sur SQL-SRV-1\DENALI1, c'est l'instance qui héberge le groupe de disponibilité que nous venons de créer. Si je bascule le groupe vers le deuxième nœud du cluster, l'application va passer en echec comme l'indique la capture d'écran ci-dessous. 23

24 Si maintenant, je change la chaine de connexion pour utiliser le nom du listener du groupe de disponibilité, à savoir AdventureWorksAG_Listener, l'application cliente se connecter bien sur l'instance qui héberge le groupe de disponibilité : L'application continue à fonctionner avec une nouvelle chaine de connexion sans avoir besoin d'être reconfigurée et bénéficie des fonctionnalités "AlwaysOn" de SQL Server Une application de reporting indiquant un accès de type "ReadOnly" pourrait se connecter sur le nom virtuel du groupe et serait redirigé vers le nœud secondaire et afin d'exploiter au mieux les ressources du cluster. 24

25 Conclusion A travers cet article, nous avons mis en œuvre dans le cadre d'une maquette une base de données AlwaysOn en suivant les étapes suivantes : Création du cluster Windows et choix du quorum utilisé Installation de SQL Server 2012 sur chacun des nœuds Activation de la fonctionnalité AlwaysOn sur les instances SQL faisant partie du cluster Création et configuration d'un groupe de disponibilité Vérification du bon fonctionnement du cluster et des clients en cas de bascule Les étapes décrites ci-dessus permettent de mettre en œuvre un cluster à des fins de test ou d'apprentissage. Dans le cadre d'une mise en production, il est nécessaire de réfléchir à l'architecture des systèmes mis en place, de la charge que le système devra supporter, du nombre de copies secondaires nécessaires, etc Si vous souhaitez en savoir plus sur SQL Server 2012, vous pouvez consulter les documents de référence : Les livres en ligne : Le guide produit : Le site technique sur SQL en Français : 25