ADM de Redes

Um Blog sobre o dia a dia do Administrator de Redes e Servidores Microsoft

By

NUMA e Dynamic Memory no Hyper-V.

Olá Pessoal,

Hoje estava conversando com meu irmão sobre NIC Teaming em um ambiente de Hyper-V em Cluster, e depois de discutirmos isso fomos olhar outras configurações e uma das coisas que me chamou a atenção era a configuração de Hardware dos Hosts. No caso do servidor em questão é um servidor com 2 Processadores, 12 Núcleos e 24 Logical Processors com 128 GB de RAM. Um servidor de respeito. Veja abaixo: (Obs.: Isso é um Hyper-V Server rodando em produção)

Na tela acima você pode verificar, além da configuração de Processador e Memória, que o gráfico de processador está dividido em 2. Isso por que foi selecionado a opção de mostrar NUMA Nodes.

Neste Cluster rodam diversas VMs e algumas delas com configurações grandes, como por exemplo uma VM, que roda uma aplicação importante, e tem 12 Virtual Processors e 32 GB de RAM. Quando temos configurações grandes como esta, é importante tomar cuidado com alguns detalhes. No caso desta máquina, por exemplo, veja a configuração:

Repare que a VM tem 12 Virtual Processors. Veja o que acontece quando colocamos 13 Virtual Processors:

V vai utilizar o que chamamos de vNUMA (Virtual NUMA) onde a VM recebe a informação de que ela está operando em NUMA, podendo a aplicação tomar a “melhor decisão” de onde colocar os processos e escrever em memória. Mas voltando ao assunto, vNUMA não é suportado com Dynamic Memory. Por isso, se você tentar alterar a configuração de UMA para NUMA, o Dynamic Memory não pode ser utilizado.

De fato, se a aplicação não é NUMA aware, o ideal é o modelo UMA, pois assim evita-se problemas de desempenho na VM. A questão então é identificar quanto uma VM pode ter de tamanho dentro de um Host para que não mude a arquitetura para NUMA. Para isso, você pode verificar o seguinte:

Na imagem acima, está indicado que a VM está configurada para utilizar 2 NUMA Nodes, e que um único NUMA Node dentro deste Host possui 12 Processors e 64GB de RAM.

Espero ter ajudado com esta dica.
Até mais!

By

Livro Microsoft Hyper-V Cluster Design

Olá Pessoal,

Há algum tempo, venho trabalhando em mais um projeto de revisão técnica de livro sobre Hyper-V. Desta vez, o livro foi sobre Design de cluster de Hyper-V. O escritor foi o Eric Siron. Claro que revisar um livro nem se compara com escrever um, mas mesmo assim foi um trabalho árduo e que precisou de bastante dedicação.

Eu, particularmente, fiquei muito bem impressionado com o livro. Achei ele extremamente completo e didático. O livro foi lançado há pouco e em breve estará disponível no site da Editora aqui, ou na Amazon aqui.

Espero que vocês gostem do livro e da dica…
Até mais!

By

Alta Disponibilidade de Serviços de Impressão no WS2012

Olá Pessoal,

Se você está acostumado a projetos de cluster, provavelmente, você já se deparou com um projeto de cluster de servidores de impressão. Até o Windows Server 2008 R2, este era um assunto um tanto quanto delicado.

Delicado pois para se ter um cluster de impressão até o Windows Server 2008 R2, você deveria montar um cluster “padrão” e adicionar o serviço de impressão como uma “Role” do cluster. Por funcionar como uma “Role” do cluster, muitas impressoras tinham incompatibilidade de drivers, o gerenciamento não era tradicional como uma impressora instalada normalmente, além de alguns processos requererem scripts que normalmente não eram fáceis de se desenvolver.

Enfim, gerenciar um cluster de impressão era um processo, como disse, um tanto delicado. Isso mudou drasticamente no Windows Server 2012. A primeira mudançca que alguém irá perceber é o fato de o serviço de impressão não estar mais disponível como uma “Role”:

image

Bom, não se desespere. Há um motivo para o serviço de impressão não estar disponível aqui. Na verdade, houve uma mudança de conceitos no Windows Server 2012.

No Windows Server 2012, se você quiser um serviço de impressão com Alta Disponibilidade, você deverá criar uma Máquina Virtual com Alta Disponibilidade e nesta Máquina Virtual você irá configurar o serviço de impressão normalmente, como faria em um servidor de impressão qualquer.

Por que isso? Bom, como dito acima, configurar um serviço de impressão em Alta Disponibilidade, pode gerar mais confusão do que resolver problemas. Com isso, este novo modelo se mostra muito mais flexível. Com a VM com alta disponibilidade, fica fácil de gerenciar o serviço de impressão, não há problemas de incompatibilidade de drivers, e etc.

Basicamente, com este novo modelo, você terá um servidor de impressão como qualquer outro. E no caso de falha de um dos nós do seu cluster, a VM será ligada em outro nó, retornando o serviço de impressão ao estado normal.

Isso fica ainda mais interessante quando combinamos esse novo modelo com um novo recurso do Windows Server 2012. O recurso de VM Monitoring, ou Monitoração de VM. Este recurso permite que o cluster verifique os serviços desejados nas VMs e tome uma ação caso o serviço não esteja em seu funcionamento padrão. Em uma VM que é servidor de impressão, você teria algo como o abaixo:

image

Com este recurso configurado, caso os nós estejam funcionando, mas o serviço de impressão dentro da VM apresente uma falha, o próprio serviço de cluster poderá tentar remediar a VM. Primeiramente, por padrão, ele tentará reiniciar a VM. Isso, no caso de um serviço de impressão poderá resolver o problema. Mas se o problema persistir, o serviço de cluster fará o Live Migration desta VM para outro nó, imaginando que se for algum problema de hardware, este será resolvido. Com isso, muito provavelmente o problema será resolvido. Mesmo assim, se o problema não for resolvido, a VM ficará indicada como “Application in VM State Critical”.

Espero que vocês tenham gostado das novidades e que de agora em diante fique mais fácil criar seus cluster de Servidores de Impressão.
Até mais!

By

Geo Cluster ou Hyper-V Replica?

Olá Pessoal,

Recentemente, me deparei com uma situação onde era necessário escolher a melhor opção de Disponibilidade e Recuperação de Desastre em um projeto. O parceiro que estava no projeto com o cliente levantou as necessidades e minha parte foi basicamente explicar as diferentes soluções que poderiam atender este caso. Gostaria de compartilhar com vocês as soluções e quais os benefícios de cada uma das opções.

Desde o Windows Server 2008, a Microsoft facilitou muito a configuração de um Cluster Geográfico. A opção de se ter um File Share Witness é um dos exemplos disso. Antes de mais nada, vamos entender o que é um Geo Cluster:

Um Cluster Geográfico é um cluster onde os nós deste cluster estão em sites diferentes da empresa. Imagine que você tem um Cluster chamado Cluster 01 e este cluster tem 2 nós. Um dos nós poderia estar em uma localidade e o outro nó estaria em outra. Não vou entrar em detalhes de links, mas é importante que os nós estejam sempre se comunicando. Por ser o mesmo cluster, os recursos que são criados no Cluster, como VMs, poderão iniciar em qualquer um dos nós. É aí que vem a primeira vantagem de um cluster geográfico. Caso um dos nós pare de funcionar, a VM que estava neste local, poderá iniciar em uma outa localidade. E o mais importante, este processo de HA será operado pelo cluster automaticamente. Este processo automatico é o que muitos entendem como grande benefício. Porém, alguns pontos devem ser observados e muitas vezes, estes pontos impossibilitam um projeto como este. Vamos lá:

Para que um cluster funcione, um armazenamento compartilhado é necessário. No caso de um Geo Cluster, isso também é verdade, mas em cada localidade os Hosts irão ter seu storages, logo, estamos falando de 2 Storages. Além disso, os storages devem estar atualizados em relaão um ao outro. O Windows Server não irá fazer este processo. Isso é um serviço que deve ser adquirido com o fabricante do storage (ou uma consultoria que faz este trabalho). Além disso, o File Share Witness é um ponto importante no processo. Isso por que é ele quem irá garantir que apenas seja feito HA caso o Nó de um dos sites realmente esteja off-line. Para que o caso de uma queda de links não impacte o processo de HA, o File Share Witness deve estar em uma terceira localidade. Então além dos 2 sites onde os nós do cluster estão, o File Share Witness devem estar em uma terceira localidade, terceiro site.

Enfim, a não ser que o processo automatico de HA seja extremamente importante, um Geo Cluster é algo que nem todas as empresas poderão contar. Mas o Windows Server 2012 trouxe uma novidade que muitas empresas poderão adotar que é extremamente mais acessível. Trata-se do Hyper-V Replica.

O Hyper-V Replica é um recurso do Hyper-V 3 que está disponível nas 2 versões do Windows Server 2012 (Standard e Datacenter) e também no Hyper-V Server 2012, ou seja, é um recurso gratuíto.

O Hyper-V Replica, consiste em ter um host de virtualização em uma localidade e outro Host em uma segunda localidade.O Replica é aplicado por VM, logo, para as VMs que você quer replicar, você irá configurar a replicação tendo uma máquina virtual de origem ligada e funcionando, e outra máquina virtual de destino desligada. No caso de uma falha, você deverá manualmente fazer o failover desta VM para que a VM de destino seja ligada. Neste caso, você poderá escolher entre os Pontos de Recuperação disponíveis, caso você tanha habilitado esta configuração, ou então, a última replicação conhecida, lembrando que a replicação do Hyper-V Replica é assincrona. Os pontos fortes do Hyper-V Replica é que este não precisa de replicação de storage. De fato, você poderia utilizar até mesmo os discos locais dos servidores Hosts para hospedar as VMs. Nenhum tipo de storage compartilhado é necessário neste caso.

Veja que com o Hyper-V Replica também é possível automatizar o processo. Para isso você poderá utilizar vários “gatilhos”, como um script Powershell, System Center Orchestrator, Operations Manager, Service Manager ou qualquer outra solução que consiga iniciar o processo. A questão aqui é a mesma que o que foi dito acima sobre o File Share Witness. Este componente que automatiza o processo precisa estar isolado dos sites onde estão os hosts.

Resumindo: Se você precisa de um processo de Recuperação Automatizado e o serviço ou aplicação que você quer proteger não puder ficar parado por muito tempo (tempo para um processo de failover manual) o ideal é ter um cluster Geográfico. Mas lembre-se que você precisará de recursos extras para isso. Agora, se a aplicação pode ter um tempo de inatividade aceitável, o Hyper-V Replica é uma excelente solução pois é simples de se configurar, não tem nenhum custo nem necessita de serviço de terceiro.

Espero que tenham gostado da expliação!
Até mais!

By

Drops 2012 #05 – Novidades de Cluster no Windows Server 2012

Olá Pessoal,

Espero que gostem!
Até mais!