Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Un cluster de basculement est une combinaison d’un ou plusieurs disques physiques dans un groupe de cluster Microsoft Cluster Service (MSCS), appelé groupe de ressources, qui sont des nœuds participants du cluster. Le groupe de ressources est configuré en tant qu’instance en cluster de basculement qui héberge une instance de SQL Server. Une instance de basculement en cluster de SQL Server apparaît sur le réseau comme s'il s'agissait d'un seul ordinateur. Cependant, elle offre des fonctionnalités de basculement vers un autre nœud si celui-ci devient indisponible. Pour plus d’informations, consultez Instances de cluster de basculement AlwaysOn (SQL Server).
Les clusters de basculement prennent en charge la haute disponibilité pour une instance Microsoft SQL Server entière, contrairement à la mise en miroir de bases de données, qui fournit une prise en charge de haute disponibilité pour une base de données unique. La mise en miroir de bases de données fonctionne entre les clusters de basculement et, également, entre un cluster de basculement et un hôte non cluster.
Remarque
Pour une présentation de la mise en miroir de bases de données, consultez La mise en miroir de bases de données (SQL Server)
Mise en miroir et clustering
En règle générale, lorsque la mise en miroir est utilisée avec le clustering, le serveur principal et le serveur miroir résident tous deux sur des clusters, avec le serveur principal s’exécutant sur l’instance cluster de basculement d’un cluster et le serveur miroir s’exécutant sur l’instance de cluster de basculement d’un autre cluster. Vous pouvez établir une session de mise en miroir dans laquelle un partenaire réside sur l’instance en cluster de basculement d’un cluster et l’autre partenaire réside sur un ordinateur distinct et non cluster, toutefois.
Si un basculement de cluster rend un serveur principal temporairement indisponible, les connexions clientes sont déconnectées de la base de données. Une fois le basculement du cluster terminé, les clients peuvent se reconnecter au serveur principal sur le même cluster, ou sur un autre cluster ou un ordinateur non cluster, en fonction du mode d’exploitation. Par conséquent, lorsque vous décidez comment configurer la mise en miroir de bases de données dans un environnement cluster, le mode d’exploitation que vous utilisez pour la mise en miroir est important.
session en mode High-Safety avec basculement automatique
Si vous envisagez de mettre en miroir une base de données en mode haute sécurité avec basculement automatique, une configuration à deux clusters est recommandée pour les partenaires. Cette configuration fournit une disponibilité maximale. Le témoin peut résider sur un troisième cluster ou sur un ordinateur non cluster.
Si le nœud exécutant le serveur principal actuel échoue, le basculement automatique de la base de données commence en quelques secondes, tandis que le cluster bascule toujours vers un autre nœud. La session de mise en miroir de bases de données bascule vers le serveur miroir sur l’autre cluster ou un ordinateur non cluster, et l’ancien serveur miroir devient le serveur principal. Le nouveau serveur principal transfère sa copie de la base de données le plus rapidement possible et le met en ligne en tant que base de données principale. Une fois le basculement du cluster terminé, ce qui prend généralement plusieurs minutes, l’instance en cluster de basculement qui était anciennement le serveur principal devient le serveur miroir.
L’illustration suivante montre un basculement automatique entre des clusters dans une session de mise en miroir s’exécutant en mode haute sécurité avec un témoin (qui prend en charge le basculement automatique).
Les trois instances de serveur de la session de mise en miroir résident sur trois clusters distincts : Cluster_A, Cluster_B et Cluster_C. Sur chaque cluster, une instance par défaut de SQL Server est exécutée en tant qu'instance de basculement en cluster de SQL Server. Lorsque la session de mise en miroir démarre, l’instance en cluster de basculement sur Cluster_A est le serveur principal, l’instance en cluster de basculement sur Cluster_B est le serveur miroir et l’instance en cluster de basculement sur Cluster_C est le témoin de la session de mise en miroir. Finalement, le nœud actif sur Cluster_A échoue, ce qui entraîne l’indisponibilité du serveur principal.
Avant le basculement du cluster, la perte du serveur principal est détectée par le serveur miroir, avec l’aide du témoin. Le serveur miroir met à jour sa base de données et la rend opérationnelle comme nouvelle base de données principale dès que possible. Lorsqu'Cluster_A a terminé le basculement, l’ancien serveur principal est maintenant le serveur miroir et synchronise sa base de données avec la base de données principale actuelle sur Cluster_B.
Session en mode High-Safety sans basculement automatique
Si vous effectuez la mise en miroir d’une base de données en mode haute sécurité sans basculement automatique, un autre nœud du cluster agit comme serveur principal si le nœud exécutant le serveur principal actuel échoue. Notez que si le cluster n’est pas disponible, la base de données n’est pas disponible.
session en mode High-Performance
Si vous envisagez de répliquer une base de données en mode hautes performances, envisagez de placer le serveur principal sur l’instance en cluster de basculement d’un cluster et de placer le serveur miroir sur un serveur non-clusterisé dans un emplacement distant. Si le cluster bascule vers un autre nœud, l’instance de basculement en cluster continuera à servir de serveur principal dans la session de mise en miroir des bases de données. Si l’ensemble du cluster rencontre des problèmes, vous pouvez forcer le service sur le serveur miroir.
Pour configurer un nouveau cluster de basculement SQL Server
Pour configurer la mise en miroir de bases de données
Voir aussi
Mise en miroir de bases de données (SQL Server)
Modes de fonctionnement de la mise en miroir de bases de données
Instances de cluster de basculement AlwaysOn (SQL Server)