Configurare un listener ILB per i gruppi di disponibilità in VM di SQL Server di Azure

Articolo
05/02/2017

Panoramica

Importante

Azure offre due modelli di distribuzione diversi per creare e usare le risorse: Azure Resource Manager e distribuzione classica. In questo articolo viene illustrato l'uso del modello di distribuzione classica. Per le distribuzioni più recenti si consiglia di usare il modello di Resource Manager.

Per configurare un listener per un gruppo di disponibilità AlwaysOn nel modello di Resource Manager, vedere Configurare un servizio di bilanciamento del carico per un gruppo di disponibilità AlwaysOn in Azure.

Il gruppo di disponibilità può contenere repliche solo locali, solo di Azure oppure sia locali che di Azure per le configurazioni ibride. Le repliche di Azure possono trovarsi nella stessa area o in più aree grazie a più reti virtuali. Le procedure riportate in questo articolo presuppongono che sia già stato configurato un gruppo di disponibilità ma che non sia stato configurato un listener.

Linee guida e limitazioni per listener interni

L'uso di un servizio di bilanciamento del carico interno con un listener del gruppo di disponibilità in Azure è soggetto alle seguenti linee guida:

Il listener del gruppo di disponibilità è supportato su Windows Server 2008 R2, Windows Server 2012 e Windows Server 2012 R2.
Per ogni servizio cloud è supportato un solo listener del gruppo di disponibilità interno, perché il listener è configurato solo per ILB, e c'è un solo ILB per ogni servizio cloud. Tuttavia, è possibile creare più listener esterni. Per altre informazioni, vedere Configurare un listener esterno per i gruppi di disponibilità AlwaysOn in Azure.

Determinare l'accessibilità del listener

È importante tenere presente che esistono due modi per configurare un listener del gruppo di disponibilità in Azure. Questi metodi differiscono nel tipo di servizio di bilanciamento del carico di Azure usato quando si crea il listener. Nella tabella seguente sono descritte le differenze:

Tipo di servizio di bilanciamento del carico	Implementazione	Utilizzare quando:
Esterno	Usa l'indirizzo IP virtuale pubblico del servizio cloud che ospita le macchine virtuali.	È necessario accedere al listener dall'esterno della rete virtuale, ad esempio da Internet.
Interno	Usa un servizio di bilanciamento del carico interno con un indirizzo privato per il listener.	È possibile accedere al listener solo dall'interno della stessa rete virtuale. Questa modalità di accesso include la VPN da sito a sito in scenari ibridi.

Importante

Per un listener che usa l'indirizzo VIP pubblico del servizio cloud (servizio di bilanciamento del carico esterno), non si incorrerà in spese di uscita fin quando il client, il listener e i database si troveranno nella stessa area di Azure. In caso contrario, i dati restituiti tramite il listener vengono considerati in uscita e vengono addebitati i normali costi di trasferimento dati.

Un servizio di bilanciamento del carico interno può essere configurato solo nelle reti virtuali con ambito a livello di area. Le reti virtuali esistenti che sono state configurate per un gruppo di affinità non possono usare un servizio di bilanciamento del carico interno. Per altre informazioni, vedere Panoramica del bilanciamento del carico interno.

Questo articolo illustra la creazione di un listener che usa un servizio di bilanciamento del carico interno. Se è necessario un listener pubblico/esterno, vedere la versione di questo articolo che tratta la procedura per la configurazione di un listener esterno.

Creare endpoint VM con bilanciamento del carico con Direct Server Return

Creare innanzitutto un servizio di bilanciamento del carico interno eseguendo lo script riportato più avanti in questa sezione.

Creare un endpoint con carico bilanciato per ogni VM che ospita una replica di Azure. Se si hanno repliche in più aree, ogni replica per tale area deve essere nello stesso servizio cloud nella stessa rete virtuale di Azure. La creazione di repliche del gruppo di disponibilità che si estendono su più aree di Azure richiede la configurazione di più reti virtuali. Per informazioni sulla configurazione della connettività fra reti virtuali, vedere Configurare una connessione da rete virtuale a rete virtuale.

