Redgate Hub

L’une des fonctionnalités les plus connues de la version de SQL Server 2012 Enterprise Edition est AlwaysOn. Celle-ci a été conçue pour répondre au besoin toujours croissant de  » haute disponibilité  » (HA). AlwaysOn n’utilise pas de technologies entièrement nouvelles, mais fait un usage plus efficace des technologies existantes qui ont fait leurs preuves. Il vise à fournir un contrôle plus granulaire pour atteindre la haute disponibilité. Actuellement, en fonction de votre environnement, vous pourriez déjà utiliser un ou plusieurs des composants HA suivants qui existaient dans les versions précédentes de SQL Server :

• Single Site Windows Server Failover Clustering
• Multi-Site Windows Server Failover Clustering
• San level Block Replication
• Transaction Log Shipping
• Database Mirroring
• Transactional Replication
• Peer-to-Peer Replication

Certaines d’entre elles peuvent prendre du temps et des ressources à mettre en œuvre, et peuvent donc ne pas répondre à vos besoins actuels. C’est là que SQL Server 2012 AlwaysOn peut vous aider, car il offre les avantages suivants :

• Utilisation des API WSFC pour effectuer des basculements. Le stockage partagé n’est pas nécessaire
• Utilisant la mise en miroir des bases de données pour le transfert des données sur TCP/IP
• fournissant une combinaison de mise en miroir synchrone et asynchrone
• fournissant un regroupement logique de bases de données similaires. via des groupes de disponibilité
• Créer jusqu’à quatre répliques secondaires lisibles
• permettre d’entreprendre des sauvegardes sur une réplique secondaire
• Exécuter des instructions DBCC contre une réplique secondaire
• Mettre en œuvre une compression intégrée.in Compression & Chiffrement

Nous devrons expliquer certains de ces composants de AlwaysOn

Windows Server Failover Clustering (WSFC)

La technologie de clustering existe depuis un certain temps, en commençant par Microsoft Clustering Services (MCS) à l’époque de NT 4.0 jours… La technologie du WSFC fait partie de l’épine dorsale d’AlwaysOn. Un cluster WSFC est un groupe de serveurs indépendants qui travaillent ensemble pour augmenter la disponibilité des applications et des services. Pour ce faire, il surveille la santé du nœud actif et bascule sur un nœud de secours, avec transfert automatique de la propriété des ressources, lorsque des problèmes sont détectés.

Bien que le WSFC soit capable de s’étendre sur plusieurs sous-réseaux, un serveur SQL qui tient compte des clusters n’était pas, jusqu’à présent, capable de prendre en charge une instance en cluster de SQL Server sur plusieurs sous-réseaux : La mise en place d’un clustering sur plusieurs centres de données a donc été assez coûteuse, car le WSFC nécessite un stockage partagé dans les deux centres de données, ainsi que la réplication SAN au niveau des blocs. Cela a nécessité beaucoup de travail avec vos fournisseurs de stockage pour obtenir une configuration correcte.

Database Mirroring

La mise en miroir des bases de données vous donne la possibilité de synchroniser entièrement les bases de données d’une instance de SQL Server à une autre, que la deuxième instance soit située sur le même serveur, sur un serveur différent dans le même centre de données ou sur un serveur dans un autre centre de données. Elle peut ensuite changer de rôle avec la base de données miroir lors du basculement. L’un des problèmes de la mise en miroir de bases de données est qu’elle ne peut pas assurer le basculement automatique d’un groupe de bases de données liées entre elles. Si vous avez plusieurs bases de données résidant dans une instance de SQL Server et que l’une de ces bases de données est basculée sur le site secondaire via votre configuration de mise en miroir de bases de données, cette base de données peut également dépendre d’une ou plusieurs autres bases de données de l’instance. Dans ce cas, votre application peut ne pas fonctionner correctement. Un autre inconvénient est que la base de données mise en miroir n’est pas accessible. Vous pouvez contourner ce problème en utilisant des instantanés de base de données pour vous donner une copie en  » lecture seule « .

Nœuds AlwaysOn

