Delen via


SQL Server-beschikbaarheidsgroep migreren naar meerdere subnetten - SQL Server op Azure-VM's

Van toepassing op: SQL Server op Azure VM

In dit artikel leert u hoe u uw AlwaysOn-beschikbaarheidsgroep (AG) migreert van één subnet naar meerdere subnetten om het maken van verbinding met uw listener in Azure met uw SQL Server op virtuele Azure-machines (VM's) te vereenvoudigen.

Fooi

Er zijn veel methoden om een beschikbaarheidsgroep te implementeren. Vereenvoudig uw implementatie en elimineer de noodzaak van een Azure Load Balancer of gedistribueerde netwerknaam (DNN) voor uw AlwaysOn-beschikbaarheidsgroep door uw virtuele SQL Server-machines (VM's) te maken in meerdere subnetten binnen hetzelfde virtuele Azure-netwerk. Als u uw beschikbaarheidsgroep al in één subnet hebt gemaakt, kunt u deze migreren naar een omgeving met meerdere subnetten.

Overzicht

Klanten die SQL Server uitvoeren op virtuele Azure-machines kunnen een AlwaysOn-beschikbaarheidsgroep (AG) implementeren in één subnet of meerdere subnetten (meerdere subnetten). Een configuratie met meerdere subnetten vereenvoudigt de omgeving van de beschikbaarheidsgroep door de noodzaak voor een Azure Load Balancer of een DNN (Distributed Network Name) te verwijderen om verkeer naar de listener in het Azure-netwerk te routeren. Hoewel het gebruik van een benadering met meerdere subnetten wordt aanbevolen, moeten de verbindingsreeksen voor een toepassing worden gebruikt MultiSubnetFailover = true, wat mogelijk niet onmiddellijk mogelijk is vanwege wijzigingen op toepassingsniveau.

Als u oorspronkelijk een beschikbaarheidsgroep in één subnet hebt gemaakt en een Azure Load Balancer of DNN voor de listener gebruikt en nu de complexiteit wilt verminderen door over te stappen op een configuratie met meerdere subnetten, kunt u dit doen met enkele handmatige stappen.

Voordat u een migratie van een bestaande omgeving start, weegt u de risico's van het wijzigen van een ingebruik zijnde omgeving.

Houd rekening met de volgende twee manieren om uw beschikbaarheidsgroep te migreren naar meerdere subnetten:

  • Een nieuwe omgeving maken om naast elkaar testen uit te voeren
  • Een bestaande beschikbaarheidsgroep handmatig verplaatsen

Let op

Het uitvoeren van een migratie brengt een risico met zich mee, dus test altijd grondig in een niet-productieomgeving voordat u naar een productieomgeving overstapt.

Nieuwe omgeving met naast elkaar testen

De eerste methode voor het verplaatsen naar een beschikbaarheidsgroep met meerdere subnetten is het instellen van een nieuwe omgeving. Als dit de gekozen route is, moet u het volgende doen:

  1. Nieuwe virtuele machines maken
  2. Een nieuwe beschikbaarheidsgroep maken in een configuratie met meerdere subnetten
  3. Een back-up maken van uw huidige database en deze herstellen naar de nieuwe omgeving

Maak in eerste instantie in de nieuwe omgeving met meerdere subnetten de listener met een andere naam dan de bestaande omgeving met één subnet. Met een nieuw benoemde listener in een nieuwe beschikbaarheidsgroep kunt u de toepassing naast elkaar testen (testen met zowel het multisubnet als de huidige load balancer of DNN).

Zodra de omgeving met meerdere subnetten grondig is gevalideerd, kunt u overschakelen naar de nieuwe infrastructuur. Afhankelijk van de omgeving (productie, test), gebruikt u een onderhoudsvenster om de wijziging te voltooien. Herstel tijdens het onderhoudsvenster de database naar de nieuwe primaire replica, zet de listener van de beschikbaarheidsgroep in beide omgevingen neer en maak vervolgens de listener opnieuw in de omgeving met meerdere subnetten met dezelfde naam als de vorige listener, de listener die in de verbindingsreeks van de toepassing wordt gebruikt.

Het instellen van een nieuwe omgeving in een configuratie met meerdere subnetten is nu eenvoudiger met de implementatie-ervaring van Azure Portal.

Een bestaande beschikbaarheidsgroep handmatig verplaatsen

De andere optie is om handmatig over te stappen van de omgeving met één subnet naar een omgeving met meerdere subnetten. Als u wilt migreren met deze methode, hebt u de volgende vereisten nodig:

  • Een IP-adres voor elke machine in een nieuw subnet
  • Verbindingsreeksen die al gebruikmaken van MultiSubnetFailover = true

Voer de volgende stappen uit om uw beschikbaarheidsgroep te migreren naar een configuratie met meerdere subnetten:

  1. Maak een nieuw subnet voor elke secundaire, omdat alle virtuele machines zich momenteel in hetzelfde subnet bevinden.

  2. Bepaal het IP- en listener-IP-adres van het cluster voor alle servers in de beschikbaarheidsgroep. Als u bijvoorbeeld een beschikbaarheidsgroep met twee knooppunten hebt, hebt u het volgende:

    VM-naam Subnet IP-adres van cluster Ip-adres van listener
    VM1 (primair) 10.1.1.0/24 (bestaand subnet) 10.1.1.15 10.1.1.16
    VM2 (secundair) 10.1.2.0/24 (nieuw subnet) 10.1.2.15 10.1.2.16
  3. Voeg het IP- en listener-IP-adres van het cluster toe aan de primaire replicaserver. Het toevoegen van deze IP-adressen is een onlinebewerking.

  4. Verplaats in Azure Portal de secundaire server naar het nieuwe subnet door naar de IP-configuraties van de netwerkinterface > van de virtuele machine >>te gaan. Als u de server naar een nieuw subnet verplaatst, wordt de secundaire replicaserver opnieuw opgestart.

  5. Voeg het cluster-IP en het listener-IP-adres toe aan de secundaire replicaserver. Het toevoegen van deze IP-adressen is een onlinebewerking.

  6. Aangezien de IP-adressen en subnetten op dit moment aanwezig zijn, kunt u de load balancer verwijderen.

  7. Zet de listener neer.

  8. Als u Windows Server 2019 en nieuwere versies gebruikt, kunt u deze stap overslaan. Als u Windows Server 2016 gebruikt, voegt u de cluster-IP's handmatig toe aan de FCI.

  9. Maak de listener opnieuw met de nieuwe listener-IP's.

  10. Dns leegmaken op alle servers met ipconfig /flushdns.

Volgende stappen