Clustering de sous-réseaux multiples SQL Server (SQL Server)

S'applique à : SQL Server

Un cluster de basculement de sous-réseaux multiples 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. En cas de clustering dans des sites géographiquement dispersés, on utilise parfois le terme « clusters étendus ». Comme tous les nœuds ne peuvent pas accéder à un stockage partagé, les données doivent être répliquées entre le stockage des données sur les sous-réseaux multiples. Avec la réplication de données, il existe plusieurs copies des données 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 de sous-réseaux multiples SQL Server (deux nœuds, deux sous-réseaux)

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

Configurations d'une instance de cluster de basculement à plusieurs sous-réseaux

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

• SQL Server FCI SQLCLUST1 inclut Node1 et Node2. Node1 est connecté à Subnet1. Node2 est connecté à Subnet2. SQL Server Le programme de configuration considère cette configuration comme un cluster à plusieurs sous-réseaux et définit la dépendance de ressource d’adresse IP sur OR.

• SQL Server FCI SQLCLUST1 inclut Node1, Node2 et Node3. Node1 et Node2 sont connectés à Subnet1. Node3 est connecté à Subnet2. SQL Server Le programme de configuration considère cette configuration comme un cluster à plusieurs sous-réseaux 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 SQLCLUST1 inclut Node1 et Node2. Node1 se trouve sur Subnet1. Node2 est sur Subnet1 et Subnet2. SQL Server Le programme de configuration considère cette configuration comme un cluster à plusieurs sous-réseaux et définit la dépendance de ressource d’adresse IP sur OR.

• SQL Server FCI SQLCLUST1 inclut Node1 et Node2. Node1 est connecté à Subnet1 et Subnet2. Node2 est également connecté à Subnet1 et Subnet2. La dépendance de ressource d’adresse IP est définie sur AND par le programme de configuration de SQL Server .

  Notes

  Cette configuration n'est pas considérée comme une configuration de cluster de basculement de sous-réseaux multiples car les nœuds de clusters se trouvent sur le même ensemble de sous-réseaux.

Considérations relatives aux ressources d'adresses IP

Dans une configuration de cluster de basculement de sous-réseaux multiples, les adresses IP ne sont pas détenues par tous les nœuds dans le cluster de basculement et ne peuvent pas être toutes en ligne pendant le 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 y a au moins une adresse IP valide avec laquelle il peut être lié.

Considérations relatives à la dépendance OR de la ressource d'adresse IP

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

• Lorsqu'il y a un échec de l'une des adresses IP sur le nœud qui possède actuellement le groupe de ressources de cluster SQL Server , aucun basculement n'est déclenché automatiquement tant que toutes les adresses IP valides sur ce nœud n'ont pas échoué.

• Lorsqu'un basculement se produit, SQL Server est mis en ligne s'il peut créer une liaison avec au moins une adresse IP valide sur le nœud actuel. Les adresses IP qui n'ont pas créé de liaison avec SQL Server au démarrage apparaîtront dans le journal des erreurs.

Lorsqu'une instance de cluster de basculement (FCI) SQL Server est installée côte à côte avec une instance autonome de Moteur de base de données SQL Server, prenez soin d'éviter les conflits de numéro de port TCP sur les adresses IP. Les conflits se produisent généralement lorsque deux instances de Moteur de base de données sont configurées pour utiliser le port TCP par défaut (1433). Pour éviter des conflits, configurez une instance pour utiliser un port fixe non défini par défaut. La configuration d'un port fixe est généralement plus simple sur l'instance autonome. La configuration de Moteur de base de données de manière à utiliser des ports différents empêche un conflit inattendu adresse IP/port TCP qui bloque un démarrage de l'instance lorsqu'une instance de cluster de basculement (FCI) SQL Server échoue au nœud en attente.

Latence de récupération cliente pendant un basculement

Une instance FCI à plusieurs sous-réseaux active par défaut la ressource de cluster RegisterAllProvidersIP pour son nom réseau. Dans une configuration à plusieurs sous-réseaux, les adresses IP en ligne et hors connexion du nom réseau seront inscrites sur le serveur DNS. L'application cliente récupère ensuite toutes les adresses IP inscrites depuis le serveur DNS, puis tente de se connecter aux adresses dans l'ordre ou en parallèle. Cela signifie que le temps de récupération client dans les basculements à plusieurs 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. Quand le client utilise le nouveau paramètre facultatif MultiSubnetFailover=True dans sa chaîne de connexion, il tente à la place les adresses IP simultanément et se connecte au premier serveur qui répond. Cela peut réduire la latence de récupération cliente lorsque des basculements se produisent. Pour plus d’informations, consultez Connectivité client AlwaysOn (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 tiers, 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. Cela garantit que la tentative de reconnexion du client n’expire pas avant de pouvoir faire défiler toutes les adresses IP de votre instance FCI à plusieurs sous-réseaux.

Le délai d’expiration de connexion cliente par défaut pour SQL Server Management Studio et sqlcmd est de 15 secondes.

Contenu associé