Implementando Hyper-V Réplica

 

A Réplica do Hyper-V é uma parte integrante da função do Hyper-V, que replica assincronamente máquinas virtuais do Hyper-V em um site primário para máquinas virtuais de réplica em um site secundário.

Os requisitos para a configuração do Hyper-V Réplica são:

  • Local – os servidores podem estar fisicamente colocalizados ou em localizações geográficas completamente separadas;
  • Topologia – os servidores de réplica primário, secundário e estendido podem ser standalone ou nós em um cluster de failover. Há suporte para uma combinação de ambientes em cluster e standalone e estendido;
  • Certificado – Se você planeja usar autenticação baseada em certificado (necessária para que os dados replicados sejam criptografados durante a transmissão), será necessário um certificado, que pode ser local ou autoassinado ou fornecido por uma AC interna.

(Referência Msdn Microsoft)

 

O Hyper-V Réplica trabalha com diferentes tipos de Failover:

  • Failover Programado – Onde você desliga a máquina virtual e executa o Failover Programado que faz o sincronismo das últimas alterações da máquina virtual e inicia ela automaticamente no servidor Réplica;
  • Failover – Em caso de catástrofe, onde você vai no servidor hyper-v réplica, clica com o botão direito na máquina virtual, replication e clica em Failover, a máquina vai iniciar no servidor de réplica, porém pode não ter todos os dados atualizados dependendo do intervalo da última replicação;
  • Teste Failover – Para validar se a máquina virtual que está no servidor de réplica vai iniciar normalmente. A máquina virtual é iniciada e isolada da rede apenas para fins de testes, tudo o que for feito ou gravado nela será perdido após o cancelamento do “Teste Failover”.

 

Desenvolvemos um documento demonstrando o cenário da replicação de máquinas virtuais configuradas com HA, através do Cluster Failover. O mesmo é composto por dois “Nodes”, Disco de “Quorum”, dois Volumes para armazenamento de máquinas virtuais e um servidor Hyper-V standaloneporém member server do domínio.

 

Faça o download do documento Hyper-V Réplica e, passo a passo, saiba como:

  • Adicionar o Hyper-V Réplica Broker no Cluster Failover
  • Configurar o Hyper-V Réplica Broker
  • Configurar o Hyper-V Standalone como Replica Server
  • Configurar a replicação da máquina virtual
  • Executar o Failover Planejado
  • Executar o Failover do servidor standalone para o Cluster Hyper-V

 

Read More

Nova versão do Veeam Backup compatível com vSphere 6

A Veeam liberou hoje uma nova versão de seu aplicativo, o Veeam Backup 8 update 2, compatível com o novo vSphere 6, lançado no VMware PEX em fevereiro e liberado para download no final de março de 2015.

Essa nova versão do Veeam traz compatibilidade com os novos recursos do vSphere 6, além da compatibilidade da versão, entre os principais podemos destacar:

  • Integração com as Tags do vSphere, uma nova abordagem para gerenciamento das VMs e do ambiente
  • Suporte ao VMware Virtual Volumes, a nova forma de organizar os discos e volumes apresentados aos servidores ESX
  • Suporte a backup mesmo se fizer migração da VM entre vCenters
Uma funcionalidade interessante é que liberaram o suporte ao PowerShell no Veeam Backup Free Edition, isso permite utilizar um agendador de tarefas externo, com o Windows Task Manager para criar os agendamentos e fazer os backups com o Veeam gratuitamente, substituindo soluções via script como o ghettoVCB.

Mais informações e procedimentos de upgrade no site da Veeam.

Read More

Windows Server 2012 com Hyper-V Replica

