Groupes de disponibilité toujours actifs améliorés dans SQL Server 2016 – Serveur d’impression

Les groupes à disponibilité permanente sont un composant fondamental de l'historique de disponibilité pour SQL Server et constituent également une solution de récupération d'urgence robuste. Les groupes de disponibilité ont été introduits pour la première fois dans SQL Server 2012, en remplacement des technologies antérieures de mise en miroir de bases de données. Ils permettent à un administrateur de bases de données de configurer deux instances SQL afin d’héberger des répliques d’un ensemble de bases de données, qui peuvent être maintenues parfaitement synchronisées, ne garantissant aucune perte de données, ou quasiment parfaitement synchronisées (réplication asynchrone, optimale pour les réplicas géographiquement distants). Cette technologie est devenue la norme utilisée par la majorité des instances critiques de SQL Server de production.

SQL Server 2016 apporte des améliorations significatives au jeu de fonctionnalités Groupes toujours disponibles. Il existe un certain nombre de fonctionnalités, telles que:

• Équilibrage de la charge à tour de rôle dans les secondaires lisibles
• Augmentation du nombre de cibles de basculement automatique
• Amélioration du débit de réplication des journaux et de la vitesse de rétablissement
• Prise en charge des comptes de service gérés par le groupe
• Prise en charge des transactions distribuées (DTC)
• Basic HA en édition standard
• Amorçage direct de nouvelles répliques de base de données

Chacun d'entre eux mérite son propre article de blog, et j'espère les avoir tous. Cependant, il ya une fonctionnalité sur laquelle je voudrais me concentrer aujourd’hui car elle ouvre des scénarios intéressants et qui est demandée depuis très longtemps.

Lorsque les groupes Toujours en disponibilité ont été introduits dans SQL Server 2012, cela représentait une avancée substantielle dans l'histoire de la haute disponibilité par rapport à la technologie précédente, la mise en miroir de bases de données (DBM). En adoptant certaines couches de la fonctionnalité WSFC (Windows Server Failover Cluster) à utiliser en tant qu'infrastructure, la nouvelle solution peut être beaucoup plus performante et évoluer beaucoup mieux que la solution DBM d'origine. Lorsque DBM était limité à deux réplicas, le principal et le miroir, les groupes de disponibilité pouvaient initialement prendre en charge cinq réplicas (jusqu'à huit à partir de SQL Server 2014). Peut-être plus important encore, lorsque DBM a établi une relation entre une base de données et une copie de cette base de données, les groupes de disponibilité, comme leur nom l’indique, établissent une relation entre un ensemble ou un groupe de bases de données et les répliques de ce groupe de bases de données sur une ou plusieurs répliques. . Cela signifie que pour les applications qui accèdent à plusieurs bases de données, telles qu'une batterie de serveurs SharePoint, toutes les bases de données du groupe peuvent désormais être déplacées comme une unité. Nous n'avons plus besoin de nous soucier de la mise en œuvre de solutions de script complexes pour faire en sorte que plusieurs bases de données se déplacent ensemble.

L'une des restrictions supplémentaires fournies avec les groupes de disponibilité était la restriction selon laquelle tous les nœuds du groupe de disponibilité devaient résider dans le même domaine Active Directory.

Bien que cela fonctionne bien pour la majorité de nos clients, certains modèles de déploiement ne peuvent pas être satisfaits avec les solutions actuelles Groupes de disponibilité permanente / Cluster de basculement Windows Server:

• Certains environnements d'entreprise ont plusieurs domaines qui ne peuvent pas être fusionnés, mais il serait avantageux de couvrir un groupe de disponibilité entre eux. Ces multiples domaines peuvent ou non avoir des relations de confiance entre eux, mais il est néanmoins nécessaire de disposer de serveurs hébergeant des répliques de récupération après sinistre.
• Certains clients ou installations spécifiques ne sont pas du tout dans le contexte de domaines Active Directory.