Les nœuds que vous utiliserez dans votre solution SQL Server 2012 AlwaysOn doivent faire partie d’un WSFC. La première étape que nous devons entreprendre pour préparer nos nœuds AlwaysOn est d’ajouter la fonctionnalité Failover Cluster à chaque nœud. J’entrerai dans les détails plus loin dans cet article.

Stockage AlwaysOn

Les versions de SQL Server antérieures à SQL Server 2012, étant configurées en tant qu’instance en cluster sur un WSFC nécessitent que le stockage soit présenté comme un stockage partagé. Cette exigence conduit à ce que le stockage soit plus cher et un peu plus compliqué à configurer et à administrer. Avec SQL Server 2012 AlwaysOn, votre solution ne doit pas nécessairement utiliser un stockage partagé, mais peut utiliser un SAN, un DAS, un NAS ou un disque local en fonction de votre budget et de vos besoins. Je suggère de travailler avec vos fournisseurs de stockage pour trouver la solution dont vous avez besoin.

Synchronous & Mirroring asynchrone

AlwaysOn utilise la technologie de mirroring existante de SQL Server. La mise en miroir synchrone, comme son nom l’indique, exige que les transactions soient écrites sur les deux sites pour que la transaction soit terminée. Bien que cela puisse entraîner une augmentation de la latence dans votre système, cela vous permet de ne pas perdre de données. AlwaysOn prend en charge jusqu’à deux répliques secondaires répliquées de manière synchrone par groupe de disponibilité. La mise en miroir asynchrone, quant à elle, est plus rapide mais augmente le risque de perte de données car elle n’a pas l’obligation de terminer la transaction sur le site secondaire. L’un des avantages d’AlwaysOn par rapport à la mise en miroir est qu’il permet d’utiliser plusieurs sites secondaires de la base de données. Un autre avantage est la possibilité d’avoir une combinaison de & Mirroring asynchrone dans votre configuration afin d’atteindre le meilleur compromis entre performance et fiabilité. En fonction de vos exigences HA/DR, vous pourriez éventuellement avoir une configuration synchrone vers un serveur dans votre centre de données local et une configuration asynchrone vers un serveur dans un centre de données secondaire.

Groupes de disponibilité

SQL Server 2012 AlwaysOn permet un contrôle plus granulaire de votre environnement avec l’introduction des groupes de disponibilité AlwaysOn (AAG). Les AAG vous permettent de configurer des groupes de bases de données que vous souhaitez faire basculer tous ensemble en cas de problème avec le serveur hôte. Lorsque vous configurez vos AAG, vous :

• Configurer votre AAG sur la réplique primaire (Votre AAG contient le groupe de BD que vous souhaitez regrouper pour basculer vers vos répliques secondaires)
• Vous devrez configurer entre une et quatre répliques secondaires, avec n’importe quelle combinaison de mise en miroir synchrone (maximum de deux) et asynchrone (Votre réplique primaire est disponible pour la connectivité en lecture et en écriture, tandis que vos répliques secondaires peuvent être configurées pour la lecture seule, l’intention de lecture ou aucun accès)

Des informations plus approfondies sur les groupes de disponibilité sont abordées plus loin.

Tâches de maintenance/ rapports

AlwaysOnvous permet d’utiliser les répliques secondaires que vous auriez créées lors de la configuration de vos AAG pour entreprendre certaines tâches régulières de maintenance de la base de données afin de supprimer certaines des surcharges de performance de votre serveur de production primaire. Certaines des tâches que vous pourriez envisager d’entreprendre sur une réplique secondaire sont :

• Sauvegardes de la base de données
  • Sauvegarde complète avec Copy_Only
  • Sauvegardes du journal des transactions
• Vérification de la base de données parDBCC

.

• Reporting
• Database Snapshots

Licensing