O Hyper-V do Windows Server 2012 introduz uma nova funcionalidade, o Hyper-V Replica, como um mecanismo de replicação embutido de máquinas virtuais. Hyper-V Replica faz a replicação de forma assíncrona de uma máquina virtual em execução hospedada em um site de produção para um site de DR através da LAN/WAN.
Neste cenário tanto os sites primários quanto os sites secundários deverão utilizar o Windows Server 2012 ou 2012 R2, onde o site primário estará com todas as VMs em produção, enquanto o site secundário irá receber as VMs replicadas (DR) do site de produção. Assim, caso o site principal tenha algum problema ou uma queda de VM planejada ou não, as VMs poderão ser ligadas no site secundário, podendo ser apenas uma VM em pontual, como também todas as VMs do site.
O Hyper-V Replica não necessita de armazenamento compartilhado, nem de hardware de armazenamento específico. Uma vez que uma cópia inicial é replicada para o site secundário a nível de LAN a replicação já estará configurada, assim, com o agendamento da replicação o Hyper-V irá replicar apenas a diferença da VM para o site secundário, ou seja, os deltas, e ocorrerá de forma assíncrona, podendo ocorrer em um tempo de no mínimo 30 segundos.

 

Habilitando a replicação para o Servidor DR

Uma vez que todas as exigências são configuradas, a primeira etapa a se configurar é o servidor de destino (réplica); em seguida configurar as VMs que serão destinadas para a replicação, conforme segue o processo de exemplo para habilitar Hyper-V Replica.
 

 

Primeira Etapa 

Identificar quais os Hosts com Windows Server 2012 Hyper-V que irão receber as réplicas e através do “Hyper-V Settings“, acessar as “Configurações de Replicação” e validar suas respectivas configurações.

 

 

Segunda Etapa 

Através do Hyper-V Manager no site principal, clicar com o botão direito do mouse nas VMs a serem replicadas e acessar “Habilitar Replicação”; em seguida, através do assistente de configuração seguir as melhores práticas para o ambiente.

 

 

 

 

 

A primeira replicação poderá ocorrer na conclusão da configuração, como também pode ser agendado.
A replicação ocorre via LAN. A melhor prática para replicação inicial é
agendar horários menos críticos, pois é neste momento que será replicado o arquivo com o tamanho total de cada VM.
Caso a VM possua um disco com tamanho muito grande temos a opção de armazenar a primeira replicação em um disco físico (HD Externo), em seguida, transportar para o Site DR e armazenar o mesmo. Após esta etapa, a replicação será apenas dos deltas, ou seja, incremental.
Também nesta configuração temos a opção de criar pontos defailover, ou
seja, podemos criar vários pontos. Assim, podemos escolher no failoverem qual momento iremos retornar a VM replicada.
Assim a configuração estará concluída. Esta tarefa deverá ser realizada em todas as VMs que farão parte da replicação.
Obs.: como a replicação ocorre a nível de kerberos é de extrema importância que o ADDC e DNS estejam funcionando corretamente.
 

 

Podemos realizar um teste de failover a partir do site Secundário (DR). Clique com o botão direito do mouse na VM replicada e selecione a opção “failovertest” assim, o Hyper-V cria uma VM com o mesmo nome da VM do site de produção, basta iniciar a mesma.
A VM será iniciada sem IP, ou seja, apenas teste, porém um recurso bastante interessante, na qual temos a possibilidade de configurar IP Failover. Ou seja, quando iniciarmos a VM no site DR podemos iniciar a mesma com outro IP.
Failover Planejado, se destina para um ambiente ou máquina virtual com possível problema, na qual iremos executar a opção “Planned Failover“. Esta opção irá ligar a VM no site DR, ou seja, esta opção apenas deverá ser executada caso a VM de produção esteja com algum problema ou desligada.

 

As informações, a seguir, são retornadas após uma execução bem-sucedida de um evento planejado de Failover a partir do site secundário (DR).

 

 

A execução com sucesso de um failover planejado irá estabelecer automaticamente uma relação de replicação inversa onde, em seguida, o local antes de réplica (DR) torna-se o principal (produção) e o local atual de produção se torna réplica (DR). Verifique a saúde da replicação clicando com o botão direito na VM; com o Hyper-V Replica habilitado, clique em “Hyper-V Manager”, que revela a relação da replicação atual. A seguir, são mostradas informações de saúde da replicação da VM antes e depois de realizar com sucesso um failover planejado, com uma relação inversa (replicação definida automaticamente).

 

