Een ILB-listener configureren voor beschikbaarheidsgroepen op Azure SQL Server-VM's

Artikel
05/02/2017

Overzicht

Belangrijk

Azure heeft twee verschillende implementatiemodellen voor het maken en werken met resources: Azure Resource Manager en klassiek. In dit artikel wordt het gebruik van het klassieke implementatiemodel beschreven. We raden u aan dat de meeste nieuwe implementaties gebruikmaken van het Resource Manager-model.

Als u een listener wilt configureren voor een AlwaysOn-beschikbaarheidsgroep in het Resource Manager-model, raadpleegt u Een load balancer configureren voor een AlwaysOn-beschikbaarheidsgroep in Azure.

Uw beschikbaarheidsgroep kan replica's bevatten die alleen on-premises of alleen Azure zijn, of die zowel on-premises als Azure omvatten voor hybride configuraties. Azure-replica's kunnen zich in dezelfde regio of in meerdere regio's bevinden die gebruikmaken van meerdere virtuele netwerken. In de procedures in dit artikel wordt ervan uitgegaan dat u al een beschikbaarheidsgroep hebt geconfigureerd , maar nog geen listener hebt geconfigureerd.

Richtlijnen en beperkingen voor interne listeners

Het gebruik van een interne load balancer (ILB) met een listener voor beschikbaarheidsgroepen in Azure is onderworpen aan de volgende richtlijnen:

De listener voor beschikbaarheidsgroepen wordt ondersteund in Windows Server 2008 R2, Windows Server 2012 en Windows Server 2012 R2.
Er wordt slechts één listener voor interne beschikbaarheidsgroepen ondersteund voor elke cloudservice, omdat de listener is geconfigureerd voor de ILB en er slechts één ILB is voor elke cloudservice. Het is echter mogelijk om meerdere externe listeners te maken. Zie Een externe listener configureren voor AlwaysOn-beschikbaarheidsgroepen in Azure voor meer informatie.

De toegankelijkheid van de listener bepalen

Het is belangrijk om te beseffen dat er twee manieren zijn om een listener voor een beschikbaarheidsgroep in Azure te configureren. De manieren verschillen in het type Azure Load Balancer dat u gebruikt wanneer u de listener maakt. In de volgende tabel worden de verschillen beschreven:

