SQL Server-clustering met meerdere subnetten

Van toepassing op:SQL Server

Een SQL Server-failovercluster met meerdere subnetten is een configuratie waarin elk failoverclusterknooppunt is verbonden met een ander subnet of een andere set subnetten. Deze subnetten kunnen zich op dezelfde locatie bevinden of op geografisch verspreide locaties. Clusters in geografisch verspreide sites worden soms stretch-clusters genoemd. Omdat er geen gedeelde opslag is waartoe alle knooppunten toegang hebben, moeten gegevens worden gerepliceerd tussen de gegevensopslag op de meerdere subnetten. Wanneer u gegevens repliceert, is er meer dan één kopie van de beschikbare gegevens. Daarom biedt een failovercluster met meerdere subnetten een oplossing voor herstel na noodgevallen naast hoge beschikbaarheid.

SQL Server-failovercluster met meerdere subnetten (twee knooppunten, twee subnetten)

In de volgende afbeelding ziet u een exemplaar van een failovercluster met twee knooppunten met twee knooppunten (FCI) in SQL Server.

Failoverclusterconfiguraties met meerdere subnetten

Hier volgen enkele voorbeelden van SQL Server-CCI's die gebruikmaken van meerdere subnetten:

• SQL Server FCI-SQLCLUST1 bevat Node1 en Node2. Node1 is verbonden met Subnet1. Node2 is verbonden met Subnet2. Sql Server Setup ziet deze configuratie als een cluster met meerdere subnetten en stelt de afhankelijkheid van de IP-adresresource in op OR.

• SQL Server FCI-SQLCLUST2 bevat Node1, Node2 en Node3. Node1 en Node2 zijn verbonden met Subnet1. Knooppunt 3 is verbonden met Subnet2. Sql Server Setup ziet deze configuratie als een cluster met meerdere subnetten en stelt de afhankelijkheid van de IP-adresresource in op OR. Omdat Node1 en Node2 zich in hetzelfde subnet bevinden, biedt deze configuratie extra lokale hoge beschikbaarheid.

• SQL Server FCI-SQLCLUST3 bevat Node1 en Node2. Node1 bevindt zich op Subnet1. Node2 bevindt zich in Subnet1 en Subnet2. Sql Server Setup ziet deze configuratie als een cluster met meerdere subnetten en stelt de afhankelijkheid van de IP-adresresource in op OR.

• SQL Server FCI-SQLCLUST4 bevat Node1 en Node2. Node1 is verbonden met Subnet1 en Subnet2. Node2 is ook verbonden met Subnet1 en Subnet2. Sql Server Setup stelt de afhankelijkheid van de IP-adresresource in op AND.

  Opmerking

  Deze configuratie wordt niet beschouwd als een failoverclusterconfiguratie met meerdere subnetten, omdat de geclusterde knooppunten zich in dezelfde set subnetten bevinden.

Overwegingen voor IP-adresresources

In een failoverclusterconfiguratie met meerdere subnetten zijn de IP-adressen niet eigendom van alle knooppunten in het failovercluster en zijn ze mogelijk niet allemaal online tijdens het opstarten van SQL Server. Vanaf SQL Server 2012 (11.x) kunt u de afhankelijkheid van de IP-adresresource instellen op OR. Als u dit doet, kan SQL Server online zijn wanneer er ten minste één geldig IP-adres is waarmee deze verbinding kan maken.

Overwegingen voor RESOURCE OF afhankelijkheid van IP-adressen

U kunt rekening houden met het volgende failovergedrag als u de afhankelijkheid ORvan de IP-adresresource instelt op:

• Wanneer er een fout optreedt in een van de IP-adressen op het knooppunt dat momenteel eigenaar is van de resourcegroep van het SQL Server-cluster, wordt een failover pas automatisch geactiveerd als alle IP-adressen die geldig zijn op dat knooppunt mislukken.

• Wanneer een failover optreedt, komt SQL Server online als deze verbinding kan maken met ten minste één IP-adres dat geldig is op het huidige knooppunt. De IP-adressen die tijdens het opstarten niet zijn verbonden met SQL Server, worden vermeld in het foutenlogboek.

Wanneer een SQL Server FCI naast een zelfstandig exemplaar van de SQL Server Database Engine is geïnstalleerd, moet u ervoor zorgen dat er conflicten tussen TCP-poortnummers op de IP-adressen worden voorkomen. Conflicten treden meestal op wanneer twee exemplaren van de database-engine zijn geconfigureerd voor het gebruik van de standaard TCP-poort (1433). Als u conflicten wilt voorkomen, configureert u één exemplaar voor het gebruik van een niet-standaard vaste poort. Het configureren van een vaste poort is meestal eenvoudiger op het zelfstandige exemplaar. Het configureren van de database-engine voor het gebruik van verschillende poorten voorkomt een onverwacht IP-adres/TCP-poortconflict dat het opstarten van een exemplaar blokkeert wanneer een SQL Server FCI het stand-by-knooppunt niet kan gebruiken.

Latentie van clientherstel tijdens failover

Standaard schakelt een FCI met meerdere subnetten de RegisterAllProvidersIP-clusterresource in voor de netwerknaam. In een configuratie met meerdere subnetten worden de online- en offline-IP-adressen van de netwerknaam beide geregistreerd op de DNS-server. De clienttoepassing haalt vervolgens alle geregistreerde IP-adressen van de DNS-server op en probeert verbinding te maken met de adressen, in volgorde of parallel. Dit betekent dat de hersteltijd van clients in failovers met meerdere subnetten niet langer afhankelijk is van de latentie van DNS-updates. De client probeert standaard de IP-adressen in de volgorde. Wanneer de client de optionele MultiSubnetFailover=True parameter in de verbindingsreeks gebruikt, probeert deze in plaats daarvan tegelijkertijd de IP-adressen en maakt deze verbinding met de eerste server die reageert. Deze configuratie kan helpen de latentie van clientherstel te minimaliseren wanneer er failovers plaatsvinden. Zie AlwaysOn-clientconnectiviteit (SQL Server) en een listener voor beschikbaarheidsgroepen maken of configureren (SQL Server) voor meer informatie.

Met verouderde clientbibliotheken of niet-Microsoft-gegevensproviders kunt u de parameter MultiSubnetFailover niet gebruiken in uw verbindingsreeks. Om ervoor te zorgen dat uw clienttoepassing optimaal werkt met FCI met meerdere subnetten in SQL Server, probeert u de verbindingstime-out in de clientverbindingsreeks met 21 seconden voor elk extra IP-adres aan te passen. Deze configuratie zorgt ervoor dat er geen time-out optreedt voordat er een time-out optreedt voordat de client alle IP-adressen in uw FCI met meerdere subnetten kan doorlopen.

De standaard time-outperiode voor clientverbindingen voor SQL Server Management Studio en sqlcmd is 15 seconden.

Verwante inhoud