Afin de remédier à cette situation, SQL Server disposait de deux options: nous pouvions (encore une fois) réimplémenter la fonctionnalité actuellement fournie par WSFC ou collaborer avec l'équipe du cluster de basculement Windows Server pour éliminer la restriction de domaine unique. . Les deux équipes se sont rencontrées et ont travaillé pendant plus d'un an pour comprendre quelles étaient les restrictions techniques qui ont conduit à cette limitation et pour imaginer à quoi pourrait ressembler une solution qui ne repose pas sur AD pour l'authentification et la sécurité, et comment la rendre utilisable. .

Il en résulte qu'avec la version de Windows Server 2016, les clusters de basculement Windows Server n'exigent plus que tous les nœuds d'un cluster résident dans le même domaine. En fait, ils n’obligeront plus les nœuds à résider dans aucun domaine. Vous pouvez maintenant former un cluster WSFC à partir de machines appartenant à des groupes de travail. En raison de cette modification, SQL Server 2016 est désormais en mesure de déployer des groupes de disponibilité permanente dans les environnements avec:

• Tous les nœuds d'un même domaine
• Nœuds dans plusieurs domaines en toute confiance
• Nœuds dans plusieurs domaines sans confiance
• Noeuds dans aucun domaine

Cela ouvre un grand nombre de nouveaux scénarios aux clients et supprime les précédents blocs empêchant la migration de la technologie obsolète de mise en miroir de bases de données vers les groupes de disponibilité AlwaysOn.

Bien que de nombreux clients considèrent ce changement comme un grand pas en avant en matière d'ouverture et de flexibilité, l'infrastructure AD simplifie de nombreuses opérations. Par conséquent, pour fonctionner sans elle, nous devons compenser ces changements.

Pour configurer le clustering de basculement Windows Server dans un environnement dépourvu de sécurité AD, nous devons fournir un moyen de configurer le cluster de manière sécurisée et d'assurer des communications sécurisées au sein du cluster. WSFC à partir de Windows Server 2016, crée des certificats auto-signés et les utilise pour sécuriser l'authentification intra-cluster. Dans les environnements dotés d'une sécurité AD, nous exploitons cette infrastructure de sécurité pour établir les liaisons de communication sécurisées. Sans AD, nous devons faire un pas supplémentaire. Pour établir le cluster dans des environnements sans AD, WSFC vous oblige à configurer des comptes d’administrateur synchronisés sur tous les nœuds de cluster proposés. Cela signifie qu'il doit exister un compte avec le même nom et le même mot de passe, à savoir dans le groupe Administrateurs, sur chaque nœud du cluster. Vous devez également pouvoir résoudre les noms d'hôte de tous les nœuds du cluster afin qu'ils puissent se retrouver.

À l'heure actuelle, WSFC ne peut pas être géré à l'aide de l'interface utilisateur dans des environnements sans sécurité AD. Vous devez donc former et manipuler le cluster à l'aide d'applets de commande PowerShell. Heureusement, le minimum de commandes pour nos besoins est très simple.

PS C: > New-Cluster -Name "MyCluster" -Nœuds Noeud1, Node2, Node3, Node4 -AdministrativeAccessPoint DNS

C'est ça! C’est aussi simple que cela une fois les bases établies.

Vous pouvez trouver plus d'informations sur les clusters Domaneous de l'équipe Windows Cluster sur le blog de l'équipe Clustering avec basculement et équilibrage de la charge réseau.