Type load balancer	Implementatie	Gebruiken wanneer:
Extern	Gebruikt het openbare virtuele IP-adres van de cloudservice die als host fungeert voor de virtuele machines (VM's).	U moet toegang krijgen tot de listener van buiten het virtuele netwerk, met inbegrip van internet.
Intern	Maakt gebruik van een interne load balancer met een privéadres voor de listener.	U hebt alleen toegang tot de listener vanuit hetzelfde virtuele netwerk. Deze toegang omvat site-naar-site VPN in hybride scenario's.

Belangrijk

Voor een listener die gebruikmaakt van het openbare VIP van de cloudservice (externe load balancer), zolang de client, listener en databases zich in dezelfde Azure-regio bevinden, worden er geen uitgaande kosten in rekening gebracht. Anders worden alle gegevens die via de listener worden geretourneerd, beschouwd als uitgaand verkeer en worden er kosten in rekening gebracht tegen normale gegevensoverdrachtsnelheden.

Een ILB kan alleen worden geconfigureerd voor virtuele netwerken met een regionaal bereik. Bestaande virtuele netwerken die zijn geconfigureerd voor een affiniteitsgroep, kunnen geen ILB gebruiken. Zie het overzicht van interne load balancer voor meer informatie.

Dit artikel is gericht op het maken van een listener die gebruikmaakt van een ILB. Als u een openbare of externe listener nodig hebt, raadpleegt u de versie van dit artikel waarin wordt besproken hoe u een externe listener instelt.

VM-eindpunten met gelijke taakverdeling maken met direct server return

U maakt eerst een ILB door het script verderop in deze sectie uit te voeren.

Maak een eindpunt met gelijke taakverdeling voor elke VIRTUELE machine die als host fungeert voor een Azure-replica. Als u replica's in meerdere regio's hebt, moet elke replica voor die regio zich in dezelfde cloudservice in hetzelfde virtuele Azure-netwerk bevinden. Voor het maken van replica's van beschikbaarheidsgroepen die meerdere Azure-regio's omvatten, moet u meerdere virtuele netwerken configureren. Zie Virtueel netwerk configureren voor virtuele netwerkconnectiviteit configureren voor virtuele netwerkconnectiviteit voor meer informatie over het configureren van connectiviteit tussen virtuele netwerken.

Ga in de Azure Portal naar elke virtuele machine waarop een replica wordt gehost om de details weer te geven.
Klik op het tabblad Eindpunten voor elke VIRTUELE machine.
Controleer of de naam en openbare poort van het listener-eindpunt dat u wilt gebruiken, nog niet in gebruik zijn. In het voorbeeld in deze sectie is de naam MyEndpoint en is de poort 1433.
Download en installeer de nieuwste PowerShell-module op uw lokale client.
Start Azure PowerShell.
Er wordt een nieuwe PowerShell-sessie geopend, waarbij de Azure-beheermodules zijn geladen.
Voer Get-AzurePublishSettingsFile uit. Met deze cmdlet wordt u naar een browser om een bestand met publicatie-instellingen naar een lokale map te downloaden. U wordt mogelijk gevraagd om uw aanmeldingsreferenties voor uw Azure-abonnement.
Voer de volgende Import-AzurePublishSettingsFile opdracht uit met het pad van het bestand met publicatie-instellingen dat u hebt gedownload:
```
Import-AzurePublishSettingsFile -PublishSettingsFile <PublishSettingsFilePath>
```
Nadat het bestand met publicatie-instellingen is geïmporteerd, kunt u uw Azure-abonnement beheren in de PowerShell-sessie.
Wijs voor ILB een statisch IP-adres toe. Bekijk de huidige configuratie van het virtuele netwerk door de volgende opdracht uit te voeren:
```
(Get-AzureVNetConfig).XMLConfiguration
```
Noteer de naam van het subnet voor het subnet dat de VM's bevat die als host fungeren voor de replica's. Deze naam wordt gebruikt in de parameter $SubnetName in het script.
Noteer de naam van VirtualNetworkSite en het beginadresvoorvoegsel voor het subnet dat de VM's bevat die als host fungeren voor de replica's. Zoek naar een beschikbaar IP-adres door beide waarden door te geven aan de Test-AzureStaticVNetIP opdracht en door de AvailableAddresses te bekijken. Als het virtuele netwerk bijvoorbeeld MyVNet heet en een subnetadresbereik heeft dat begint bij 172.16.0.128, bevat de volgende opdracht beschikbare adressen:
```
(Test-AzureStaticVNetIP -VNetName "MyVNet"-IPAddress 172.16.0.128).AvailableAddresses
```
Selecteer een van de beschikbare adressen en gebruik deze in de parameter $ILBStaticIP van het script in de volgende stap.

Kopieer het volgende PowerShell-script naar een teksteditor en stel de variabelewaarden in op uw omgeving. Er zijn standaardwaarden opgegeven voor sommige parameters.

Bestaande implementaties die gebruikmaken van affiniteitsgroepen kunnen geen ILB toevoegen. Zie het overzicht van interne load balancer voor meer informatie over ILB-vereisten.

Als uw beschikbaarheidsgroep Azure-regio's omvat, moet u het script eenmaal uitvoeren in elk datacenter voor de cloudservice en knooppunten die zich in dat datacenter bevinden.

# Define variables
$ServiceName = "<MyCloudService>" # the name of the cloud service that contains the availability group nodes
$AGNodes = "<VM1>","<VM2>","<VM3>" # all availability group nodes containing replicas in the same cloud service, separated by commas
$SubnetName = "<MySubnetName>" # subnet name that the replicas use in the virtual network
$ILBStaticIP = "<MyILBStaticIPAddress>" # static IP address for the ILB in the subnet
$ILBName = "AGListenerLB" # customize the ILB name or use this default value

# Create the ILB
Add-AzureInternalLoadBalancer -InternalLoadBalancerName $ILBName -SubnetName $SubnetName -ServiceName $ServiceName -StaticVNetIPAddress $ILBStaticIP

# Configure a load-balanced endpoint for each node in $AGNodes by using ILB
ForEach ($node in $AGNodes)
{
    Get-AzureVM -ServiceName $ServiceName -Name $node | Add-AzureEndpoint -Name "ListenerEndpoint" -LBSetName "ListenerEndpointLB" -Protocol tcp -LocalPort 1433 -PublicPort 1433 -ProbePort 59999 -ProbeProtocol tcp -ProbeIntervalInSeconds 10 -InternalLoadBalancerName $ILBName -DirectServerReturn $true | Update-AzureVM
}

Nadat u de variabelen hebt ingesteld, kopieert u het script vanuit de teksteditor naar uw PowerShell-sessie om het uit te voeren. Als de prompt nog steeds wordt weergegeven >>, drukt u nogmaals op Enter om te controleren of het script wordt uitgevoerd.

Controleer of KB2854082 zo nodig is geïnstalleerd

Als op servers in het cluster Vervolgens Windows Server 2008 R2 of Windows Server 2012 wordt uitgevoerd, moet u controleren of de hotfix KB2854082 is geïnstalleerd op elk van de on-premises servers of Azure-VM's die deel uitmaken van het cluster. Elke server of VM die zich in het cluster bevindt, maar niet in de beschikbaarheidsgroep, moet ook deze hotfix hebben geïnstalleerd.

Download KB2854082 in de sessie extern bureaublad voor elk van de clusterknooppunten naar een lokale map. Installeer vervolgens de hotfix op elk clusterknooppunt opeenvolgend. Als de clusterservice momenteel wordt uitgevoerd op het clusterknooppunt, wordt de server opnieuw opgestart aan het einde van de hotfix-installatie.

Waarschuwing

Het stoppen van de clusterservice of het opnieuw opstarten van de server is van invloed op de quorumstatus van uw cluster en de beschikbaarheidsgroep. Dit kan ertoe leiden dat uw cluster offline gaat. Als u de hoge beschikbaarheid van uw cluster tijdens de installatie wilt behouden, moet u ervoor zorgen dat:

Het cluster heeft de optimale quorumstatus.
Voordat u de hotfix op een knooppunt installeert, zijn alle clusterknooppunten online.
Voordat u de hotfix installeert op een ander knooppunt in het cluster, staat u toe dat de hotfixinstallatie wordt uitgevoerd op één knooppunt, inclusief het volledig opnieuw opstarten van de server.

Open de firewallpoorten in beschikbaarheidsgroepknooppunten

In deze stap maakt u een firewallregel om de testpoort te openen voor het eindpunt met gelijke taakverdeling (59999, zoals eerder opgegeven) en een andere regel om de listenerpoort voor de beschikbaarheidsgroep te openen. Omdat u het eindpunt met taakverdeling hebt gemaakt op de VM's die replica's van de beschikbaarheidsgroep bevatten, moet u de testpoort en de listenerpoort op de respectieve VM's openen.

Start Windows Firewall met Geavanceerde beveiliging op VM's die replica's hosten.
Met de rechtermuisknop op regels voor binnenkomende verbindingen, en klik vervolgens op nieuwe regel.
Selecteer Poort op de pagina Regeltype en klik vervolgens op Volgende.
Selecteer TCP op de pagina Protocol en poorten, typ 59999 in het vak Specifieke lokale poorten en klik vervolgens op Volgende.
Houd op de pagina Actiede verbinding toestaan geselecteerd en klik vervolgens op Volgende.
Accepteer op de pagina Profiel de standaardinstellingen en klik vervolgens op Volgende.
Geef op de pagina Naam in het tekstvak Naam een regelnaam op, zoals alwayson-listenertestpoort, en klik vervolgens op Voltooien.
Herhaal de voorgaande stappen voor de listenerpoort van de beschikbaarheidsgroep (zoals eerder opgegeven in de parameter $EndpointPort van het script) en geef vervolgens een juiste regelnaam op, zoals AlwaysOn-listenerpoort.

De listener voor beschikbaarheidsgroep maken

Maak de listener voor beschikbaarheidsgroepen in twee stappen. Maak eerst de clusterresource van het clienttoegangspunt en configureer afhankelijkheden. Configureer ten tweede de clusterbronnen in PowerShell.

Het clienttoegangspunt maken en de clusterafhankelijkheden configureren

In deze stap maakt u handmatig de listener voor beschikbaarheidsgroepen in Failoverclusterbeheer en SQL Server Management Studio.

Open Failoverclusterbeheer vanuit het knooppunt dat als host fungeert voor de primaire replica.
Selecteer het knooppunt Netwerken en noteer de naam van het clusternetwerk. Deze naam wordt gebruikt in de $ClusterNetworkName variabele in het PowerShell-script.
Vouw de clusternaam uit en klik vervolgens op Rollen.
Klik in het deelvenster Rollen met de rechtermuisknop op de beschikbaarheidsgroepnaam en selecteer Resource toevoegen>Clienttoegangspunt.
Maak in het vak Naam een naam voor deze nieuwe listener, klik tweemaal op Volgende en klik vervolgens op Voltooien.
Breng de listener of resource op dit moment nog niet online.
Klik op het tabblad Resources en vouw vervolgens het clienttoegangspunt uit dat u zojuist hebt gemaakt. De IP-adresresource voor elk clusternetwerk in uw cluster wordt weergegeven. Als dit een alleen-Azure-oplossing is, wordt er slechts één IP-adresresource weergegeven.
Gebruik een van de volgende methoden:
- Een hybride oplossing configureren:
  
  a. Klik met de rechtermuisknop op de IP-adresresource die overeenkomt met uw on-premises subnet en selecteer vervolgens Eigenschappen. Noteer de IP-adresnaam en netwerknaam.
  
  b. Selecteer Statisch IP-adres, wijs een ongebruikt IP-adres toe en klik vervolgens op OK.
- Een alleen-Azure-oplossing configureren:
  
  a. Klik met de rechtermuisknop op de IP-adresresource die overeenkomt met uw Azure-subnet en selecteer vervolgens Eigenschappen.
  
  Notitie
  
  Als de listener later niet online komt vanwege een conflicterend IP-adres dat is geselecteerd door DHCP, kunt u een geldig statisch IP-adres configureren in dit eigenschappenvenster.
  
  b. Wijzig in hetzelfde venster ip-adreseigenschappen de naam van het IP-adres.
  Deze naam wordt gebruikt in de $IPResourceName variabele van het PowerShell-script. Als uw oplossing meerdere virtuele Azure-netwerken omvat, herhaalt u deze stap voor elke IP-resource.

De clusterbronnen configureren in PowerShell

Voor ILB moet u het IP-adres van de eerder gemaakte ILB gebruiken. Gebruik het volgende script om dit IP-adres te verkrijgen in PowerShell:

# Define variables
$ServiceName="<MyServiceName>" # the name of the cloud service that contains the AG nodes
(Get-AzureInternalLoadBalancer -ServiceName $ServiceName).IPAddress

Kopieer op een van de VM's het PowerShell-script voor uw besturingssysteem naar een teksteditor en stel de variabelen in op de waarden die u eerder hebt genoteerd.

Gebruik het volgende script voor Windows Server 2012 of hoger:

# Define variables
$ClusterNetworkName = "<MyClusterNetworkName>" # the cluster network name (Use Get-ClusterNetwork on Windows Server 2012 of higher to find the name)
$IPResourceName = "<IPResourceName>" # the IP address resource name
$ILBIP = "<X.X.X.X>" # the IP address of the ILB

Import-Module FailoverClusters

Get-ClusterResource $IPResourceName | Set-ClusterParameter -Multiple @{"Address"="$ILBIP";"ProbePort"="59999";"SubnetMask"="255.255.255.255";"Network"="$ClusterNetworkName";"EnableDhcp"=0}

Gebruik voor Windows Server 2008 R2 het volgende script:

# Define variables
$ClusterNetworkName = "<MyClusterNetworkName>" # the cluster network name (Use Get-ClusterNetwork on Windows Server 2012 of higher to find the name)
$IPResourceName = "<IPResourceName>" # the IP address resource name
$ILBIP = "<X.X.X.X>" # the IP address of the ILB

Import-Module FailoverClusters

cluster res $IPResourceName /priv enabledhcp=0 address=$ILBIP probeport=59999  subnetmask=255.255.255.255

Nadat u de variabelen hebt ingesteld, opent u een venster met verhoogde bevoegdheid Windows PowerShell, plakt u het script vanuit de teksteditor in uw PowerShell-sessie om het uit te voeren. Als de prompt nog steeds wordt weergegeven >>, drukt u nogmaals op Enter om ervoor te zorgen dat het script wordt uitgevoerd.
Herhaal de voorgaande stappen voor elke VIRTUELE machine.
Met dit script configureert u de IP-adresresource met het IP-adres van de cloudservice en stelt u andere parameters in, zoals de testpoort. Wanneer de IP-adresresource online wordt gebracht, kan deze reageren op de polling op de testpoort vanaf het eindpunt met gelijke taakverdeling dat u eerder hebt gemaakt.

De listener online brengen

Vouw in Failoverclusterbeheer rollen uit en markeer vervolgens uw beschikbaarheidsgroep.
Klik op het tabblad Resources met de rechtermuisknop op de naam van de listener en klik vervolgens op Eigenschappen.
Klik op het tabblad Afhankelijkheden . Als er meerdere resources worden vermeld, controleert u of de IP-adressen OR, niet EN, afhankelijkheden hebben.
Klik op OK.
Klik met de rechtermuisknop op de naam van de listener en klik vervolgens op Bring Online.
Nadat de listener online is, klikt u op het tabblad Resources met de rechtermuisknop op de beschikbaarheidsgroep en klikt u vervolgens op Eigenschappen.
Maak een afhankelijkheid van de naamresource van de listener (niet de naam van de IP-adresresources) en klik vervolgens op OK.
Start SQL Server Management Studio en maak vervolgens verbinding met de primaire replica.
Ga naar AlwaysOn High Availability>><Groups Availability Groups AvailabilityGroupName>>Availability Group Listeners.
De naam van de listener die u hebt gemaakt in Failoverclusterbeheer, moet worden weergegeven.
Klik met de rechtermuisknop op de naam van de listener en klik vervolgens op Eigenschappen.
Geef in het vak Poort het poortnummer voor de listener voor de beschikbaarheidsgroep op met behulp van de $EndpointPort die u eerder hebt gebruikt (in deze zelfstudie was 1433 de standaardinstelling) en klik vervolgens op OK.

Opvolgingsitems

Nadat u de listener voor de beschikbaarheidsgroep hebt gemaakt, is het mogelijk nodig om de clusterparameters RegisterAllProvidersIP en HostRecordTTL voor de listener-resource aan te passen. Deze parameters kunnen de tijd voor opnieuw verbinden verminderen na een failover, waardoor verbindingstime-outs mogelijk worden voorkomen. Zie Een listener voor een beschikbaarheidsgroep maken of configureren voor meer informatie over deze parameters en voorbeeldcode.

De listener van de beschikbaarheidsgroep testen (binnen hetzelfde virtuele netwerk)

In deze stap test u de listener van de beschikbaarheidsgroep met behulp van een clienttoepassing die wordt uitgevoerd op hetzelfde netwerk.

Clientconnectiviteit heeft de volgende vereisten:

Clientverbindingen met de listener moeten afkomstig zijn van computers die zich in een andere cloudservice bevinden dan die waarop de AlwaysOn-beschikbaarheidsreplica's worden gehost.
Als de AlwaysOn-replica's zich in verschillende subnetten bevinden, moeten clients MultisubnetFailover=True opgeven in de connection string. Deze voorwaarde resulteert in parallelle verbindingspogingen naar replica's in de verschillende subnetten. Dit scenario omvat een implementatie van een AlwaysOn-beschikbaarheidsgroep voor meerdere regio's.

Een voorbeeld is om verbinding te maken met de listener vanaf een van de VM's in hetzelfde virtuele Azure-netwerk (maar niet één die als host fungeert voor een replica). Een eenvoudige manier om deze test te voltooien, is door te proberen SQL Server Management Studio verbinding te maken met de listener van de beschikbaarheidsgroep. Een andere eenvoudige methode is omSQLCMD.exeuit te voeren, als volgt:

sqlcmd -S "<ListenerName>,<EndpointPort>" -d "<DatabaseName>" -Q "select @@servername, db_name()" -l 15

Notitie

Als de EndpointPort-waarde 1433 is, hoeft u deze niet op te geven in de aanroep. Bij de vorige aanroep wordt ook ervan uitgegaan dat de clientcomputer lid is van hetzelfde domein en dat de aanroeper machtigingen heeft gekregen voor de database met behulp van Windows-verificatie.

Wanneer u de listener test, moet u een failover uitvoeren voor de beschikbaarheidsgroep om ervoor te zorgen dat clients verbinding kunnen maken met de listener via failovers.

Volgende stappen

Naast het automatisch verbinden van clients met de primaire replica, kan een listener worden gebruikt om alleen-lezenworkloads om te leiden naar de secundaire bestanden. Dit gebruik kan de prestaties en schaalbaarheid van uw algehele oplossing verbeteren. Zie ReadIntent Routing gebruiken met azure AlwaysOn-listener voor beschikbaarheidsgroepen voor meer informatie.