SQL Server 2012 a été publié avec un nouveau modèle de licence. Avec la capacité de SQL Server 2012 AlwaysOn à avoir plusieurs secondaires, vous devez prendre en compte la licence lorsque vous allez mettre en œuvre plusieurs secondaires. Le modèle de licence exige que vous accordiez une licence à votre serveur SQL actif (primaire) dans votre cluster AlwaysOn. Vous avez droit à un serveur passif (secondaire) pour lequel vous n’avez pas besoin de licence. Si vous avez plus d’un serveur secondaire, vous devez obtenir une licence pour chaque serveur, qu’il soit actif ou passif. Pour plus d’informations sur les licences, consultez le Guide de référence des licences SQL Server 2012 et parlez-en à votre revendeur de licences.

Qu’est-ce qui est actif et qu’est-ce qui est passif ? Votre primaire est actif car vous y accédez et utilisez la base de données. Si vous configurez un serveur secondaire pour effectuer l’une des tâches énumérées ci-dessus dans Tâches de maintenance/rapports, alors ce secondaire est également actif et doit être licencié. N’oubliez pas : si vous y accédez, il est actif. Par exemple : Si nous devions avoir un serveur primaire (actif), trois serveurs secondaires (un actif, deux passifs), nous devrions obtenir une licence pour trois des quatre serveurs.

Sécurité & Performances

Pour vous donner tous les avantages de la haute disponibilité, il y aura beaucoup de mouvements de données. Cela entraîne des risques de sécurité et des demandes de bande passante plus élevées. Pour minimiser ces exigences, le cryptage transparent des bases de données (TDE) ainsi que la compression des sauvegardes, sont tous deux livrés avec l’édition Enterprise,

Mise en œuvre d’AlwaysOn

Maintenant que nous avons couvert au large les bases de ce à quoi une solution AlwaysOn pourrait éventuellement ressembler, nous sommes prêts à commencer et à planifier la mise en œuvre de cette solution pour répondre à vos exigences de haute disponibilité et à vos besoins de DR toujours plus importants.

Votre solution finale pourrait ressembler à quelque chose comme ceci :

Image 1 – Solution AlwaysOn SQL Server 2012

Construction de votre cluster AlwaysOn

Dans ce scénario, nous allons construire un cluster AlwaysOn SQL Server 2012 à deux nœuds. Pour cela, tous les nœuds qui vont participer au cluster SQL Server AlwaysOn doivent avoir .NET Framework 3.5.1 et la fonctionnalité Failover Clustering activée.

Image 2 – Fonctionnalités requises

Maintenant que nous avons activé ces deux fonctionnalités, nous pouvons construire notre WSFC. Depuis le Panneau de configuration | Outils d’administration | Gestionnaire de cluster de basculement | Valider une configuration, nous pouvons valider si nos serveurs sont d’accord pour participer à un WSFC.

Image 3 – Valider le cluster

L’assistant ‘Valider une configuration de cluster’ va démarrer. Cliquez dans cet assistant et il vous sera demandé quels tests vous souhaitez exécuter. J’ai sélectionné tous les tests pour cette validation. Vous devrez ajouter tous les nœuds que vous allez ajouter à votre WSFC.

Image 4 – Nœuds du cluster

À la fin de la validation, dans la mesure où tout a passé, vous devriez obtenir la notification suivante :

Image 5 – Succès de la validation du cluster

Construction de votre cluster Windows Server Failover

Il n’y a aucune différence entre la tâche de construction de votre WSFC à utiliser avec SQL Server 2012 AlwaysOn et votre WSFC précédemment construit pour SQL Server 2008 R2. Si vous n’avez jamais construit un WSFC auparavant, vous pouvez en savoir plus à ce sujet ici Guide étape par étape du cluster de basculement. Dans cet article, je ne vais pas passer en revue la construction du WSFC, mais je dois mentionner que votre construction WSFC doit passer toutes les règles de validation afin de vous donner un WSFC supporté.

SQL Server 2012 Setup

Maintenant que nous avons nos deux nœuds dans notre WSFC, nous sommes prêts à commencer le processus de construction de notre cluster SQL Server 2012 AlwaysOn. Nous devons nous assurer que nous avons notre support d’installation qui peut être téléchargé à partir de Microsoft SQL Server 2012 Downloads.

Sur Node1, nous lançons le setup.exe pour commencer le processus d’installation. Nous sommes accueillis par l’écran initial. Vous devez naviguer vers l’onglet Installation pour démarrer l’installation, en sélectionnant ‘Nouvelle installation autonome de SQL Server ou ajout de fonctionnalités à une installation existante’.

Image 6 – Installation autonome

Les règles d’installation devraient toutes se terminer avec succès et vous pouvez alors cliquer sur ‘OK’ pour continuer. Une fois que votre analyse de mise à jour du produit est terminée, cliquez sur ‘Suivant’.

Suivez les invites jusqu’à ce que vous arriviez à l’écran Type d’installation, assurez-vous de sélectionner ‘Effectuer une nouvelle installation de SQL Server 2012’, cliquez sur ‘Suivant’.

Image 7 – Nouvelle installation

Entrez votre clé de produit, cliquez sur ‘Suivant’.

Image 8 – Clé de produit

Acceptez les conditions générales, cliquez sur ‘Suivant’.

Veillez à sélectionner ‘Installation des fonctionnalités de SQL Server’, cliquez sur ‘Suivant’.

Image 9 – Installation des fonctionnalités de SQL Server

Choisissez les fonctionnalités que vous devez installer, cliquez sur ‘Next’.

Image 10 – Fonctionnalités du serveur SQL

Vos règles d’installation seront vérifiées et, tant qu’il n’y a pas de problème, vous pouvez poursuivre l’installation en cliquant sur ‘Suivant’.

Entrez votre nom d’instance SQL Server 2012 pour l’instance que vous construisez, cliquez sur ‘Next’.

Image 11 – Nom d’instance

Normalement, je recommanderais d’avoir des comptes de service différents pour chacun des services SQL que vous installez. Cependant, dans cette installation, je n’utilise que les comptes locaux par défaut. Vous devrez avoir vos comptes de service de domaine créés et définir les mots de passe sur cet écran de configuration du serveur dans l’installation. Une fois que vous avez défini les mots de passe, assurez-vous de cliquer sur l’onglet Collation afin de configurer votre Collation pour l’Instance, cliquez sur ‘Next’.

Image 12 – Détails du compte de service

Sur l’écran de configuration du moteur de base de données, il y a trois onglets auxquels nous devons prêter attention. L’onglet Configuration du serveur est l’endroit où vous définissez votre mode de sécurité – Soit Windows (recommandé), soit le mode mixte. N’oubliez pas d’ajouter le compte actuel sous lequel vous exécutez l’installation, ainsi que toute autre personne ou groupe qui doit être membre du groupe SysAdmins.

Image 13 – Détails de la configuration du serveur

L’onglet Répertoires de données vous permet de spécifier où vous voulez que vos bases de données utilisateur, TempDB et les emplacements de sauvegarde soient stockés. Traditionnellement, vous auriez quatre emplacements de lecteur distincts en fonction de votre stockage pour les fichiers de données, les fichiers journaux, TempDB et les sauvegardes.

L’onglet FileStream vous permet d’activer Filestream si c’est une option requise dont vous avez besoin dans votre environnement. Cliquez sur ce lien pour plus de lecture sur FileStream.

Cliquez sur ‘Suivant’ jusqu’à ce que vous arriviez à l’écran ‘Prêt à installer’. À ce moment-là, vous devez passer en revue ce qui va être installé et, si vous êtes satisfait, alors Cliquez sur le bouton Installer.

Image 14 – Prêt à installer

Rappellez-vous que ces mêmes étapes doivent être effectuées sur le deuxième nœud que vous incluez dans votre cluster AlwaysOn SQL Server 2012.

Configuration de SQL Server 2012

Maintenant que nous avons installé deux instances autonomes de SQL Server 2012 sur nos deux serveurs dans le WSFC, nous devons entreprendre une certaine configuration post-installation. Ceci est réalisé en utilisant le gestionnaire de configuration du serveur SQL qui est disponible à partir de Démarrer | Tous les programmes | Microsoft SQL Server 2012 | Outils de configuration.

