- A alta disponibilidade em servidores virtualizados combina clusters, replicação e armazenamento redundante para minimizar o tempo de inatividade.
- RHEL, Hyper-V, HA-DAS e soluções NAS como a QNAP oferecem diferentes abordagens de alta disponibilidade dependendo do tamanho, orçamento e necessidades.
- A replicação para recuperação de desastres não substitui uma alta disponibilidade real: a recuperação automática e praticamente imperceptível em caso de falha requer sincronização quase em tempo real.
- Projetar a arquitetura corretamente e respeitar os requisitos de hardware, rede e software é fundamental para garantir a continuidade do serviço.
A alta disponibilidade em servidores virtualizados tornou-se um requisito básico para qualquer organização que não possa se dar ao luxo de interrupções de serviço, mesmo que por apenas alguns minutos. Estamos falando de garantir que suas máquinas virtuais, aplicativos e dados permaneçam acessíveis mesmo que um servidor físico, disco, rede ou até mesmo um data center inteiro falhe. Não se trata apenas de ter backups, mas de manter o serviço em funcionamento independentemente do que aconteça.
Ao combinarmos virtualização , clusters, armazenamento e recuperação de desastres , diversas tecnologias surgem (KVM, Xen, Hyper-V, RHEL HA, RHEV, CSV, NAS, JBOD, réplicas, etc.), e nem sempre é claro qual escolher ou como integrá-las. Este artigo oferece uma análise aprofundada das principais opções e abordagens: desde clusters tradicionais com armazenamento compartilhado até soluções modernas baseadas em replicação em tempo real entre nós, incluindo exemplos específicos com arquiteturas Red Hat, Microsoft Hyper-V, QNAP e HA-DAS.
Conceitos básicos de alta disponibilidade em ambientes virtualizados
Em um ambiente virtualizado, alta disponibilidade (HA) significa que as máquinas virtuais (VMs) permanecem acessíveis mesmo se um ou mais componentes do sistema (servidores, discos, controladores, rede, fonte de alimentação, etc.) falharem. Isso não é o mesmo que recuperação de desastres (DR): a HA visa o tempo de inatividade mínimo ou próximo de zero, enquanto a DR normalmente aceita algum tempo de inatividade para restaurar os serviços a partir de um backup.
Para alcançar esse comportamento, vários componentes são combinados: redundância de hardware, software de cluster, armazenamento tolerante a falhas e mecanismos de monitoramento e failover . O objetivo é evitar pontos únicos de falha: se um componente falhar, outro assume o controle sem intervenção manual (ou com intervenção mínima).
No mundo da virtualização, isso normalmente se traduz em ter vários hosts físicos que compartilham ou replicam o armazenamento , e um sistema que monitora o status dos nós e das máquinas virtuais. Quando um host falha, as máquinas virtuais são iniciadas em outro host, idealmente sem que o usuário perceba ou com uma interrupção muito breve.
Também é importante diferenciar entre soluções projetadas para ambientes elásticos "tipo nuvem" e plataformas clássicas de alta disponibilidade. Certos produtos de cluster têm uma configuração relativamente estática e um número máximo de nós relativamente baixo, portanto, não são adequados para configurar uma nuvem massiva, embora sejam excelentes para proteger um conjunto bem definido de serviços críticos.
Em um ambiente de nuvem ou híbrido, é recomendável revisar estratégias específicas de migração e continuidade: por exemplo, a migração para a nuvem pode fazer parte da estratégia de recuperação de desastres, mas não substitui a alta disponibilidade local.
Alta disponibilidade em plataformas Red Hat Enterprise Linux e KVM/Xen
O ecossistema Red Hat oferece diversas opções para proteger máquinas virtuais usando clusters e complementos de alta disponibilidade . Versões como o Red Hat Enterprise Linux 5 e 6 suportam várias combinações de hipervisores e complementos de cluster.
O RHEL 5 suporta duas plataformas de virtualização: Xen (a partir do RHEL 5.0) e KVM (a partir do RHEL 5.4) . O complemento RHEL 5 Advanced Platform (AP) Cluster permite gerenciar VMs Xen e KVM como recursos de cluster, de forma que a infraestrutura de alta disponibilidade do host controle a inicialização, o desligamento e o failover de máquinas virtuais entre os nós.
Com o RHEL 6, o suporte à virtualização foi simplificado: apenas o KVM é suportado como hipervisor . No entanto, o plugin de Alta Disponibilidade do RHEL 6 ainda permite que máquinas virtuais KVM sejam tratadas como recursos de cluster gerenciados pela infraestrutura de alta disponibilidade do host. O gerenciador de recursos do cluster (rgmanager nas versões clássicas) é responsável por monitorar os nós e mover as máquinas virtuais entre servidores físicos quando uma falha é detectada.
Essa abordagem é frequentemente chamada de “ Cluster RHEL/HA executado em hosts físicos atuando como uma plataforma de virtualização ”. O próprio cluster RHEL gerencia onde cada VM é executada e assume o controle em caso de falha de um nó, garantindo que as máquinas virtuais configuradas como críticas sejam reiniciadas em um host íntegro.
Um aspecto interessante é que, da perspectiva do cluster, o sistema operacional convidado da máquina virtual é menos importante . Qualquer sistema operacional convidado compatível com Xen ou KVM no RHEL pode ser tratado como uma máquina virtual de alta disponibilidade: diferentes versões do RHEL (3, 4, 5, etc.) e várias edições do Microsoft Windows, desde que sejam suportadas pelo hipervisor. Isso proporciona considerável flexibilidade na segurança de ambientes mistos.
No entanto, a própria Red Hat recomenda cautela ao escolher entre usar o complemento de alta disponibilidade do RHEL ou plataformas de virtualização mais abrangentes, como o Red Hat Enterprise Virtualization (RHEV), para fornecer alta disponibilidade para máquinas virtuais. Ambos oferecem funcionalidade de alta disponibilidade, mas os casos de uso são diferentes e o tamanho do ambiente e o modelo operacional devem ser considerados.
Quando usar RHEL HA versus RHEV para alta disponibilidade
Ao decidir entre usar o complemento RHEL HA ou uma plataforma como o RHEV para proteger máquinas virtuais, um dos principais critérios é o número de hosts físicos e o tipo de uso que será dado ao ambiente virtualizado.
O complemento de alta disponibilidade do RHEL foi projetado para clusters relativamente pequenos e configurados estaticamente . Tradicionalmente, esses clusters têm um limite máximo de cerca de 16 nós físicos, o que é suficiente para muitos ambientes corporativos, mas não se adapta bem a arquiteturas em nuvem com dezenas ou centenas de hosts em constante mudança.
Portanto, a própria documentação da Red Hat indica que o uso exclusivo do RHEL HA para construir infraestruturas semelhantes à nuvem não é recomendado , justamente por causa de sua natureza estática e do limite de nós. Para cenários de nuvem, faz mais sentido usar plataformas projetadas especificamente para esse modelo, com gerenciadores de recursos mais elásticos e escaláveis.
Por outro lado, se o objetivo é proteger um número moderado de VMs críticas em um conjunto bem definido de hosts , o complemento HA do RHEL é uma solução robusta: ele se integra bem ao sistema operacional, utiliza tecnologias de clusterização maduras e fornece a lógica necessária para monitorar e mover VMs em caso de falha.
Em qualquer caso, é aconselhável consultar a documentação mais recente do RHEL sobre os sistemas operacionais convidados, hipervisores e combinações de clusters suportados , pois o suporte evolui a cada versão e é importante seguir as diretrizes oficiais.
Alta disponibilidade no Hyper-V: clusters, réplicas e migração em tempo real.
Em ambientes Microsoft, a alta disponibilidade baseia-se fundamentalmente nas capacidades do Hyper-V combinadas com o Clustering de Failover do Windows Server . O objetivo é ter acesso consistente às máquinas virtuais mesmo em caso de falhas de hardware, problemas de rede ou erros de software.
O componente principal são os clusters de failover do Hyper-V . Um cluster desse tipo é um conjunto de servidores (nós) que compartilham armazenamento e funcionam de maneira coordenada: se um nó falhar, as máquinas virtuais que estavam sendo executadas nele são reiniciadas automaticamente em outro nó do cluster. Tudo isso é suportado por tecnologias de disco compartilhado e comunicações internas específicas.
Para que isso funcione, os nós normalmente compartilham o armazenamento por meio de uma SAN (Storage Area Network) ou um servidor de arquivos de expansão horizontal (SOFS) . Volumes compartilhados de cluster (CSVs) são então criados sobre essa camada , permitindo que todos os nós acessem simultaneamente os mesmos discos onde residem os arquivos da máquina virtual.
Os nós também se comunicam por meio de uma rede dedicada conhecida como heartbeat do cluster . Essa rede é separada da rede de dados de produção e permite que cada servidor informe que está ativo. Se o cluster parar de receber sinais de heartbeat de um nó, considera-se que ele falhou e os procedimentos de failover são iniciados.
Outro elemento fundamental é a configuração do quorum . O quorum define quantos votos (nós ou testemunhas externas) devem estar ativos para que o cluster continue funcionando. Isso evita cenários de "cérebro dividido", nos quais grupos isolados de nós acreditam erroneamente ser o cluster principal e causam corrupção de dados. Escolher o modelo de quorum correto (nós, testemunha de disco, testemunha de compartilhamento de arquivos, etc.) é essencial para a estabilidade.
Com base nisso, o Hyper-V aproveita os recursos de cluster para permitir migrações em tempo real de máquinas virtuais entre nós com tempo de inatividade mínimo . Durante a manutenção ou balanceamento de carga, uma VM pode ser movida de um host para outro sem interrupção do serviço, transferindo de forma transparente memória, estado e conexões ativas.
Se, em vez de uma manutenção planejada, ocorrer uma falha real de hardware ou software em um nó, o cluster realiza um failover automático . As máquinas virtuais em execução nesse nó são iniciadas em outro host com acesso ao mesmo armazenamento compartilhado. A interrupção é maior do que em uma migração ao vivo (as VMs precisam ser desligadas e ligadas), mas a continuidade do serviço é mantida com intervenção humana mínima.
Além do cluster SAN clássico, o Hyper-V incorpora outras tecnologias focadas tanto em alta disponibilidade quanto em recuperação de desastres, notadamente o Hyper-V Replica e a migração ao vivo sem armazenamento compartilhado.
A Replicação do Hyper-V é um recurso de replicação assíncrona de máquinas virtuais que replica máquinas virtuais entre um host primário e um ou mais hosts de réplica, geralmente localizados em um site ou data center diferente. As alterações são enviadas para a VM de destino em intervalos regulares, criando pontos de recuperação que permitem que a VM seja restaurada a um estado recente caso o site primário sofra uma falha.
Esse mecanismo utiliza um agente de replicação do Hyper-V que coordena o tráfego de replicação, gerencia os pontos de recuperação e centraliza as operações de failover. Ele permite tanto failovers planejados (por exemplo, para migrar a produção para outro site) quanto failovers não planejados (quando o site primário fica inativo inesperadamente).
Devido à sua natureza assíncrona, a replicação é mais voltada para a recuperação de desastres ( DR) do que para alta disponibilidade (HA) com tempo de inatividade próximo de zero . Após um incidente, um failover deve ser iniciado na VM de réplica e, embora o processo seja bastante ágil, envolve algum tempo de inatividade e a potencial perda dos últimos segundos ou minutos de dados, dependendo do intervalo de replicação configurado.
Em paralelo, o Hyper-V oferece a migração ao vivo "Shared Nothing" , que permite mover uma máquina virtual entre hosts que não compartilham armazenamento. Nesse modelo, cada host possui seu próprio armazenamento local, mas a migração ao vivo copia de forma transparente os discos da máquina virtual para o destino enquanto a máquina virtual permanece online e, em seguida, transfere a execução para o novo servidor.
Essa funcionalidade é especialmente útil em ambientes sem SAN ou infraestrutura de armazenamento compartilhado , reduzindo o custo inicial para PMEs ou em cenários onde a manutenção de uma rede de armazenamento dedicada é indesejável. Ela permite, por exemplo, reorganizar hosts ou migrar para novo hardware com impacto mínimo, sem a necessidade de desligar as máquinas existentes.
A combinação dessas tecnologias (clusters de failover, CSV, migração ao vivo com ou sem armazenamento compartilhado e replicação Hyper-V) oferece uma ampla gama de opções para projetar estratégias de continuidade de negócios e tolerância a falhas, adaptadas a diferentes orçamentos e níveis de demanda.
Soluções de alta disponibilidade com HA-DAS e Windows Server
Além de ambientes com grandes SANs, existem arquiteturas projetadas para alta disponibilidade em sistemas de armazenamento conectados diretamente a servidores (HA-DAS) . Essas soluções utilizam o Windows Server (por exemplo, 2012) e controladores RAID/HBA avançados para fornecer clusters de alta disponibilidade sem a necessidade de configurar uma SAN iSCSI ou FC tradicional.
Essa abordagem utiliza dois nós de cluster de alta disponibilidade com armazenamento JBOD compartilhado (um conjunto de discos sem qualquer inteligência integrada). O JBOD se conecta a ambos os servidores por meio de controladores HBA RAID redundantes, de modo que cada nó vê o mesmo conjunto de discos e pode acessar o mesmo array RAID simultaneamente.
Essas soluções podem atingir capacidades de até 180 TB em um chassi compartilhado , funcionando com discos rígidos magnéticos ou SSDs hot-swap em diferentes níveis de RAID. Os controladores RAID normalmente incorporam 1 GB de cache cada, com o cache espelhado entre os controladores para manter a consistência e melhorar o desempenho, e a proteção do cache é baseada em supercapacitores em vez de baterias tradicionais.
A comunicação entre os controladores é normalmente realizada por meio de links SAS , eliminando a necessidade de links Ethernet de pulsação para a sincronização do estado do disco. Isso proporciona um caminho de comunicação direto e altamente confiável entre os dois nós de armazenamento.
Outra característica importante é que essas arquiteturas normalmente operam em modo ativo/ativo no mesmo array RAID . Isso significa que ambos os nós fornecem serviço simultaneamente e aproveitam o poder computacional de ambos os servidores, em vez de deixar um "em espera" até que o outro falhe. Isso evita o desperdício de 50% do investimento em hardware que normalmente ocorre em clusters ativo/passivo.
Ao utilizar o Windows Server 2012 (ou versões posteriores), os administradores se beneficiam de um ambiente de gerenciamento familiar: ferramentas, assistentes, console de gerenciamento e modelo de permissões já conhecidos. O tempo de aprendizado é minimizado, o que também reduz os custos operacionais e os riscos durante a implementação.
Essas soluções HA-DAS são voltadas para diversos usos: virtualização de servidores Hyper-V, VDI Windows, armazenamento SAN/NAS, bancos de dados transacionais (OLTP) , data warehousing e serviços web de alta disponibilidade . Tudo isso é alcançado utilizando um único chassi de armazenamento compartilhado, dois nós redundantes e a lógica de cluster do Windows.
Alta disponibilidade especificamente para arrays NAS da QNAP e Virtualization Station 4.
No setor de NAS, fabricantes como a QNAP desenvolveram recursos avançados para alcançar alta disponibilidade tanto para o armazenamento quanto para as máquinas virtuais hospedadas em seus dispositivos . Especificamente, eles combinam o sistema operacional QuTS hero (baseado em ZFS) com o Virtualization Station 4 para oferecer replicação em tempo real e failover entre dois dispositivos NAS.
Por um lado, o sistema QuTS hero integra tecnologias de alta disponibilidade (HA) no próprio NAS , permitindo que dois dispositivos idênticos (ou similares) sejam configurados como um par de alta disponibilidade. Se um NAS falhar, o segundo assume o controle e os serviços permanecem operacionais. Isso protege tanto o armazenamento quanto os serviços principais do NAS.
Partindo dessa base, a nova funcionalidade de alta disponibilidade do Virtualization Station 4 (disponível em versão beta nas versões recentes) vai um passo além: permite que máquinas virtuais em execução no NAS tenham tolerância a falhas avançada por meio de replicação em tempo real entre dois dispositivos QNAP.
Este recurso está disponível apenas em dispositivos NAS da QNAP com processadores x86 executando o QuTS hero e a versão apropriada do Virtualization Station 4. O uso das tecnologias ZFS e SnapSync é essencial, pois sincroniza os dados da máquina virtual entre os dois dispositivos NAS em tempo real, garantindo que a máquina virtual replicada esteja sempre atualizada.
O esquema operacional baseia-se em dois dispositivos NAS que fazem backup um do outro : o NAS A e o NAS B atuam como nós de backup bidirecionais. Cada um pode ter suas próprias máquinas virtuais e, para aquelas marcadas como protegidas em alta disponibilidade (HA), uma réplica é criada no outro NAS. Em caso de falha de um dos dispositivos, o outro assume o controle e inicia as VMs afetadas.
Isso permite a troca perfeita de servidores NAS . A proteção de Alta Disponibilidade (HA) pode ser ativada apenas para VMs críticas específicas, sem afetar outros serviços do NAS (por exemplo, backups, compartilhamento de arquivos etc.). Cada NAS pode continuar executando sua função original enquanto protege simultaneamente as máquinas virtuais designadas para alta disponibilidade.
A sincronização em tempo real baseada no SnapSync garante que, em caso de incidente, a recuperação seja praticamente instantânea e sem perda de dados . Ao contrário das arquiteturas tradicionais que dependem de uma área de armazenamento compartilhada central (SAN), essa solução elimina esse ponto único de falha: cada NAS mantém uma cópia completa e consistente das VMs que protege.
Além disso, a QNAP define várias condições de falha que podem acionar um failover : sobrecarga prolongada da CPU (acima de um determinado limite, por exemplo, 80% por um período de tempo), temperatura excessiva do sistema, falha de disco mesmo em configurações RAID, perda de uma das fontes de alimentação redundantes, entre outras. O sistema avalia essas condições e, se o NAS for considerado não confiável, transfere a carga para o outro nó.
O sistema também oferece a opção de migrações manuais , que são muito úteis quando a equipe técnica deseja migrar máquinas virtuais para outro NAS de forma controlada para tarefas de manutenção, como substituição de discos, atualização de firmware, alteração de configurações avançadas, etc. A migração é muito rápida (da ordem de menos de um segundo), tornando o processo praticamente transparente para os usuários.
Outro ponto interessante é que não há custos adicionais de licenciamento : a funcionalidade de alta disponibilidade do Virtualization Station 4 faz parte da própria aplicação e está incluída no sistema, sem pagamentos extras por nó ou por máquina virtual. Isso o torna especialmente atraente para PMEs e ambientes que buscam alta disponibilidade a um custo razoável.
Requisitos e limitações de alta disponibilidade no QNAP
Para implementar esta solução com sucesso em um dispositivo QNAP, é essencial atender a certos requisitos de software, hardware e rede . Eles não são extremamente complexos, mas é importante tê-los bem claros antes de projetar o ambiente.
Em relação ao software, é necessário o QuTS hero versão h5.3 ou superior e o Virtualization Station 4.1 ou posterior. Somente essas versões incluem a funcionalidade de alta disponibilidade (HA) de máquinas virtuais baseada em SnapSync. Esse recurso não está disponível em dispositivos NAS com o QTS "clássico" ou versões anteriores do Virtualization Station.
Em termos de hardware, os dois dispositivos NAS não precisam ser exatamente do mesmo modelo, mas precisam usar processadores da mesma arquitetura e marca (ambos Intel ou ambos AMD) . Isso simplifica a compatibilidade e garante que as VMs replicadas possam ser executadas sem problemas em qualquer um dos dispositivos.
Em relação à rede, é essencial que ambos os dispositivos NAS estejam no mesmo segmento de rede e que haja uma conexão direta entre eles por meio de um cabo de rede físico dedicado para a sincronização de dados das máquinas virtuais. Essa conexão dedicada funciona como um canal "fora de banda" para replicação, evitando interferências com o tráfego normal do usuário.
Na prática, os requisitos de hardware se resumem a isto: a mesma família de CPUs e uma conexão direta entre os dispositivos NAS . Todo o resto (capacidade de disco, RAM, etc.) é dimensionado com base no número de VMs a serem protegidas e no desempenho esperado. Se essas condições forem atendidas, a configuração de alta disponibilidade (HA) da QNAP é relativamente simples e muito robusta.
Diferença entre alta disponibilidade e replicação/recuperação de desastres simples em máquinas virtuais.
As soluções de replicação de máquinas virtuais como mecanismo de recuperação de desastres são frequentemente confundidas com alta disponibilidade real, com tempo de inatividade zero (ou mínimo). Ambas são importantes, mas resolvem problemas diferentes.
Por exemplo, em ambientes VMware vSphere, é comum configurar a replicação de VMs para um site de recuperação de desastres (DR) , de forma que a imagem do disco do servidor primário seja copiada para o nó de recuperação de desastres. Isso protege contra a perda total do site primário, mas, quando este falha, geralmente é necessária uma recuperação manual: ligar as VMs no site de DR, reconfigurar as redes, validar a integridade dos dados e assim por diante.
Embora parcialmente automatizável, esse processo envolve períodos de inatividade que podem variar de minutos a horas, dependendo da complexidade do ambiente e dos procedimentos internos. É uma excelente estratégia de recuperação de desastres, mas não atende à meta de disponibilidade quase contínua esperada de uma solução de alta disponibilidade rigorosa.
A verdadeira alta disponibilidade exige um mecanismo de failover automático ou quase automático com tempo de inatividade muito baixo e sem necessidade de operações manuais complexas quando um componente falha. Além disso, a sincronização de dados entre os nós ativos e de backup deve ser suficientemente precisa para evitar ou minimizar a perda de informações recentes.
Portanto, ao projetar um ambiente de máquinas virtuais de alta disponibilidade, é essencial combinar adequadamente tecnologias de clusterização, replicação quase em tempo real, armazenamento redundante e monitoramento proativo . Somente assim os usuários poderão continuar acessando o site, o banco de dados ou o aplicativo corporativo com o mínimo de interrupção, mesmo que um servidor inteiro ou um NAS seja desligado repentinamente.
Na prática, a abordagem mais comum é complementar a alta disponibilidade local (por exemplo, um cluster dentro do mesmo centro de dados) com uma estratégia de recuperação de desastres em um local diferente . Dessa forma, tanto falhas do dia a dia (discos, servidores, fontes de alimentação, etc.) quanto eventos mais graves (incêndios, quedas de energia prolongadas, desastres naturais) ficam cobertos.
Essa ampla gama de soluções — clusters RHEL e Hyper-V, arquiteturas HA-DAS sem SAN, alta disponibilidade dedicada em NAS QNAP com Virtualization Station e replicação avançada de VMs — demonstra que agora é possível projetar ambientes virtualizados altamente tolerantes a falhas, adaptados a diferentes portes e orçamentos de empresas . Uma compreensão completa das diferenças entre cada abordagem, suas limitações (como o número máximo de nós ou a necessidade de armazenamento compartilhado) e seus requisitos técnicos é fundamental para escolher a combinação certa e manter os serviços críticos em funcionamento praticamente sem interrupções.
