Clustering multi-sous-réseau SQL Server

S'applique à :SQL Server

Un cluster de basculement multi-sous-réseau SQL Server est une configuration dans laquelle chaque nœud de cluster de basculement est connecté à un sous-réseau différent ou à un ensemble différent de sous-réseaux. Ces sous-réseaux peuvent se trouver au même emplacement ou dans des sites géographiquement dispersés. Les clusters dans des sites géographiquement dispersés sont parfois appelés clusters étendus. Étant donné qu’il n’existe aucun stockage partagé auquel tous les nœuds peuvent accéder, les données doivent être répliquées entre le stockage de données sur les plusieurs sous-réseaux. Lorsque vous répliquez des données, plusieurs copies des données sont disponibles. Par conséquent, un cluster de basculement de sous-réseaux multiples fournit une solution de récupération d'urgence en plus d'une haute disponibilité.

Cluster de basculement multi-sous-réseau SQL Server (deux nœuds, deux sous-réseaux)

L’illustration suivante représente une instance de cluster de basculement à deux nœuds à deux sous-réseaux (FCI) dans SQL Server.

Configurations d’instance de cluster de basculement multi-sous-réseau

Voici quelques exemples d’instances de cluster de cluster SQL Server qui utilisent plusieurs sous-réseaux :

• SQL Server FCI SQLCLUST1 inclut Node1 et Node2. Node1 est connecté à Subnet1. Node2 est connecté à Subnet2. Le programme d’installation de SQL Server voit cette configuration en tant que cluster multi-sous-réseau et définit la dépendance de ressource d’adresse IP sur OR.

• SQL Server FCI SQLCLUST2 inclut Node1, Node2 et Node3. Node1 et Node2 sont connectés à Subnet1. Node3 est connecté à Subnet2. Le programme d’installation de SQL Server voit cette configuration en tant que cluster multi-sous-réseau et définit la dépendance de ressource d’adresse IP sur OR. Étant donné que Node1 et Node2 se trouvent sur le même sous-réseau, cette configuration fournit une haute disponibilité locale supplémentaire.

• Sql Server FCI SQLCLUST3 inclut Node1 et Node2. Node1 se trouve sur Subnet1. Node2 est sur Subnet1 et Subnet2. Le programme d’installation de SQL Server voit cette configuration en tant que cluster multi-sous-réseau et définit la dépendance de ressource d’adresse IP sur OR.

• SQL Server FCI SQLCLUST4 inclut Node1 et Node2. Node1 est connecté à Subnet1 et Subnet2. Node2 est également connecté à Subnet1 et Subnet2. Le programme d’installation de SQL Server définit la dépendance de ressource d’adresse IP sur AND.

  Notes

  Cette configuration n’est pas considérée comme une configuration de cluster de basculement multi-sous-réseau, car les nœuds en cluster se trouvent sur le même ensemble de sous-réseaux.

Considérations relatives aux ressources d’adresse IP

Dans une configuration de cluster de basculement multi-sous-réseau, les adresses IP ne sont pas détenues par tous les nœuds du cluster de basculement, et elles peuvent ne pas toutes être en ligne au démarrage de SQL Server. À compter de SQL Server 2012 (11.x), vous pouvez définir la dépendance de ressource d’adresse IP sur OR. Cela permet à SQL Server d’être en ligne lorsqu’il existe au moins une adresse IP valide à laquelle elle peut être liée.

Notes

Dans les versions de SQL Server antérieures à SQL Server 2012 (11.x), une technologie stretch V-LAN a été utilisée dans les configurations de cluster multisites pour exposer une adresse IP unique pour le basculement entre les sites. Maintenant que SQL Server peut mettre en cluster des nœuds sur différents sous-réseaux, vous pouvez configurer des clusters de basculement SQL Server sur plusieurs sites sans implémenter la technologie V-LAN étendue.

Considérations relatives à la dépendance OU à la ressource d’adresse IP

Vous pouvez envisager le comportement de basculement suivant si vous définissez la dépendance de ressource d’adresse IP sur OR:

