Failover Cluster – Novidades do Windows Server 2016! – Parte 1

Este artigo faz parte de uma ação conjunta do grupo MTI, com foco em Windows Server 2016.

O Windows Server 2016 está realmente cheio de novidades, e neste artigo vou falar sobre algumas mudanças na feature de Failover Cluster. O ebook Introducing Windows Server 2016 lista as principais alterações:

 

Vou abordar de forma resumida alguns dos pontos listados acima em duas partes.

  • CLOUD WITNESS Utilizando MICROSOFT AZURE

Neste novo modelo de Quorum, temos um cenário similar ao  modelo FILE SHARE MAJORITY, onde a diferença principal é a possibilidade de atribuir o voto de witness ao Azure, evitando assim que clusters geográficos sofram o cenário de “split brain”, onde após uma perda de comunicação entre os sites, ambos permaneçam com sua estrutura de cluster ativa, resultando ações não cordenadas.

Caso a estrutura de Failover Cluster geográfico esteja configurada para utilizar o modelo de quorum Cloud Witness, e ocorra uma perda de comunicação entre os respectivos sites, o cluster irá permanecer em execução no nó que detem acesso a cloud, forçando assim o failover e queda do serviço de cluster no site que está sem conexão.

  • Melhorias no recurso de Shared VHDX

O Recurso de shared VHDX permite que 2 máquinas virtuais tenham acesso simultâneo ao mesmo VHDX, configuração útil para cenários de Failover Cluster configurado em máquinas virtuais. Uma observação importante deste modelo, é que o mesmo contempla o cenário de CLUSTER dentro de CLUSTER, onde é pré-requisito um storage compartilhado (CSV ou SCALE-OUT-File Server) para configuração do Cluster em VM.

Abaixo temos uma imagem que representa muito bem este modelo, utilizando como base um Cluster Shared Volume, dentro de um cenário de failover cluster em máquinas virtuais:

Embora este recurso funcine muito bem no Windows Server 2012 R2, existem algumas limitações que impedem a execução das ações abaixo:

When you share a virtual hard disk file, these tasks aren’t supported:

  • Resizing
  • Migrating
  • Backing up or making replicas

https://technet.microsoft.com/en-us/library/dn281956(v=ws.11).aspx>

Estas limitações foram removidas do shared VHDX do server 2016, onde as operações de resizing, Migrating e Backup podem ser realizadas sem down time, além de ser possível incluir o shared VHD em um cenário de Hyper-V replica.

Para detalhes sobre a configuração de um Shared VHDX clique aqui

  • Melhorias no Cluster Log

Aqui temos uma das minhas alterações prediletas no Failover Cluster do Server 2016! O cluster log agora traz informações sobre recursos e grupos presentes no cluster, além de trazer também os logs de sistema relacionados. Isso torna o troubleshooting mais dinâmico, e facilita a procura de logs para confecção de RCAs:

  1. ACTIVE MEMORY DUMP

Servidores com um grande montante de memória física tendem a apresentar boa performance, entretanto, quando é necessário realizar o debuging de um memory Dump, esta tarefa pode se tornar difícil devido ao tamanho do arquivo de dump a ser gerado, que no caso de um “FULL DUMP” equivale ao montante total de memória da máquina.

Eu mesmo já trabalhei em situações onde um servidor SQL com 2 TB de memória RAM apresentava esporadicamente hang durante o logon, e este servidor não possuía espaço em disco suficiente para armazenar um full memory dump. Minha solução neste caso foi alterar o parametro “Maximum memory” na opção de boot avançado (MSCONFIG), limitando o Windows a iniciar com um montante de memória que caberia no disco.

No Windows Server 2016, temos a opção de gerar um DUMP apenas da “memória ativa” consumida pelo sistema operacional. Ou seja, no momento da falha, apenas o conteúdo efetivamente utilizado pelo Kernel Mode e User Mode é armazenado no arquivo de dump, diminuindo o tamanho do arquivo, e trazendo realmente os dados necessários para debuging. No contexto de failover cluster por exemplo, esta configuração pode ser útil na análise do BugCheck 0x9e, que se refere a um bugcheck forçado pelo recurso de monitoramento do cluster, RHS.exe. Para mais informações Clique aqui.

 

  • Diagnóstico de Network Name

Uma atenção especial foi dada a este contexto, onde nas versões anteriores do failover Cluster, falhas de Network Name, relacionadas por exemplo a falha na atualização de DNS, eram simplesmente representadas por eventos genéricos de sistema. Agora este recurso do cluster passa a ter rotinas de diagnóstico, onde frequentemente são feitas algumas validações como:

– Busca por domain controllers acessíveis

– Validação quanto a existência e sincronização da senha do CNO (Cluster Name Object)

Durante o validation report, novos testes também foram incluídos,  validando se o a estrutura geral do CNO/VNO e níveis de permissão estão de acordo, facilitando o diagnóstico de problemas de permissão com os objetos que representam o cluster no Active Directory.

 

É isto por hoje pessoal! Em breve teremos a segunda parte deste artigo, comentando sobre as alterações do Failover Cluster restantes do Windows Server 2016.

Marcado com , , , , , ,

Deixe uma resposta

%d blogueiros gostam disto: