IaaS con SQL Server - Ottimizzazione delle soglie di rete del cluster di failover

Questo articolo introduce soluzioni per modificare la soglia delle reti del cluster di failover.

Sintomo

Quando si eseguono nodi del cluster di failover Windows in IaaS con un gruppo di disponibilità SQL Server Always On, è consigliabile modificare l'impostazione del cluster in uno stato di monitoraggio più rilassato. Le impostazioni del cluster predefinite sono restrittive e potrebbero causare interruzioni non necessari. Le impostazioni predefinite sono progettate per l'ottimizzazione elevata nelle reti locali e non tengono conto della possibilità di latenza indotto causata da un ambiente multi-tenant, ad esempio Microsoft Azure (IaaS).

Il clustering di failover di Windows Server monitora costantemente le connessioni di rete e l'integrità dei nodi in un cluster Windows. Se un nodo non è raggiungibile in rete, viene eseguita un'azione di ripristino per ripristinare e portare online applicazioni e servizi in un altro nodo del cluster. La latenza nella comunicazione tra nodi del cluster può causare l'errore seguente:

Errore 1135 (registro eventi di sistema)

Il nodo del cluster Nodo 1 è stato rimosso dall'appartenenza al cluster di failover attivo. Il servizio cluster in questo nodo potrebbe essere stato arrestato. Ciò potrebbe essere dovuto anche alla perdita della comunicazione del nodo con altri nodi attivi nel cluster di failover. Eseguire la Convalida guidata configurazione per controllare la configurazione di rete. Se la condizione persiste, verificare la presenza di errori hardware o software correlati alle schede di rete in questo nodo. Controllare anche la presenza di errori in qualsiasi altro componente di rete a cui è connesso il nodo, ad esempio hub, commutatori o bridge.

Cluster.log esempio:

0000ab34.00004e64::2014/06/10-07:54:34.099 DBG   [NETFTAPI] Signaled NetftRemoteUnreachable event, local address 10.xx.x.xxx:3343 remote address 10.x.xx.xx:3343
0000ab34.00004b38::2014/06/10-07:54:34.099 INFO  [IM] got event: Remote endpoint 10.xx.xx.xxx:~3343~ unreachable from 10.xx.x.xx:~3343~
0000ab34.00004b38::2014/06/10-07:54:34.099 INFO  [IM] Marking Route from 10.xxx.xxx.xxxx:~3343~ to 10.xxx.xx.xxxx:~3343~ as down
0000ab34.00004b38::2014/06/10-07:54:34.099 INFO  [NDP] Checking to see if all routes for route (virtual) local fexx::xxx:5dxx:xxxx:3xxx:~0~ to remote xxx::cxxx:xxxd:xxx:dxxx:~0~ are down
0000ab34.00004b38::2014/06/10-07:54:34.099 INFO  [NDP] All routes for route (virtual) local fxxx::xxxx:5xxx:xxxx:3xxx:~0~ to remote fexx::xxxx:xxxx:xxxx:xxxx:~0~ are down
0000ab34.00007328::2014/06/10-07:54:34.099 INFO  [CORE] Node 8: executing node 12 failed handlers on a dedicated thread
0000ab34.00007328::2014/06/10-07:54:34.099 INFO  [NODE] Node 8: Cleaning up connections for n12.
0000ab34.00007328::2014/06/10-07:54:34.099 INFO  [Nodename] Clearing 0 unsent and 15 unacknowledged messages.
0000ab34.00007328::2014/06/10-07:54:34.099 INFO  [NODE] Node 8: n12 node object is closing its connections
0000ab34.00008b68::2014/06/10-07:54:34.099 INFO  [DCM] HandleNetftRemoteRouteChange
0000ab34.00004b38::2014/06/10-07:54:34.099 INFO  [IM] Route history 1: Old: 05.936, Message: Response, Route sequence: 150415, Received sequence: 150415, Heartbeats counter/threshold: 5/5, Error: Success, NtStatus: 0 Timestamp: 2014/06/10-07:54:28.000, Ticks since last sending: 4
0000ab34.00007328::2014/06/10-07:54:34.099 INFO  [NODE] Node 8: closing n12 node object channels
0000ab34.00004b38::2014/06/10-07:54:34.099 INFO  [IM] Route history 2: Old: 06.434, Message: Request, Route sequence: 150414, Received sequence: 150402, Heartbeats counter/threshold: 5/5, Error: Success, NtStatus: 0 Timestamp: 2014/06/10-07:54:27.665, Ticks since last sending: 36
0000ab34.0000a8ac::2014/06/10-07:54:34.099 INFO  [DCM] HandleRequest: dcm/netftRouteChange
0000ab34.00004b38::2014/06/10-07:54:34.099 INFO  [IM] Route history 3: Old: 06.934, Message: Response, Route sequence: 150414, Received sequence: 150414, Heartbeats counter/threshold: 5/5, Error: Success, NtStatus: 0 Timestamp: 2014/06/10-07:54:27.165, Ticks since last sending: 4
0000ab34.00004b38::2014/06/10-07:54:34.099 INFO  [IM] Route history 4: Old: 07.434, Message: Request, Route sequence: 150413, Received sequence: 150401, Heartbeats counter/threshold: 5/5, Error: Success, NtStatus: 0 Timestamp: 2014/06/10-07:54:26.664, Ticks since last sending: 36

0000ab34.00007328::2014/06/10-07:54:34.100 INFO    <realLocal>10.xxx.xx.xxx:~3343~</realLocal>
0000ab34.00007328::2014/06/10-07:54:34.100 INFO    <realRemote>10.xxx.xx.xxx:~3343~</realRemote>
0000ab34.00007328::2014/06/10-07:54:34.100 INFO    <virtualLocal>fexx::xxxx:xxxx:xxxx:xxxx:~0~</virtualLocal>
0000ab34.00007328::2014/06/10-07:54:34.100 INFO    <virtualRemote>fexx::xxxx:xxxx:xxxx:xxxx:~0~</virtualRemote>
0000ab34.00007328::2014/06/10-07:54:34.100 INFO    <Delay>1000</Delay>
0000ab34.00007328::2014/06/10-07:54:34.100 INFO    <Threshold>5</Threshold>
0000ab34.00007328::2014/06/10-07:54:34.100 INFO    <Priority>140481</Priority>
0000ab34.00007328::2014/06/10-07:54:34.100 INFO    <Attributes>2147483649</Attributes>
0000ab34.00007328::2014/06/10-07:54:34.100 INFO  </struct mscs::FaultTolerantRoute>
0000ab34.00007328::2014/06/10-07:54:34.100 INFO   removed

0000ab34.0000a7c0::2014/06/10-07:54:38.433 ERR   [QUORUM] Node 8: Lost quorum (3 4 5 6 7 8)
0000ab34.0000a7c0::2014/06/10-07:54:38.433 ERR   [QUORUM] Node 8: goingAway: 0, core.IsServiceShutdown: 0
0000ab34.0000a7c0::2014/06/10-07:54:38.433 ERR   lost quorum (status = 5925)

Causa

Per configurare l'integrità della connettività del cluster vengono usate due impostazioni.

Ritardo : definisce la frequenza con cui gli heartbeat del cluster vengono inviati tra i nodi. Il ritardo è il numero di secondi prima dell'invio dell'heartbeat successivo. All'interno dello stesso cluster, possono esserci ritardi diversi tra i nodi nella stessa subnet e tra i nodi, che si trovano in subnet diverse.

Soglia : definisce il numero di heartbeat mancanti prima che il cluster esegua l'azione di ripristino. La soglia è costituita da un numero di heartbeat. All'interno dello stesso cluster possono essere presenti soglie diverse tra i nodi nella stessa subnet e tra i nodi che si trovano in subnet diverse.

Per impostazione predefinita Windows Server 2016 imposta SameSubnetThreshold su 10 e SameSubnetDelay su 1000 ms. Ad esempio, se il monitoraggio della connettività ha esito negativo per 10 secondi, viene raggiunta la soglia di failover, causando la rimozione del nodo dall'appartenenza al cluster. In questo modo le risorse vengono spostate in un altro nodo disponibile nel cluster. Verranno segnalati errori del cluster, incluso l'errore del cluster 1135 (sopra).

Risoluzione

Per risolvere questo problema, ridurre le impostazioni di configurazione della rete cluster. Vedere Heartbeat e soglia.

Riferimenti

Per altre informazioni sull'ottimizzazione delle impostazioni di configurazione della rete del cluster Windows, vedere Ottimizzazione delle soglie di rete del cluster di failover.

Per informazioni sull'uso dicluster.exe per ottimizzare le impostazioni di configurazione della rete del cluster Windows, vedere Come configurare le reti cluster per un cluster di failover.