Condividi tramite

Ottimizzazione delle soglie di rete del cluster di failover

  • Articolo

Questo articolo presenta le soluzioni per modificare le soglie delle impostazioni di rete del cluster di failover. L'aumento dei valori di queste impostazioni potrebbe contribuire a ridurre la sensibilità del cluster a problemi di rete temporanei.

Sintomo

Quando si eseguono nodi del cluster di failover Windows, è consigliabile modificare l'impostazione del cluster impostando uno stato di monitoraggio più rilassato. Le impostazioni del cluster predefinite sono restrittive e potrebbero causare interruzioni non desiderate. Le impostazioni predefinite sono progettate per reti locali altamente ottimizzate e non considerano la possibilità di latenza indotta da un ambiente multi-tenant, ad esempio Microsoft Azure (IaaS).

Windows Server Failover Clustering 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 1 del cluster è stato rimosso dall'appartenenza al cluster di failover attivo. Il servizio cluster in questo nodo potrebbe essere stato arrestato. Ciò potrebbe anche essere dovuto al fatto che il nodo ha perso la comunicazione con altri nodi attivi nel cluster di failover. Eseguire la Convalida guidata configurazione per controllare la configurazione di rete. Se questa condizione persiste, controllare nel registro eventi di sistema la presenza di errori hardware o software correlati alle schede di rete in questo nodo. Verificare 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

Esistono due impostazioni usate per configurare l'integrità della connettività del cluster.

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 verificarsi ritardi diversi tra i nodi nella stessa subnet e tra i nodi, che si trovano in subnet diverse.

Soglia : definisce il numero di heartbeat che non vengono rilevati prima che il cluster esecupi l'azione di ripristino. La soglia è 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 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 con conseguente rimozione del nodo dall'appartenenza al cluster. Ciò comporta lo spostamento delle risorse in un altro nodo disponibile nel cluster. Verranno segnalati errori del cluster, incluso l'errore del cluster 1135 (precedente).

Risoluzione

Per risolvere questo problema, rilassare le impostazioni di configurazione della rete del cluster. Vedi Heartbeat e soglia.

Riferimenti

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

Per informazioni sull'uso di cluster.exe per ottimizzare le impostazioni di configurazione di rete del cluster Windows, vedere How to Configure Cluster Networks for a Failover Cluster .For information on using cluster.exe to tune Windows Cluster network configuration settings, see How to Configure Cluster Networks for a Failover Cluster.