Dans les environnements sans sécurité AD, nous devons sécuriser les «points finaux de mise en miroir» de la même manière que lorsqu'ils étaient utilisés dans la mise en miroir de bases de données sans domaines. Cela implique un certain nombre d'étapes et peut s'avérer fastidieux, notamment lorsqu'il existe plusieurs nœuds dans l'AG. Afin de faciliter cela, j'ai créé une paire de scripts pour vous aider. Le premier, CreateEndpointCert, crée un certificat basé sur un mot de passe et le sauvegarde sur un partage réseau auquel toutes les machines de l’AG auront accès. Afin de faciliter cela, je vous recommande de configurer le service SQL Server pour qu'il s'exécute en tant que compte d'utilisateur synchronisé de la même manière que le compte Admin utilisé pour configurer le cluster. Ce compte ne doit pas nécessairement être un administrateur de boîte, mais cela permettra à un partage réseau d'être configuré avec un accès en écriture à ce compte. Le script configure ensuite le noeud final de mise en miroir pour qu'il soit authentifié à l'aide de ce certificat. Cela signifie que lorsqu'une tentative de connexion est effectuée via le noeud final vers une autre machine, le certificat sera présenté au serveur comme informations d'identification pour la tentative de connexion.

Le deuxième script, InstallEndpointCert, prend comme paramètres l'ordinateur distant dont le certificat doit être installé sur cette instance, le partage sur lequel les certificats ont été sauvegardés et un mot de passe fort à utiliser pour une connexion locale.

Le script restaurera le certificat distant et créera une connexion basée sur ce certificat. Il accordera ensuite à cet utilisateur et à son identifiant l'accès à l'instance. Désormais, lorsque le noeud final de l'autre système tente de se connecter et présente le certificat, le noeud local reconnaîtra ce certificat comme étant lié à l'utilisateur local et accordera la connexion en fonction de celui-ci.

Ainsi, la séquence totale ressemble à:

Si vous avez configuré les instances avec des comptes de service synchronisés, vous pouvez désormais créer et manipuler le groupe de disponibilité comme n'importe quel autre. Vous pouvez créer un script pour la création ou utiliser l'assistant de création d'un nouvel AG pour créer l'AG. Vous le manipulez comme tout autre et le surveillez à l'aide du tableau de bord, des DMV ou d'autres outils SQL.

CreateEndpointCert

——————————————————————————————————–
– Cette procédure automatise la création d'un certificat local et des points de terminaison requis pour un AG sans domaine.
– Les paramètres sont le mot de passe fort pour le cert et l'emplacement d'un partage qui reçoit la sauvegarde du cert.
– Le partage doit être accessible à tous les nœuds de l'AG, car ils devront lire les certificats l'un pour l'autre.
– La procédure crée également le noeud final en fonction du certificat nouvellement créé.
–
– EXEC CreateEndpointCert "\ Myserver Myshare" "1R3 @ llyStr0ngP @ ssw0rd!"
———————————————————————————————————

CREATE PROCEDURE CreateEndpointCert
@ShareName SYSNAME ,
@StrongPassword SYSNAME
COMME COMMENCER

–Ceci doit être exécuté dans le contexte du maître
SI (DB_NAME() <> 'Maître')
COMMENCER
IMPRESSION N’This SP doit être exécuté en maître. UTILISEZ master et réessayez. ’
REVENIR (-1)
FIN

DÉCLARER @DynamicSQL Varchar(1000)
DÉCLARER @CompName Varchar(250)
DÉCLARER @HasMasterKey INT;
SÉLECTIONNER @CompName = CONVERT(SysName, SERVEURPROPERTY('Nom de la machine'));

– Créer une clé principale uniquement si elle n'existe pas déjà

SÉLECTIONNER @HasMasterKey = is_master_key_encrypted_by_server de sys.databases où Nom = 'Maître'
SI (@HasMasterKey = 0)
COMMENCER
–Créez une MASTER KEY pour chiffrer le certificat.
ENSEMBLE @DynamicSQL = CONCAT('CREER UN CHIFFREMENT DE CLE PRINCIPALE PAR MOT DE PASSE =' , QUOTENAME(@StrongPassword, ""));
EXEC (@DynamicSQL)
FIN

–Créez le certificat pour authentifier le noeud final
ENSEMBLE @DynamicSQL = CONCAT(«CRÉER LE CERTIFICAT», QUOTENAME(@CompName + «-Cert»), 'WITH SUBJECT =', QUOTENAME(@CompName, ""));
EXEC (@DynamicSQL)