Comme les transferts de données par SQL Server 2012 AlwaysOn sont effectués via TCP/IP, nous devons l’activer dans les protocoles de configuration du réseau. Par défaut, cette option sera désactivée. Changez la valeur en Activé et cliquez sur ‘OK’.

Nous sommes maintenant au point principal avec la configuration de notre Cluster SQL Server 2012 AlwaysOn. Auparavant, nous créions une instance de SQL Server en cluster et nous devions entreprendre l’option de construction en cluster. Vous aurez remarqué que nous avons installé des instances autonomes de SQL Server sur chacun des nœuds participant au WSFC. Nous devons activer les groupes de disponibilité AlwaysOn. Dans le ‘SQL Server Configuration Manager’, sélectionnez l’instance de SQL Server, faites un clic droit, sélectionnez Propriétés. Dans l’onglet ‘Haute disponibilité AlwaysOn’, cochez la case ‘Activer les groupes de disponibilité AlwaysOn’.

Cliquez sur ‘OK’. Les modifications ne prendront effet que lorsque l’Instance sera redémarrée. Vous devrez répéter cette étape sur la deuxième instance que nous avons installée. (Cela devra être fait sur chaque instance de votre cluster AlwaysOn SQL Server 2012)

Image 15 – Activer les groupes de disponibilité AlwaysOn

Nous sommes maintenant prêts à commencer à configurer nos groupes de disponibilité.

Configuration des groupes de disponibilité AlwaysOn de SQL Server 2012

Avant SQL Server 2012, l’une des options disponibles que vous pouviez utiliser pour construire votre solution de haute disponibilité (HA) était d’utiliser la mise en miroir de bases de données. La technologie Database Mirroring est très bonne dans ce pour quoi elle a été créée. Cependant, elle présente certaines limites lorsqu’il s’agit de votre solution HA. Ces limites comprennent :

• Une seule base de données secondaire
• La base de données miroir est accessible via db snapshot uniquement jusqu’à ce que le basculement se produise
• Non prise en charge de MSDTC (transactions distribuées)
• Les bases de données apparentées ne peuvent pas être regroupées

Les AAG de SQL Server 2012 résolvent la plupart de ces problèmes en vous donnant plus de flexibilité sur votre environnement et un contrôle plus granulaire sur votre environnement pour répondre à vos exigences complexes toujours croissantes en matière de HA.

Avec la mise en œuvre des AAG de SQL Server 2012, qui utilise toujours la technologie Database Mirroring pour transférer vos données via TCP/IP de manière synchrone ou asynchrone vers une ou plusieurs répliques mais en vous donnant l’avantage supplémentaire de pouvoir accéder à ces répliques. Elle ne prend toujours pas en charge la cohérence transactionnelle pour les bases de données participant à un groupe de disponibilité.

Groupes de disponibilité

Comme son nom l’indique, un groupe de disponibilité est un regroupement de bases de données liées. Lorsque vous configuriez la mise en miroir de bases de données Avant SQL Server 2012, vous pouviez configurer plusieurs miroirs, mais vous ne pouviez configurer la mise en miroir que d’une seule base de données à la fois. Si vous avez plusieurs bases de données qui dépendent les unes des autres pour que l’application fonctionne, il n’y a pas de moyen simple de garantir que toutes les bases de données basculent ensemble. Les groupes de disponibilité vous permettent désormais de regrouper les bases de données appropriées. Vous pouvez configurer jusqu’à 10 groupes de disponibilité au niveau de chaque instance. A travers ces 10 groupes de disponibilité, vous pouvez avoir jusqu’à 100 bases de données répliques participantes.

Les avantages donnés par un groupe de disponibilité sont qu’il :

• Prise en charge des modes de disponibilité alternatifs
• Prise en charge de plusieurs formes de basculement AAG
• Prise en charge la configuration des répliques secondaires en mode lecture-.Only Mode
• Supports de la configuration des répliques secondaires pour effectuer des sauvegardes
• Supports de la réparation automatique des pages
• Supports du cryptage et de la compression
• Supports de la gestion via
  • TSQL
  • PowerShell
  • GUI Wizards

  .

  • Dashboard
  • Management Studio