O failover sempre deverá ser iniciado manualmente no site DR após a identificação de que uma VM ou o site principal como um todo está com problema.
Caso o problema esteja no Host, deverá ser efetuado o failover de todas as VMs no site secundário. Assim, quando o Host voltar em seu perfeito funcionamento irá desligar as VM e efetuar o failback, do secundário para o primário.

 

 

INFORMAÇÕES

Replicação assíncrona de mudanças

O Hyper-V Replica irá replicar, ou seja, criar uma VM idêntica no Gerenciador Hyper-V do servidor de réplica, e posteriormente, o Hyper-V Replica, irá rastrear, acompanhar os processos e reproduzir as alterações no site secundário.
Esta tarefa irá ocorrer independente dos arquivos VHDs, ou seja, podendo ser de origem de compartilhamento (SMB), Cluster Shared Volumes (CSVs), SANs ou dispositivos conectados diretamente ao Hyper-V.

 

 

Hyper-V Replica com Cluster

Se o ambiente possuir um cluster de failover do Hyper-V como um site DR, deve-se utilizar a função Failover Cluster Manager para realizar todas as configurações e gerenciamento do Hyper-V Replica, sendo que primeiro deve-se criar uma função Hyper-V Replica Broker, conforme demonstrado abaixo.
  

 

O Hyper-V Replica Broker é o ponto selecionado nesta imagem. Ele consulta o banco de dados de cluster associado e redireciona para o melhor nó as VMs e eventos específicos, tais como pedidos de migração ao vivo em um cluster de réplica. 

 

Active Directory

Domínio do Windows Active Directory não é um requisito para o Hyper-V Replica, que também pode ser implementado entre grupos de trabalho e domínios não confiáveis através de uma autenticação baseada em certificado. O Active Directory, no entanto, é um requisito muito importante no host Hyper-V quando o mesmo faz parte de um cluster de failover, nesse caso, todos os hosts Hyper-V de um cluster de failover devem estar no mesmo domínio do Active Directory, com segurança aplicadas no nível do cluster.
Autor: Alex Santos – Especialista Blue Solutions


Read More

Como funciona a Virtualização de Servidores?

Virtualização de Servidores, como já explicamos nesse outro artigo, é uma forma de dividir os recursos de um servidor físico em vários servidores virtuais, também chamados de máquinas virtuais, de modo que possa executar diversos sistemas operacionais no mesmo hardware físico, isolados entre si.

Funciona da seguinte forma:

1. Aquisição do servidor

Um servidor físico vem com recursos físicos instalados de fábrica, entre eles: CPU, memória, discos, conexões de rede e conexões a SAN:

Servidor

Um servidor moderno tem muito mais recursos do que os softwares são projetados para usar e é comum recursos como CPU e memória ficarem ociosos em alguns servidores, enquanto outros servidores tem gargalos.

Aí que entra a virtualização, no lugar de vários servidores de pequeno porte para diversas aplicações, é melhor investir em um servidor de maior porte e compartilhar os recursos entre os servidores virtuais sob demanda.

2. Instalação do Hypervisor

No servidor físico é instalado um sistema operacional básico, que possui a capacidade de dividir o hardware em pequenas partes. Esse sistema operacional é chamado de hypervisor.

Servidor com Hypervisor Instalado

Quanto menor for o espaço em disco e memória usada por esse hypervisor, mais recursos sobram para as máquinas virtuais, menor é a chance de ter problemas de código no hypervisor e menor são as paradas para manutenção do mesmo.

3. Criar as Máquinas Virtuais

O hypervisor simula dentro de cada “fatia” do hardware um novo hardware, que são chamadas de máquinas virtuais. Os discos ficam armazenados em arquivos dentro do sistema operacional do hypervisor, enquanto que a CPU e memória são alocados sob demanda.

