Failover automatico gruppo di disponibilità AlwaysOn non funziona

Giocando con la configurazione di AG ho il WSFC attivo e configurato con due nodi in un gruppo di disponibilità chiamato DevClusterOnline. Entrambi i nodi (DEV-AWEB5 primario, DEV-AWEB6 secondario) eseguono Windows Server 2008 R2.

Se controllo lo stato della mia AG ottengo questo:

L'esecuzione della query seguente restituirà questo set di risultati:

select
    ar.replica_server_name,
    availability_group_name = ag.name,
    ar.availability_mode_desc,
    ar.failover_mode_desc
from sys.availability_replicas ar
inner join sys.availability_groups ag
on ar.group_id = ag.group_id
order by availability_group_name, replica_server_name;

Se disconnetto DEV-AWEB5, non riesco a collegarmi al Listener di gruppo (DevListener), ma posso eseguire il ping e risponderà al mio ping. La replica - DEV-AWEB6 entra in uno stato di RISOLUZIONE e il mio DB è inaccessibile. Tuttavia, posso accedere manualmente a Management Studio e impostare Failover su DEV-AWEB6, quindi sono di nuovo attivo e funzionante e DevListener accetterà ancora una volta le connessioni.

Considerando che questi fatti confermano che il failover funziona effettivamente, che ho sincronizzato i commit e configurato il failover automatico, non ho idea di cosa succede se il malfunzionamento nella mia configurazione.

Quando disconnetto DEV-AWEB5 mi aspetto che la mia replica mantenga la connessione e quindi anche DevListener. Mi aspetto che il failover automatico mi consenta di collegarmi all'AG Listener in modo trasparente. Dal punto di vista dell'utente finale, utilizzando un sistema Web non dovrebbe essere evidente che uno dei server DB non funziona.

Sono bloccato qui, qualcuno può per favore illuminarmi su ciò che sto facendo di sbagliato?

Se disconnetto DEV-AWEB5

Definisci "disconnetti", se vuoi. Suppongo che tu abbia tenuto la scatola aperta ma hai rimosso SQL Server.

Non riesco a collegarmi al Listener di gruppo (DevListener), ma posso eseguire il ping e risponderà al mio ping

Questo perché il listener è solo un nome di rete virtuale (VNN) all'interno del gruppo di risorse del cluster WSFC per il gruppo di disponibilità rappresentato. Il nodo DEV_AWEB5 possiede ancora il gruppo di risorse del cluster, ma è probabilmente solo la risorsa del cluster AG che si trova in uno stato non riuscito. Il VNN deve essere ancora online (comportamento previsto). Sta semplicemente indicando qualunque nodo possieda quel gruppo di risorse (in questo caso, DEV-AWEB5). In effetti, se il remoting di PowerShell era abilitato e si eseguiva quanto segue:

Invoke-Command -ComputerName "YourListenerName" -ScriptBlock { $env:computername }

Allo stesso modo, se puoi RDP in DEV-AWEB5 (a condizione che tu abbia la capacità e l'accessibilità, ecc.) Allora sarai in grado di RDP usando il nome dell'ascoltatore ( mstsc /v:YourListenerName). È solo un VNN.

Il ritorno sarebbe il nome del computer del tuo nodo proprietario.

Con tutti i tuoi sintomi, sarei disposto a scommettere che hai raggiunto la soglia di failover. La soglia di failover determina quante volte il cluster tenterà di eseguire il failover del gruppo di risorse in un periodo di tempo specificato. Il valore predefinito di questi valori max failover n - 1 (dove n è il conteggio dei nodi) in un periodo di 6 ore . Puoi vederlo tramite il seguente comando WSFC PowerShell:

Get-ClusterGroup -Name "YourAgName" |
    Select-Object Name, FailoverThreshold, FailoverPeriod

Questo ti dà solo le impostazioni (che puoi modificare se lo desideri, ovviamente).

Il modo migliore per dimostrare che questo è il tuo caso, è necessario generare il registro del cluster (i registri degli eventi di sistema vanno solo nei dettagli fino a quando "non è riuscito" o qualcosa del genere).

Get-ClusterLog -Node "YourClusterNode" -TimeSpan <amount_of_minutes_since_failure>

Per impostazione predefinita, verrà inserito nella cartella "C: \ Windows \ Cluster \ Reports" e il file si chiama "Cluster.log".

Se dovessi aprire quel registro del cluster, dovresti essere in grado di trovare la seguente stringa, indicando esattamente cosa è successo e perché è successo:

Non eseguire il failover sul gruppo [YourClusterGroupName] , failoverCount [# numero di failover] , soglia di failover [valore soglia di failover] , nodeAvailCount [conteggio nodi disponibili ].

Il messaggio sopra è semplicemente WSFC che ti dice che non eseguirà il failover del tuo gruppo perché è successo troppo (hai raggiunto la soglia).

Perché succede? Semplicemente per evitare che l'effetto Ping-Pong delle risorse del cluster vada avanti e indietro troppo frequentemente tra i nodi.

Mentre questo sarebbe comune superare queste soglie nei test di failover, nella produzione indicherebbe in genere un problema che dovrebbe essere studiato.

L'aggiunta di MSSQL come risorsa di servizio generico non è la risposta.

Ciò metterà semplicemente il Cluster Manager a capo del Servizio SQL Server, OK, sì, si verificherà automaticamente il failover, ma noterai in SQL Server Configuration Manager che i tuoi servizi sono ora impostati su "Manuale" indicando che il Cluster Manager è ora sotto controllo del tuo servizio SQL Server.

Stai mettendo Cluster Manager a capo di un'applicazione NON cluster.

Finirà in lacrime.

L'approccio corretto è quello di configurare correttamente i gruppi di disponibilità di SQL Server come da documentazione MS.

Inoltre, assicurarsi di non superare i parametri di failover come definito in Gestione cluster> Ruoli> Scheda Failover.

Se si superano questi limiti, il cluster non eseguirà il failover delle risorse e verrà registrato un errore nel registro eventi dell'applicazione.