Un basculement rapide de l’application grâce à l’utilisation de AlwaysOn Availability Group Listeners (AAGLs)

Répliques de disponibilité

Les répliques de disponibilité vous offrent la possibilité de configurer :

• Une réplique primaire qui vous permet d’entreprendre des capacités de lecture et d’écriture contre les bases de données qui ont été configurées dans l’AAG
• Jusqu’à quatre répliques secondaires qui vous permettent d’avoir des capacités de lecture seule contre les bases de données qui ont été configurées dans l’AAG. Vous permet également de configurer la capacité d’effectuer des sauvegardes sur ces secondaires.

Modes de disponibilité

Comme mentionné ci-dessus, lors de la configuration de vos groupes de disponibilité AlwaysOn SQL Server 2012, il y a quelques considérations à prendre en compte pour déterminer le type de mode de disponibilité que vous pouvez utiliser.

Si vous souhaitez utiliser les AAG pour un processus de reporting, vous pourriez avoir votre réplique secondaire située dans le même centre de données physique et mettre en œuvre le mode synchronous-commit pour vous donner un groupe de bases de données en lecture seule à proximité du temps pour générer des rapports sans impacter les performances des bases de données primaires avec des frais généraux de reporting. Vous n’envisageriez probablement pas ce type de mode de disponibilité lorsqu’il y a de grandes distances entre les centres de données.

Si vous avez l’exigence d’un processus de reporting, qui n’exige pas que les données soient en temps quasi réel, vous pourriez envisager de mettre en œuvre votre réplique dans un centre de données distinct qui peut se trouver à plus de 30-40 Kilomètres. Si c’est le cas, vous devriez envisager de mettre en œuvre des commandes asynchrones pour votre AAG. En mettant en œuvre une méthode asynchrone-commit, vous réduiriez la latence des transactions sur le site primaire, mais cela vous ouvrirait à la possibilité d’une perte de données.

Comme vous pouvez configurer plusieurs répliques, vous êtes en mesure de configurer différents modes de disponibilité dans votre environnement. Chaque AAG est configuré séparément ; par exemple : vous pouvez avoir deux implémentations synchrones et deux implémentations asynchrones.

Dans cet exemple, vous auriez vos bases de données primaires dans AAG1 résidant dans DC1. Vous configurez ensuite une réplique secondaire qui est également située dans DC1 en mode synchrone-commit, ce qui vous permet d’exécuter vos exigences de reporting sans que la surcharge de reporting ait un impact sur votre base de données primaire. Cela permet également de répondre à vos besoins en matière de gestion des ressources humaines, en disposant d’un environnement secondaire cohérent sur le plan transactionnel et capable de basculer en cas de problème avec vos bases de données primaires. Vous pourriez alors configurer des répliques secondaires dans DC2, DC3 & DC4 en mode asynchrone-commit. Ces répliques secondaires asynchrones vous permettent de répondre à vos exigences en matière de DR en disposant de plusieurs copies dans plusieurs emplacements géographiquement dispersés, avec la possibilité de basculer vers en cas de problème sur le site primaire.

Failing Over

Comme avec Database Mirroring et Windows Server Failover Clustering, les groupes de disponibilité AlwaysOn offrent la possibilité de basculer entre les répliques primaires et secondaires que vous avez configurées. Il existe trois formes de basculement qui peuvent être entreprises avec les AAG :

• Automatique – Pris en charge par le mode Commit synchrone – Aucune perte de données
• Manuel – Pris en charge par le mode Commit synchrone – Aucune perte de données
• Forcé – Pris en charge par le mode Commit asynchrone – Perte de données possible

Le mode de disponibilité utilisé dépendra de la mise en œuvre de la haute disponibilité ou de la reprise après sinistre. Cela affecte la configuration de basculement que vous allez mettre en œuvre dans votre environnement SQL Server 2012 AlwaysOn.

Availability Group Listener