Servidor com Hypervisor instalado e Máquinas Virtuais criadas

Cada máquina virtual pode ter capacidades diferentes de acordo com a necessidade, enquanto uma pode ter mais memória, a outra mais processador e a outra mais espaço em disco, cada uma dividindo uma fração do servidor original.

Na configuração de rede dos hypervisors mais avançados é possível dividir o tráfego e priorizar de acordo com a máquina virtual.

4. Instalação do Sistema Operacional dentro das Máquinas Virtuais

Dentro de cada máquina virtual pode ser instalado um sistema operacional diferente, de acordo com a necessidade. Cada um estará isolado dos demais, enxergará apenas os recursos que lhe foram dedicados e se comportará como se estivesse instalado em uma máquina física comum:

Servidor com Hypervisor e Máquinas Virtuais Instaladas

O hypervisor fica responsável por dividir os recursos entre as máquinas virtuais. Alguns recursos podem ser alocados em maior quantidade do que existe de verdade (over provisioning).

Por exemplo, um servidor com 10Gb de memória pode ter 7 máquinas virtuais com 2Gb de memória cada, o que totalizaria 14Gb, desde que essas não usem todo o recurso ao mesmo tempo; o hypervisor garante que nas situações de disputa, algumas máquinas virtuais tenham preferência de execução (maior prioridade).

5. Conectar a uma SAN (Storage Area Network)

Em um ambiente empresarial com Alta Disponibilidade, as máquinas virtuais ficam armazenadas em uma SAN, que nada mais é do que um local de armazenamento (Storage) compartilhado entre os servidores. A SAN pode ser virtual, nesse caso é chamada de VSAN.

Uma SAN pode ser implementada também com um Storage dedicado, nesse caso, o equipamento possui toda a redundância necessária para garantir a alta disponibilidade do ambiente.

O fato de agregar os discos em um ponto único permite algumas facilidades de gerenciamento, além de poder distribuir a performance mais uniformemente e definir prioridades entre as máquinas virtuais.

Virtualização com SAN em modo de Alta Disponibilidade

 

6. Usando a SAN para manutenção programada de servidores

A SAN armazena os arquivos das máquinas virtuais, sendo assim, as máquinas virtuais podem ser desligadas de um servidor e ligadas em outro servidor sem necessidade de reinstalar o sistema operacional e aplicativos, ou de copiar arquivos entre os servidores físicos.

Também, dependendo da configuração e licenciamento, é possível migrar a máquina virtual entre um servidor e outro sem desligar, esse recurso é chamado de vMotion, Live Migration ou XenMotion de acordo com o fabricante do hypervisor e permite a manutenção de um servidor físico sem downtime (parada) do ambiente.

Manutenção programada com Virtualização

 

7. Crescendo o ambiente

Quando o ambiente cresce, basta adicionar mais servidores ou espaço de Storage e todo o ambiente se beneficia. Pode-se crescer o ambiente em quantidade de máquinas virtuais, capacidade das máquinas virtuais, servidores físicos ou espaço no Storage. Cada servidor físico novo adiciona mais poder de processamento, memória e conectividade com a rede, enquanto que mais discos no Storage adicionam espaço em disco e mais performance de IOPS.

Crescendo o ambiente com Virtualização

 

8. Resiliência do ambiente contra quebras

No caso da quebra física de um dos servidores, as máquinas virtuais podem ser acessadas e ligadas nos demais servidores; se estiver corretamente configurado, esse processo acontece automaticamente, sem necessidade do operador intervir, esse recurso é chamado de HA (High Avaliability) ou Alta Disponibilidade e permite que as máquinas virtuais voltem ao trabalho em poucos minutos.

Alta Disponibilidade (HA) automática com Virtualização

 

Conclusão

Esses são apenas alguns dos benefícios da virtualização de servidores. Para ver mais, leia a matéria sobre os 12 Benefícios da Virtualização no Datacenter.

Read More