Nel portale di Azure passare a ogni VM che ospita una replica per vedere i dettagli.
Scegliere la scheda Endpoint per ogni VM.
Verificare che il nome e la porta pubblica specificati per l'endpoint del listener non siano già in uso. Nell'esempio di questa sezione il nome è MyEndpoint e la porta è 1433.
Nel client locale scaricare e installare l'ultimo modulo PowerShell.
Avviare Azure PowerShell.
Viene aperta una nuova sessione di PowerShell con i moduli amministrativi di Azure caricati.
Eseguire Get-AzurePublishSettingsFile. Questo cmdlet conduce a un browser per scaricare un file di impostazioni di pubblicazione in una directory locale. Potrebbero essere richieste le credenziali di accesso per la sottoscrizione di Azure.
Eseguire il comando Import-AzurePublishSettingsFile seguente con il percorso del file delle impostazioni di pubblicazione scaricato:
```
Import-AzurePublishSettingsFile -PublishSettingsFile <PublishSettingsFilePath>
```
Dopo aver importato il file delle impostazioni di pubblicazione, è possibile gestire la sottoscrizione di Azure nella sessione di PowerShell.
Per ILB assegnare un indirizzo IP statico. Esaminare la configurazione attuale della rete virtuale eseguendo il comando seguente:
```
(Get-AzureVNetConfig).XMLConfiguration
```
Annotare il nome Subnet per la subnet contenente le VM che ospitano le repliche. Questo nome viene usato nel parametro $SubnetName nello script.
Annotare il valore VirtualNetworkSite e il valore iniziale AddressPrefix per la subnet contenente le VM che ospitano le repliche. Cercare un indirizzo IP disponibile passando entrambi i valori al comando Test-AzureStaticVNetIP ed esaminando il valore AvailableAddresses. Se, ad esempio, il nome della rete virtuale è MyVNet e l'inizio dell'intervallo di indirizzi della subnet corrisponde a 172.16.0.128, il comando seguente elencherà gli indirizzi disponibili:
```
(Test-AzureStaticVNetIP -VNetName "MyVNet"-IPAddress 172.16.0.128).AvailableAddresses
```
Selezionare uno degli indirizzi disponibili e usarlo nel parametro $ILBStaticIP dello script al passaggio seguente.

Copiare lo script di PowerShell seguente in un editor di testo e impostare i valori delle variabili in base all'ambiente. Per alcuni parametri sono stati forniti valori predefiniti.

Le distribuzioni esistenti che usano i gruppi di affinità non potranno aggiungere un servizio di bilanciamento del carico interno. Per altre informazioni sui requisiti per il servizio di bilanciamento del carico interno, vedere la panoramica del bilanciamento del carico interno.

Se il gruppo di disponibilità si estende tra diverse aree di Azure, è necessario eseguire lo script una volta in ogni data center per il servizio cloud e i nodi che risiedono nel data center.

# 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
}

Dopo aver impostato le variabili, copiare lo script dall'editor di testo nella sessione di PowerShell per eseguirlo. Se nel prompt viene ancora visualizzato >> , digitare di nuovo INVIO per assicurarsi che l'esecuzione dello script sia stata avviata.

Se necessario, verificare che KB2854082 sia installato.

Se i server nel cluster stanno eseguendo Windows Server 2008 R2 o Windows Server 2012, è necessario quindi verificare che l'hotfix KB2854082 sia installato su ognuno dei server locali o sulle VM di Azure che fanno parte del cluster. Qualsiasi server o macchina virtuale che si trova nel cluster, ma non nel gruppo di disponibilità, deve avere installato tale hotfix.

Nella sessione desktop remota per ciascuno dei nodi del cluster, scaricare KB2854082 in una directory locale. Quindi, installare l'hotfix in ogni nodo del cluster in modo sequenziale. Se il servizio cluster è in esecuzione nel nodo del cluster, il server viene riavviato al termine dell'installazione dell'hotfix.

Avviso

L'arresto del servizio cluster o il riavvio del server influiscono sull'integrità del quorum del cluster e del gruppo di disponibilità e possono portare il cluster offline. Per mantenere la disponibilità elevata del cluster durante l'installazione, verificare quanto segue:

Il cluster è in stato di quorum ottimale.
Prima dell'installazione dell'hotfix in qualsiasi nodo, tutti i nodi del cluster sono online.
Prima di installare l'hotfix in altri nodi del cluster, è necessario consentire il completamento dell'esecuzione dell'installazione dell'hotfix in un nodo, incluso il riavvio completo del server.

Aprire le porte firewall nei nodi del gruppo di disponibilità in

In questo passaggio si creerà una regola del firewall per aprire la porta probe per l'endpoint con carico bilanciato (59999, come specificato in precedenza) e un'altra regola per aprire la porta del listener del gruppo disponibilità. Poiché è stato creato l'endpoint con carico bilanciato nelle VM contenenti repliche del gruppo di disponibilità, è necessario aprire la porta probe e la porta del listener sulle rispettive macchine virtuali.