Afin de tirer parti des différentes solutions que nous avons échelonnées dans cet article, nous devons configurer et permettre aux applications de maintenir la connectivité aux bases de données SQL Server après un basculement. C’est là que les AlwaysOn Availability Group Listeners (AAGL’s) entrent en jeu.

Un Availability Group Listener est un nom de serveur virtuel auquel les applications se connectent. Du point de vue des applications, l’endroit où la base de données de disponibilité est active et disponible pour être utilisée n’a pas d’importance. L’AAGL se compose de :

• Nom de réseau virtuel (VNN)
• Port d’écouteur
• Une ou plusieurs adresses IP virtuelles (VIP)

Pour que votre application se connecte, vous pouvez soit configurer une chaîne de connexion pour votre AAGL, soit vous connecter directement à votre instance SQL Server. Cependant, une connexion directe ne donne pas le support de basculement pour lequel cette technologie a été construite.

Lorsqu’un basculement se produit pour un AAG, la connexion du client est terminée. Pour avoir à nouveau accès, le client doit se reconnecter à l’AAGL. Pour ce faire, l’application doit être conçue et construite pour interroger l’AAGL. Selon la connexion que vous utilisez :

• Base de données primaire
• Réplique de lecture secondaire

Vous devrez configurer votre ‘ApplicationIntent’ dans votre chaîne de connexion AAGL de manière appropriée.

Avec ces points en tête, nous sommes maintenant capables de créer notre premier AAG de plusieurs façons, qui sont de

• Créer un assistant de groupe de disponibilité
• TSQL
• PowerShell

Élargir l’arbre AlwaysOn High Availability | clic droit Groupes de disponibilité | Nouvel assistant de groupe de disponibilité

Image 16 – Assistant Nouveau groupe de disponibilité AlwaysOn

Nommez votre AAG, cliquez sur ‘Suivant’.

Sélectionnez les bases de données que vous devez inclure dans l’AAG, cliquez sur ‘Suivant’.

Image 17 – Bases de données de disponibilité

Votre réplique primaire sera automatiquement disponible pour que vous puissiez la configurer. Choisissez le mode de disponibilité, la stratégie de basculement et les exigences secondaires lisibles. Cliquez sur  » Ajouter une réplique « , en vous connectant à vos serveurs secondaires appropriés. Assurez-vous de définir votre secondaire de la même manière que votre primaire.

Image 18 – Répliques de disponibilité

Sélectionnez l’onglet Listener, donnez à votre AAGL un nom, un numéro de port et les adresses IP appropriées, cliquez sur ‘Next’.

Image 19 – Répliques de disponibilité

Chaque réplique doit avoir accès à un emplacement partagé pour accéder aux sauvegardes des bases de données créées et utilisées pour la synchronisation des bases de données secondaires. Entrez votre chemin de partage, cliquez sur ‘Suivant’.

Image 20 – Synchronisation initiale des données

Vérifiez que vous recevez toutes les coches vertes pour votre validation, cliquez sur ‘Suivant’.

Image 21 – Validation

Vérifiez le résumé, cliquez sur ‘Terminer’.

Image 22 – Terminer

Venez configurer votre nouvel environnement SQL Server 2012 AlwaysOn.

Lectures complémentaires

• Windows Server Failover Clustering
• Miroir de base de données
• Cryptage transparent des données
• Compression des sauvegardes
• Sauvegardes des bases de données
• SQL Server 2012 AlwaysOn Haute disponibilité et modèles de conception de reprise après sinistre

.

• Guide des solutions Microsoft SQL Server AlwaysOn pour la haute disponibilité et la reprise après sinistre

Matériel de référence

• http://sqlcat.com/sqlcat/b/whitepapers/archive/2011/12/22/sql-server-2012-alwayson_3a00_-multisite-failover-cluster-instance.aspx
• http://www.brentozar.com/archive/2010/11/sql-server-denali-database-mirroring-rocks/
• http://www.sqlmag.com/article/sqlserverdenali/sql-server-2012-configure-alwayson-141127
• http://msdn.microsoft.com/en-us/library/ms189134.aspx