IaaS com SQL Server – ajustando limites de rede de cluster de failover

Este artigo apresenta soluções para ajustar o limite de redes de cluster de failover.

Sintoma

Quando você executa nós de cluster de failover do Windows no IaaS com um grupo de disponibilidade SQL Server Always On, é recomendável alterar a configuração do cluster para um estado de monitoramento mais descontraído. As configurações de cluster fora da caixa são restritivas e podem causar interrupções desnecessárias. As configurações padrão são projetadas para redes locais altamente ajustadas e não levam em conta a possibilidade de latência induzida causada por um ambiente multilocatário, como o Microsoft Azure (IaaS).

O Clustering de Failover do Windows Server está constantemente monitorando as conexões de rede e a integridade dos nós em um Cluster do Windows. Se um nó não for acessível na rede, a ação de recuperação será tomada para recuperar e colocar aplicativos e serviços online em outro nó no cluster. A latência na comunicação entre nós de cluster pode levar ao seguinte erro:

Erro 1135 (log de eventos do sistema)

O nó de cluster Node 1 foi removido da associação de cluster de failover ativo. O serviço cluster neste nó pode ter parado. Isso também pode ser devido ao nó ter perdido a comunicação com outros nós ativos no cluster de failover. Execute o assistente Validar uma Configuração para marcar sua configuração de rede. Se a condição persistir, marcar para erros de hardware ou software relacionados aos adaptadores de rede neste nó. Também marcar para falhas em quaisquer outros componentes de rede aos quais o nó está conectado, como hubs, comutadores ou pontes.

Cluster.log exemplo:

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)

Motivo

Há duas configurações que são usadas para configurar a integridade da conectividade do cluster.

Atraso – isso define a frequência em que os batimentos cardíacos de cluster são enviados entre nós. O atraso é o número de segundos antes da próxima pulsação ser enviada. No mesmo cluster, pode haver atrasos diferentes entre nós na mesma sub-rede e entre nós, que estão em sub-redes diferentes.

Limite – isso define o número de pulsações, que são perdidas antes do cluster tomar medidas de recuperação. O limite é uma série de pulsações. No mesmo cluster, pode haver limites diferentes entre nós na mesma sub-rede e entre nós que estão em sub-redes diferentes.

Por padrão Windows Server 2016 define o SameSubnetThreshold como 10 e SameSubnetDelay como 1000 ms. Por exemplo, se o monitoramento de conectividade falhar por 10 segundos, o limite de failover será atingido, resultando no inacessível que o nó está sendo removido da associação de cluster. Isso resulta na movimentação de recursos para outro nó disponível no cluster. Erros de cluster serão relatados, incluindo o erro de cluster 1135 (acima) é relatado.

Resolução

Para resolve esse problema, relaxe as configurações de configuração de rede de cluster. Consulte Pulsação e limite.

Referências

Para obter mais informações sobre como ajustar as configurações de rede do Cluster do Windows, consulte Ajustar limites de rede de cluster de failover.

Para obter informações sobre como usar cluster.exe para ajustar as configurações de configuração de rede do Cluster do Windows, consulte Como configurar redes de cluster para um cluster de failover.