Dependendo da potência do equipamento que temos e dos recursos necessários para nossos sistemas, teremos uma proporção média de máquinas virtuais por servidor.
Considere, por exemplo, a manutenção programada de um servidor no Centro de Computação. Há alguns anos se este não fizesse parte de um cluster, o sistema contido no equipamento seria retirado do ar, consequentemente os usuários também seriam afetados e / ou o pessoal envolvido na manutenção teria que trabalhar em janelas de tempo reduzido (para não dizer desconfortável).
No caso de um ambiente virtualizado, as máquinas virtuais podem simplesmente ser “movidas ou migradas” para outro membro de um cluster e o equipamento pode ser desligado para funcionar nele. Problema resolvido.
Vamos começar a ver as situações em que a falta de serviço não está programada.
Máquina virtual e monitoramento de aplicativos
Cada vez que criamos uma máquina virtual, é recomendável instalar um compêndio de aplicativos e drivers que otimizam o comportamento do hardware virtual em sua totalidade (disponível para Windows, Mac OS, Linux e outros sistemas operacionais). Essas ferramentas, chamadas VMTools, entre outras coisas, incluem a possibilidade de o host monitorar a máquina virtual (por meio de pulsações, como em clusters). Se não responder em um determinado período, ele reinicia o sistema operacional.
Um caso semelhante acontece com o monitoramento de aplicativos, mas primeiro você precisa obter o SDK apropriado (ou usar um aplicativo que ofereça suporte ao monitoramento de aplicativos VMware).
Mas … o que acontece se a falha for hardware?
O cluster mencionado acima é a primeira camada da solução.
Armazenamento compartilhadoOnde todos os membros do cluster têm acesso às máquinas virtuais.
Formação de equipes de redeDiante da falha de uma placa, as demais continuam administrando o tráfego.
Caminhos múltiplos (caminhos múltiplos)Para armazenamento, eles não só otimizarão o acesso, mas também fornecerão redundância.
Em termos gerais, essas três tecnologias reduzem o tempo em que nossas informações ficam inacessíveis. Agora, dependendo do licenciamento que temos, também podemos ter dois recursos muito interessantes: Alta Disponibilidade (HA) e Tolerância a Falhas (FT).
Em ambos os casos, exigimos um cluster com armazenamento compartilhado. Sem a necessidade de instalar software adicional, o HA pode ser ativado e configurado de forma que, se um servidor ou máquina virtual falhar no cluster, ele será iniciado automaticamente em outro membro do cluster. Vale a pena esclarecer que HA não se destina a VMs de missão crítica (máquinas virtuais). Portanto o tempo estimado sem serviço será: “Iniciando o Sistema Operacional + Iniciando os serviços”.
Número de falhas de host suportadas pelo cluster
Temos uma quantidade X de máquinas virtuais distribuídas em servidores Y em um cluster.
Quantos hosts podem falhar sem afetar a disponibilidade e o desempenho de nosso ambiente virtual?
A HA pode ser configurada para suportar um número específico de falhas de servidor, garantindo que haja recursos suficientes restantes na recuperação.
O HA divide os recursos disponíveis de um cluster levando em consideração a CPU e a RAM configuradas e consumidas por nossas máquinas virtuais de uma forma muito conservadora. Leva a maior reserva de CPU configurada de qualquer VM em cada host no cluster e, em seguida, a maior reserva de memória e seu excesso. Se não houver reserva configurada, será necessário um mínimo de 32 Mhz por VM para CPU e 0 Mb de RAM + seu excesso.
Com esses números, ele pressupõe que cada máquina virtual usada consumirá essa CPU e memória, então ele gera um valor chamado tamanho do slot. Com este valor, é determinado quantos slots estão disponíveis / usados por cada host.
O problema surge quando, por exemplo, temos uma única máquina com grande CPU e reserva de memória. Ao aceitar as reservas configuradas, é muito provável que o restante de nossas máquinas virtuais não precise realmente desses recursos, resultando em menos slots para nosso cluster.
Porcentagem de recursos do cluster como capacidade para falhas
Ao contrário da opção anterior, esta funciona muito bem quando você tem VMs com configurações de CPU e memória altamente variáveis.
É possível configurar valores percentuais de CPU e memória separadamente, sendo assim ainda mais flexível e consequentemente economizando recursos. Este é geralmente o método preferido para configurar HA.
Hosts para failover
Esta é a configuração típica de cluster em espera. Essa opção é fornecida principalmente porque algumas organizações mantêm políticas que indicam que deve haver servidores em espera no caso de algum desastre. Como o VMware faz um bom gerenciamento de tolerância a falhas, talvez essa seja a opção quando os recursos são abundantes … mas definitivamente não é a melhor.
vMotion: Migrações ao vivo
A migração ao vivo permite que você mova máquinas virtuais em funcionamento de um servidor físico para outro, enquanto mantém sua conexão de rede e identidade. A memória ativa (processos em execução) é transferida pela rede de alta velocidade. Todo o processo leva menos de 5 segundos em uma rede gigabit.
É possível movimentar a VM, os arquivos que ela utiliza, ou ambos, e o procedimento pode ser feito com a máquina ligada ou desligada. No último caso, chamamos de "migração fria" e se a máquina estiver funcionando, chamamos de vMotion.
Usos e benefícios do vMotion
- Reorganização VM, otimizando recursos. Remova-os dos servidores que estão sujeitos a falhas ou saturados.
- Otimização automática de recursos disponíveis (Eu trabalho em conjunto com o Dynamic Resource Scheduler ou DRS).
- Fazer manutenção da infraestrutura subjacente não há necessidade de programação de manutenção ou interrupção de negócios.
Cada componente da integridade da VM é tratado de maneira diferente durante a migração. A configuração geral é a mais simples, ela não se move, mas é recriada no computador de destino.
Como o disco não pode ser recriado em tão pouco tempo, é necessário ter armazenamento compartilhado. O estado atual da memória é gradualmente copiado para o host de destino. Ao final da cópia, as diferenças existentes que surgiram durante a migração são comparadas, o estado da VM de origem é congelado e o sistema operacional é ativado na VM de destino .
Como em alguns casos a opção de reiniciar a máquina não é ideal, para missão crítica temos o Tolerância ao erro. O que se deseja nesses casos não para de funcionar a qualquer momento, mesmo que seu host falhe. A única maneira de isso ser possível é se a VM estiver sendo executada em dois lugares ao mesmo tempo. Ele é configurado no nível da máquina virtual e irá gerar uma cópia exata da VM, mantendo-a 100% replicada o tempo todo em outro servidor, portanto no caso de uma falha de hardware, seu gêmeo simplesmente continuará a funcionar sem qualquer perda de informações. Interessante, certo?
Se fosse apenas sobre recursos, habilitaríamos o FT em todas as máquinas virtuais de nosso data center, mas nas versões anteriores do vSphere encontramos algumas limitações, a mais importante: Não era possível habilitar o FT em máquinas que usavam mais de um virtual processador. Felizmente, na versão mais recente do produto, ele suporta até 4 processadores virtuais simultaneamente por máquina protegida, no entanto, o licenciamento terá que ser considerado:
O número de vCPUs com suporte por uma VM habilitada para FT é limitado pelo nível de licenciamento adquirido para o vSphere.
A tolerância a falhas é suportada da seguinte forma:
- vSphere Standard e Enterprise. Permite até 2 vCPUs.
- vSphere Enterprise Plus. Permite até 4 vCPUs.
Esse não é o único requisito do sistema.
ArmazenarAs VMs devem ter armazenamento compartilhado. Não é possível usar RDM (Raw Devide Mapping) físico.
InternetÉ necessário ter pelo menos dois cartões virtuais (vmnics), um para vMotion e outro (10 gbps) para FT Logging. É um novo requisito da versão 6 (anteriormente, eram necessárias placas de 1 gbps)
ProcessadorOs processadores e sistemas operacionais devem ser compatíveis com o FT (e entre si).
Limitações
- Não é possível tirar instantâneos das VMs que estão sendo protegidas com FT e devem ser excluídas antes de habilitar esta função.
- Discos virtuais (VMDK) com mais de 2 Tb.
- Há uma lista de dispositivos e recursos específicos na documentação do VMware.
E também há uma limitação no número de VMs por servidor: no máximo 4 máquinas protegidas por host ou 8 vCPUs protegidas (o que ocorrer primeiro). Esses máximos incluem a máquina primária e secundária (e vCPUs)
Diferenças entre o legado FT (anterior) e o atual
IPv6
Legacy FT = Não suportado por placas de rede configuradas para registro FT FT = Compatível
APIs VStorage - Backup com proteção de dados
Legacy FT = Não Suportado FT = Suportado
Disco virtual
Legacy FT = EZT (Eager Zeroed Thick) FT = Todos os tipos, incluindo grossos e finos
Redundância Vmdk (disco virtual)
Legacy FT = cópia única FT = As máquinas primárias e secundárias mantêm cópias independentes, o que permite que sejam armazenadas em armazenamentos de dados diferentes e aumenta a redundância
Largura de banda da placa de rede
Legacy FT = NIC dedicado de 1 Gb recomendado FT = NIC dedicado de 10 Gb recomendado
CPU e compatibilidade de host
Legacy FT = Requer o mesmo modelo e família de CPU. As versões FT = CPUs do vSphere quase idênticas devem ser compatíveis com o vSphere vMotion ou EVC. A versão do VSphere deve ser compatível com o vSphere vMotion
Ativar / desativar FT com a máquina em execução
Legacy FT = Nem sempre compatível FT = Compatível
Lembre-se de que o FT protege contra falhas de hardware do servidor, e não contra falhas de sistemas operacionais ou aplicativos.
Watchdog do vCenter Server é uma funcionalidade incorporada da versão 6.x. Ele verifica periodicamente o status dos serviços que compõem o vCenter, irá reiniciar os processos de administração ou a VM se necessário.