–Créez le point de terminaison de mise en miroir de la base de données authentifié par le certificat.
ENSEMBLE @DynamicSQL =
CONCAT(«CREATE ENDPOINT Endpoint_Mirroring
STATE = STARTED
AS TCP (LISTENER_PORT = 5022, LISTENER_IP = ALL)
FOR DATABASE_MIRRORING (AUTHENTICATION = CERTIFICATE ',QUOTENAME(@CompName + «-Cert»), ", CHIFFREMENT = ALGORITHME REQUIS AES, ROLE = ALL)")
EXEC (@DynamicSQL)

–Back le certificat sur un partage réseau commun pour importation dans d'autres nœuds du cluster
ENSEMBLE @DynamicSQL = CONCAT(«CERTIFICAT DE SAUVEGARDE»,QUOTENAME(@CompName + «-Cert»),'To FILE =', QUOTENAME( @ShareName + ' SQL-' + @CompName + «.Cer», ""));
EXEC (@DynamicSQL)
FIN
ALLER

InstallEndpointCert

—————————————————————————————-
– Cette procédure suppose qu'un certificat a été créé sur un autre nœud de l'AG et sauvegardé sur un partage réseau commun.
– Paramètres:
– @CompName – Nom de l'ordinateur dont le certificat doit être installé ici. c’est-à-dire l’autre réplica avec lequel ce nœud doit communiquer.
– @ShareName – Partage réseau commun sur lequel les certificats ont été sauvegardés à partir de chaque machine du cluster / de l'AG.
– @StrongPassword – Un mot de passe fort à utiliser pour le login créé pour se connecter au nom du noeud final sur l'autre noeud.
–
– Cette procédure suppose que chaque nœud a exécuté CreateEndpointCert et que tous les fichiers de sauvegarde de certificat résident sur le partage pointé par le second paramètre.
– La procédure crée un identifiant et un utilisateur pour la machine distante, puis a créé un certificat pour autoriser l'utilisateur lorsque le certificat est utilisé comme authentification à partir du noeud final distant.
———————————————————————————————

CREER PROCEDURE InstallEndpointCert
@CompName SYSNAME,
@ShareName SYSNAME,
@StrongPassword SYSNAME
COMME COMMENCER
DÉCLARER @DynamicSQL Varchar(1000)
DÉCLARER @MyCompName Varchar(250)
SÉLECTIONNER @MyCompName = CONVERTIR(SysName, SERVEURPROPERTY('Nom de la machine'));
–N’a pas besoin de créer de LOGIN pour le système local
SI (@MyCompName <> @CompName)
COMMENCER
ENSEMBLE @DynamicSQL = CONCAT('CRÉER UNE CONNEXION ', QUOTENAME (@CompName + '-S'identifier'), 'WITH PASSWORD =', QUOTENAME( @StrongPassword, ""));
EXEC (@DynamicSQL)

ENSEMBLE @DynamicSQL = CONCAT('CRÉER UN UTILISATEUR ', QUOTENAME( @CompName + '-Utilisateur'), "POUR CONNEXION", QUOTENAME(@CompName + '-S'identifier'));
EXEC (@DynamicSQL)

ENSEMBLE @DynamicSQL = CONCAT(«CRÉER LE CERTIFICAT», QUOTENAME(@CompName +«-Cert»), «AUTORISATION», QUOTENAME(@CompName +'-Utilisateur'), 'FROM FILE =', QUOTENAME(@ShareName + ' SQL-' + @CompName + «.Cer» , ""));
EXEC (@DynamicSQL)

ENSEMBLE @DynamicSQL = CONCAT("GRANT CONNECT ON ENDPOINT :: Endpoint_Mirroring TO", QUOTENAME(@CompName +'-S'identifier'));
EXEC (@DynamicSQL)
FIN
FIN
ALLER

Voir les autres articles de la série de blogs SQL Server 2016.