• En cas d’échec de l’une des adresses IP sur le nœud qui possède actuellement le groupe de ressources de cluster SQL Server, un basculement n’est pas déclenché automatiquement tant que toutes les adresses IP valides sur ce nœud échouent.

• Lorsqu’un basculement se produit, SQL Server est en ligne s’il peut être lié à au moins une adresse IP valide sur le nœud actuel. Les adresses IP qui n’ont pas été liées à SQL Server au démarrage sont répertoriées dans le journal des erreurs.

Lorsqu’une instance FCI SQL Server est installée côte à côte avec une instance autonome du moteur de base de données SQL Server, veillez à éviter les conflits de numéros de port TCP sur les adresses IP. Les conflits se produisent généralement lorsque deux instances du moteur de base de données sont configurées pour utiliser le port TCP par défaut (1433). Pour éviter les conflits, configurez une instance pour utiliser un port fixe nondefault. La configuration d’un port fixe est généralement plus facile sur l’instance autonome. La configuration du moteur de base de données pour utiliser différents ports empêche un conflit inattendu d’adresse IP/port TCP qui bloque le démarrage d’une instance lorsqu’une instance de cluster de basculement SQL Server ne parvient pas au nœud de secours.

Latence de récupération du client pendant le basculement

Par défaut, une instance FCI multi-sous-réseau active la ressource de cluster RegisterAllProvidersIP pour son nom réseau. Dans une configuration multi-sous-réseau, les adresses IP en ligne et hors connexion du nom réseau sont toutes deux inscrites sur le serveur DNS. L’application cliente récupère ensuite toutes les adresses IP inscrites du serveur DNS et tente de se connecter aux adresses, dans l’ordre ou en parallèle. Cela signifie que le temps de récupération du client dans les basculements multi-sous-réseaux ne dépend plus des latences de mise à jour DNS. Par défaut, le client tente les adresses IP dans l'ordre. Lorsque le client utilise le paramètre facultatif MultiSubnetFailover=True dans sa chaîne de connexion, il tente les adresses IP simultanément et se connecte au premier serveur qui répond. Cette configuration peut aider à réduire la latence de récupération du client lorsque des basculements se produisent. Pour plus d’informations, consultez Connectivité du client Always On (SQL Server) et Créer ou configurer un écouteur de groupe de disponibilité (SQL Server).

Avec les bibliothèques clientes héritées ou les fournisseurs de données non-Microsoft, vous ne pouvez pas utiliser le paramètre MultiSubnetFailover dans votre chaîne de connexion. Pour vous aider à vous assurer que votre application cliente s'exécute de façon optimale avec l'instance FCI à plusieurs sous-réseaux dans SQL Server, essayez d'ajuster le délai de connexion dans la chaîne de connexion du client par 21 secondes pour chaque adresse IP supplémentaire. Cette configuration garantit que la tentative de reconnexion du client n’expire pas avant de pouvoir parcourir toutes les adresses IP de votre instance FCI multi-sous-réseau.

La période d’expiration de la connexion cliente par défaut pour SQL Server Management Studio et sqlcmd est de 15 secondes.

Notes

Si vous utilisez plusieurs sous-réseaux et que vous disposez d’un DNS statique, vous devez disposer d’un processus en place pour mettre à jour l’enregistrement DNS associé à l’écouteur avant d’effectuer un basculement. Sinon, le nom du réseau ne sera pas en ligne.

Contenu connexe

Descriptif	Article
Installer un cluster de basculement SQL Server	Créer un cluster de basculement SQL Server (installation)
Mise à niveau sur place de votre cluster de basculement SQL Server existant	Mettre à niveau une instance de cluster de basculement SQL Server (installation)
Gérer votre cluster de basculement SQL Server	Ajouter ou supprimer des nœuds dans un cluster de basculement SQL Server (installation)
Utiliser le composant logiciel enfichable Gestion du cluster de basculement pour afficher les événements et journaux du cluster de basculement Windows Server	Afficher les événements et les journaux d’activité d’un cluster de basculement
Utiliser Windows PowerShell pour créer un fichier journal pour tous les nœuds (ou un nœud spécifique) dans un cluster de basculement Windows Server	applet de commande de cluster de basculementGet-ClusterLog