Compartilhar via

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

  • Artigo

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

Sintoma

Quando você executa nós de cluster de failover do Windows em IaaS com um grupo de disponibilidade Always On do SQL Server, é recomendável alterar a configuração do cluster para um estado de monitoramento mais relaxado. As configurações de cluster prontas para uso 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 monitora constantemente as conexões de rede e a integridade dos nós em um cluster do Windows. Se um nó não puder ser acessado pela rede, uma ação de recuperação será executada para recuperar e colocar os aplicativos e os serviços online em outro nó no cluster. A latência na comunicação entre os nós de cluster pode resultar no seguinte erro:

Erro 1135 (log de eventos do sistema)

O nó de cluster O nó 1 foi removido da associação de cluster de failover ativo. O serviço de 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 de Validação de Configuração para verificar a configuração de rede. Verifique o log de eventos do sistema quanto a erros de hardware ou de software relacionados aos adaptadores de rede nesse nó. Verifique também se há falhas em 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)

Causa

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

Atraso - Define a frequência com que as pulsações do cluster são enviadas entre os nós. O atraso é o número de segundos antes que a próxima pulsação seja enviada. No mesmo cluster, pode haver diferentes atrasos entre os nós da mesma sub-rede e entre nós que estão em sub-redes diferentes.

Threshold - Define o número de pulsações que são perdidas antes que o cluster execute uma ação de recuperação. O limite é uma série de pulsações. No mesmo cluster, pode haver diferentes limites entre os nós da mesma sub-rede e entre nós que estão em sub-redes diferentes.

Por padrão, o Windows Server define o SameSubnetThreshold como 10 e o SameSubnetDelay como 1000 ms. Por exemplo, se o monitoramento de conectividade falhar por 10 segundos, o Limite de failover será atingido, resultando na inacessível remoção do nó da associação ao cluster. Isso faz com que os recursos sejam movidos para outro nó disponível no cluster. Os erros de cluster serão relatados, incluindo o erro de cluster 1135 (acima).

Resolução

Para resolver esse problema, reduza as restrições das definições de configuração da rede de cluster. Confira Pulsação e limite.

Referências

Para obter mais informações sobre como ajustar as definições de configuração da rede de cluster do Windows, confira Como ajustar os limites da rede de cluster de failover.

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