Nelle macchine virtuali che ospitano le repliche, avviare Windows Firewall con sicurezza avanzata.
Fare clic con il pulsante destro del mouse su Regole in entrata e quindi scegliere Nuova regola.
Nella pagina Tipo di regola selezionare Porta e quindi fare clic su Avanti.
Nella pagina Protocollo e porte selezionare TCP, digitare 59999 nella casella Porte locali specifiche e quindi fare clic su Avanti.
Nella pagina Azione mantenere selezionata l'opzione Consenti la connessione e fare clic su Avanti.
Nella pagina Profilo accettare le impostazioni predefinite e fare clic su Avanti.
Nella pagina Nome specificare nella casella di testo Nome un nome per la regola, ad esempio Porta probe del listener AlwaysOn e quindi fare clic su Fine.
Ripetere i passaggi precedenti per la porta del listener del gruppo di disponibilità (come specificato in precedenza nel parametro $EndpointPort dello script) e specificare un nome di regola appropriato, ad esempio Porta del Listener AlwaysOn.

Creare il listener del gruppo di disponibilità

Creare il listener del gruppo di disponibilità in due passaggi. Creare prima di tutto la risorsa del cluster del punto di accesso client e configurare le dipendenze. Come seconda cosa, configurare le risorse del cluster in PowerShell.

Creare il punto di accesso client e configurare le dipendenze del cluster

In questo passaggio si creerà manualmente il listener del gruppo di disponibilità in Gestione cluster di failover e SQL Server Management Studio.

Aprire Gestione cluster di failover dal nodo che ospita la replica primaria.
Selezionare il nodo Reti e quindi annotare il nome di rete del cluster. Questo nome viene usato nella variabile $ClusterNetworkName nello script di PowerShell.
Espandere il nome del cluster, quindi fare clic su Ruoli.
Nel pannello Ruoli fare clic con il pulsante destro del mouse sul nome del gruppo di disponibilità e quindi scegliere Aggiungi risorsa>Punto di accesso client.
Nella casella Nome creare un nome per il nuovo listener, fare clic su Avanti due volte, quindi fare clic su Fine.
Non portare il listener o la risorsa in linea a questo punto.
Scegliere la scheda Risorse, e quindi espandere il punto di accesso client appena creato. Viene visualizzata la risorsa indirizzo IP per ogni rete di cluster nel cluster. Se si tratta di una soluzione solo per Azure, viene visualizzata solo una risorsa indirizzo IP.
Effettuare una delle operazioni seguenti:
- Per configurare una soluzione ibrida:
  
  a. Fare clic con il pulsante destro del mouse sulla risorsa indirizzo IP che corrisponde alla subnet locale e quindi scegliere Proprietà. Annotare il nome dell'indirizzo IP e il nome di rete.
  
  b. Selezionare Indirizzo IP statico, assegnare un indirizzo IP non usato e quindi fare clic su OK.
- Per configurare una soluzione solo per Azure:
  
  a. Fare clic con il pulsante destro del mouse sulla risorsa indirizzo IP corrispondente alla subnet di Azure e quindi selezionare Proprietà.
  
  Nota
  
  Se il listener non riesce in un secondo momento a portarsi in linea a causa di un indirizzo IP in conflitto selezionato da DHCP, è possibile configurare un indirizzo IP statico valido in questa finestra Proprietà.
  
  b. Nella stessa finestra delle proprietà di Indirizzo IP modificare il valore per Nome indirizzo IP.
  Questo nome viene usato nella variabile $IPResourceName dello script di PowerShell. Se la soluzione si estende in più reti virtuali di Azure, ripetere questo passaggio per ogni risorsa IP.

Configurare le risorse del cluster in PowerShell

Per il servizio di bilanciamento del carico interno è necessario usare l'indirizzo IP del servizio di bilanciamento del carico interno creato in precedenza. Usare lo script seguente per ottenere questo indirizzo IP in PowerShell:
```
# Define variables
$ServiceName="<MyServiceName>" # the name of the cloud service that contains the AG nodes
(Get-AzureInternalLoadBalancer -ServiceName $ServiceName).IPAddress
```

Su una delle VM copiare lo script di PowerShell del sistema operativo in un editor di testo quindi impostare le variabili sui valori annotati prima.

Per Windows Server 2012 o versione successiva usare lo script seguente:

# 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}

Per Windows Server 2008 R2 usare lo script seguente:

