J'expliquerai ce qu'est l'architecture SQL Server AlwaysOn et l'installation étape par étape dans cette série d'articles. Passons en revue l'architecture et l'installation de SQL Server AlwaysOn (groupe de disponibilité)
SQL Server AlwaysOn pas à pas
Microsoft a introduit la fonctionnalité Groupes de disponibilité AlwaysOn avec la version SQL Server 2012. Cette fonctionnalité est en fait une combinaison de fonctionnalités de SQL Server que nous connaissions auparavant, Log Shipping, Failover Clustering et Mirroring.
Si vous ne savez pas ce qu'est l'envoi de journaux, vous pouvez lire les articles suivants sur l'envoi de journaux.
Installation et configuration de l'envoi de journaux et de la récupération après sinistre de SQL Server -4
Si vous ne savez pas ce qu'est le clustering de basculement, vous pouvez lire les articles suivants sur le clustering de basculement.
Installation du cluster de basculement SQL Server -4
La récupération après sinistre a été fournie avec l'envoi de journaux, mais la synchronisation en temps réel n'existe pas avec l'envoi de journaux. La mise en miroir a une synchronisation en temps réel mais il n'y avait pas d'option de lecture seule et un serveur témoin est requis pour le basculement automatique.
L'application a accès à 2 nœuds via le nom du cluster de basculement en même temps que le clustering de basculement, mais le cluster de basculement n'était qu'une solution de haute disponibilité.
Microsoft a combiné tous les avantages de l'envoi de journaux, de la mise en miroir et du cluster de basculement dans SQL Server Always On.
Groupe de disponibilité SQL Server
L'architecture SQL Server AlwaysOn est la suivante.
AlwaysOn est une nouvelle solution SQL Server qui fournit à la fois la haute disponibilité et la reprise après sinistre entre 2 serveurs s'exécutant sur un cluster de basculement Windows Server (WSFC) installé sur au moins 2 serveurs.
AlwaysOn fournit une haute disponibilité car si le nœud principal a été arrêté au moment T, le nœud secondaire sera principal via le basculement automatique.
AlwaysOn fournit une récupération après sinistre car lorsque le stockage ou la carte mère (ou une autre partie du serveur) du serveur primaire a échoué, vous pouvez récupérer la base de données avec le basculement automatique. Parce que la base de données existe physiquement au nœud secondaire et se synchronise à partir de la base de données principale.
Vous pouvez également utiliser le nœud secondaire à des fins de rapport et de sauvegarde.
En bref, si vous envisagez de combiner haute disponibilité et reprise après sinistre pour vos bases de données SQL Server exécutées dans votre entreprise, la seule solution est AlwaysOn .
Créer un groupe de disponibilité
Groupe de disponibilité AlwaysOn : Il s'agit d'une structure publiée avec SQL Server 2012 qui peut être utilisée comme alternative à la mise en miroir de bases de données, à l'envoi de journaux et au clustering de basculement. Avec le groupe de disponibilité AlwaysOn, les modifications apportées à une base de données sur un serveur sont synchronisées sur un autre serveur. Les avantages de cette structure par rapport à la mise en miroir sont que plusieurs serveurs secondaires peuvent être utilisés activement . De plus, alors que les opérations d'écriture et d'autres opérations DML sont effectuées sur le serveur principal, les opérations de sauvegarde et de création de rapports peuvent être effectuées sur le serveur secondaire.
Les conditions requises pour la configuration d'AlwaysOn sont les suivantes.
Créer un groupe de disponibilité AlwaysOn
Pour que la méthode du groupe de disponibilité SQL Server AlwaysOn soit appliquée à la base de données, il doit y avoir deux serveurs ou plus avec les mêmes propriétés, dans lesquels la structure du cluster de basculement Windows Server est configurée comme suit. De plus, la version doit être au moins SQL Server 2012 Enterprise Edition.
Pour activer AlwaysOn sur SQL Server 2012 et supérieur, les deux nœuds doivent être membres du cluster comme suit.
Les définitions nécessaires pour l'accès entre le premier nœud à configurer et le deuxième nœud via les ports 1433 et 445 doivent être faites.
De plus, les définitions de partage de fichiers doivent être effectuées sur un dossier qui doit être défini lors de la configuration du groupe de disponibilité et les sauvegardes initiales des bases de données à inclure dans le groupe de disponibilité seront effectuées. (Normalement, il suffit de donner aux comptes SQL Server et SQL Agent des deux serveurs des privilèges de lecture/écriture sur le dossier correspondant. ) Cependant, si le compte SQL Server sur le serveur de production est l'utilisateur 'LOCAL SYSTEM', l'autorisation de être accordé sur le dossier partagé doit être 'tout le monde – lecture/écriture' Autorisation.
L'utilisateur qui configurera le serveur SQL sur le serveur source doit disposer de l'administrateur sur Windows et de l'administrateur système sur l'autorisation SQL Server.
Étant donné que les disques des serveurs sur lesquels le groupe de disponibilité AlwaysOn sera appliqué sont séparés et indépendants les uns des autres, les dossiers à utiliser pour les données et les fichiers journaux des bases de données à localiser sur les serveurs doivent être créés avec le même nom et le même chemins.
Vous devez installer StandAlone SQL Server pour AlwaysOn. Vous pouvez utiliser l'article suivant pour installer StandAlone SQL Server Instance.
Installation étape par étape de SQL Server 2017 -2
Je continuerai à expliquer l'installation d'AlwaysOn dans l'article suivant.
Vous pouvez accéder aux articles suivants liés à l'installation SQL Server Always On avec le lien suivant.
Architecture SQL Server AlwaysOn et installation étape par étape -2