# 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

Dopo aver impostato le variabili, aprire una finestra con privilegi elevati di Windows PowerShell, incollare lo script dall'editor di testo nella sessione di PowerShell per eseguirlo. Se nel prompt viene ancora visualizzato >> , digitare di nuovo INVIO per assicurarsi che l'esecuzione dello script sia stata avviata.
Ripetere i passaggi precedenti per ciascuna VM.
Questo script consente di configurare la risorsa Indirizzo IP con l'indirizzo IP del servizio cloud e di impostare altri parametri come la porta probe. Quando la risorsa Indirizzo IP viene portata online, può rispondere al polling sulla porta probe dall'endpoint con carico bilanciato, creato in precedenza.

Portare online il listener

In Gestione cluster di failover espandere Ruoli e quindi evidenziare il gruppo di disponibilità.
Nella scheda Risorse fare clic con il pulsante destro del mouse sul nome del listener e scegliere Proprietà.
Fare clic sulla scheda Dipendenze . Se sono elencate più risorse, verificare che gli indirizzi IP abbiano OR, non AND, dipendenze.
Fare clic su OK.
Fare clic con il pulsante destro del mouse sul nome del listener e quindi scegliere Porta online.
Quando il listener è online, nella scheda Risorse fare clic con il pulsante destro del mouse sul gruppo di disponibilità e quindi scegliere Proprietà.
Creare una dipendenza nella risorsa nome del listener, non il nome della risorsa indirizzo IP, e quindi fare clic su OK.
Avviare SQL Server Management Studio e connettersi alla replica primaria.
Passare a Gruppi di disponibilità elevata >AlwaysOnAvailabilityGroupName><>>Listener del gruppo di disponibilità.
Verrà visualizzato il nome del listener creato in Gestione cluster di failover.
Fare clic con il pulsante destro del mouse sul nome del listener e quindi su Proprietà.
Nella casella Porta specificare il numero di porta per il listener del gruppo di disponibilità usando il valore di $EndpointPort usato in precedenza e quindi fare clic su OK. In questa esercitazione 1433 era l'impostazione predefinita.

Operazioni di completamento della procedura

Dopo aver creato il listener del gruppo di disponibilità, può essere necessario regolare i parametri cluster RegisterAllProvidersIP e HostRecordTTL per la risorsa listener. Questi parametri possono ridurre il tempo di riconnessione dopo un failover che può impedire i timeout di connessione. Per altre informazioni su questi parametri e sull'esempio di codice, vedere Creare o configurare un listener del gruppo di disponibilità.

Testare il listener del gruppo di disponibilità (entro la stessa rete virtuale)

In questo passaggio si testa il listener del gruppo di disponibilità usando un'applicazione client in esecuzione nella stessa rete.

Questi sono i requisiti per la connettività client:

Le connessioni client al listener devono provenire da computer che si trovano in un servizio cloud diverso da quello che ospita le repliche di disponibilità AlwaysOn.
Se le repliche AlwaysOn si trovano in subnet diverse, i client devono specificare MultisubnetFailover=True nella stringa di connessione. Questa condizione comporta l'esecuzione di tentativi di connessione paralleli alle repliche nelle diverse subnet. Questo scenario include la distribuzione di un gruppo di disponibilità AlwaysOn tra più aree.

È ad esempio possibile connettersi al listener da una delle macchine virtuali nella stessa rete virtuale di Azure (ma non quello che ospita una replica). Un modo semplice per completare questo test consiste nel provare a connettere SQL Server Management Studio al listener del gruppo di disponibilità. Un altro metodo semplice consiste nell'eseguire SQLCMD.exe, come segue:

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

Nota

Se il valore EndpointPort è 1433, non è necessario specificarlo nella chiamata. La chiamata precedente presuppone inoltre che il computer client sia aggiunto allo stesso dominio e che al chiamante siano state concesse autorizzazioni per il database tramite l'autenticazione di Windows.

Durante il test del listener, eseguire il failover del gruppo di disponibilità per assicurarsi che i client possano connettersi al listener attraverso i failover.

Passaggi successivi

Oltre a connettere automaticamente i client per la replica primaria, è possibile usare un listener per reindirizzare i carichi di lavoro di sola lettura ai database secondari. Questo approccio può migliorare le prestazioni e la scalabilità della soluzione globale. Per altre informazioni, vedere Use ReadIntent Routing with Azure Always On availability group listener (Usare ReadIntent Routing con il listener del gruppo di disponibilità AlwaysOn di Azure).