Webinar
Eventos ITGLOBAL.COM

Blog

Blog
hiperconvergência

Cluster de 2 Nós: Guia de Alta Disponibilidade e Virtualização

Para muitas empresas, implementar alta disponibilidade ainda significa aumentar a infraestrutura: mais servidores, storage dedicado e maior complexidade operacional. Mas nem todo ambiente precisa de um cluster tradicional com três ou mais nós. Um cluster de 2 nós permite criar uma infraestrutura de virtualização resiliente utilizando apenas dois servidores físicos, reduzindo CAPEX, espaço ocupado e complexidade de operação sem abrir mão da continuidade dos serviços. Na plataforma vStack, os dois nós trabalham em alta disponibilidade e compartilham o acesso aos dados necessários para manter as máquinas virtuais em operação. Se um servidor falhar, o outro pode assumir os workloads, reduzindo o downtime e o impacto sobre aplicações críticas. Para CTOs e líderes de infraestrutura, esse modelo pode ser especialmente relevante em filiais, edge computing, ambientes de menor porte, projetos com restrição de orçamento ou cenários em que uma arquitetura de três ou mais nós seria superdimensionada. Neste guia, analisamos como funciona um cluster de 2 nós, quais arquiteturas podem ser utilizadas com vStack e em quais cenários essa abordagem faz mais sentido. Classificação geral As arquiteturas de Cluster de 2 Nós podem ser divididas em duas categorias principais:  Categoria  Funcionamento  Árbitro  Armazenamento Compartilhado  Ambos os nós acessam os mesmos discos físicos  Não necessário  Discos Locais  Cada nó possui seus próprios discos e os dados são replicados sincronamente  Necessário  Com base nessas categorias, a vStack suporta três modelos principais de implantação.  Tipo 1: Armazenamento externo (JBOD/JBOF)  Como funciona  Os dois controladores são conectados a gavetas de discos externas (JBOD ou JBOF) através de adaptadores HBA e infraestrutura de cabeamento dedicada.  Os discos ficam simultaneamente visíveis para ambos os servidores.  O controle de acesso e a prevenção de conflitos de gravação são realizados por software, utilizando mecanismos como SCSI Persistent Reservations.  Exemplos de hardware  Dell PowerEdge R760 / R660  HPE ProLiant DL380 Gen10 Plus  Vantagens   Alta escalabilidade de armazenamento   Possibilidade de adicionar novas gavetas de discos  Sem necessidade de replicação de dados   Menor consumo de recursos computacionais  Failover praticamente instantâneo  Não requer árbitro  Limitações  Custo mais elevado  Necessidade de HBAs dedicados  Infraestrutura adicional de cabeamento   Dependência física das gavetas de armazenamento   JBOF requer SSDs NVMe dual-port especializados  text_with_btn btn="Fale conosco agora" link="https://br.itglobal.com/vstack-service-provider-program/" small" Crie seu serviço em nuvem /text_with_btn Tipo 2: Chassi dual-node com backplane compartilhado  Como funciona  Os dois nós ficam instalados dentro de um único chassi equipado com um backplane compartilhado.  Os discos são acessíveis simultaneamente por ambos os controladores através de caminhos redundantes.  A plataforma vStack gerencia os mecanismos de bloqueio para evitar conflitos de escrita.  Arquitetura  Cada disco possui dois caminhos de acesso:  Caminho 1 → Controlador 1  Caminho 2 → Controlador 2  Exemplos de hardware  Supermicro BigTwin  Supermicro TwinPro  Supermicro FatTwin  Dell PowerEdge C6620  HPE Apollo XL170r / XL190r  Lenovo ThinkSystem SD530  Vantagens   Alta densidade computacional  Menor ocupação física  Cabeamento simplificado  Latência extremamente baixa  Failover instantâneo  Não necessita árbitro  Limitações  Hardware especializado  Escalabilidade limitada pelo chassi  Ponto único de falha no próprio chassi  Sem possibilidade de distribuição geográfica Tipo 3: Nós independentes com discos locais  Nesse modelo, cada servidor possui armazenamento próprio, os discos não são compartilhados fisicamente e a consistência dos dados é garantida por replicação síncrona realizada pela camada de software da vStack.  O componente crítico desta arquitetura é o árbitro (mediator).  Por que o árbitro é necessário?  Sem armazenamento compartilhado, uma falha de comunicação entre os nós pode gerar o chamado problema de split-brain, situação em que ambos os servidores acreditam ser o nó principal.  O árbitro atua como um terceiro voto para determinar qual servidor permanece ativo.  Tipo 3A: Nós próximos  Os dois servidores ficam no mesmo rack ou no mesmo datacenter.  A replicação síncrona ocorre através de rede de alta velocidade.  Requisitos recomendados  Rede de 10/25/100 GbE  Latência inferior a 1 ms  VLAN ou interface dedicada para heartbeat  Tipo 3B: Stretched Cluster (Cluster Geograficamente Distribuído)  Nesse cenário, os nós ficam instalados em datacenters distintos.  Essa arquitetura protege contra falhas completas de uma instalação, incluindo:  Incêndios;  Falhas elétricas;  Desastres naturais;  Indisponibilidade total do site.  Requisitos de rede  Parâmetro  Cluster Local  Stretched Cluster  Replicação  LAN 10/25/100 GbE  WAN, DWDM ou Dark Fiber  Latência  < 1 ms  Recomendado < 5 ms  Máximo aceitável  -  < 10 ms  Heartbeat  VLAN dedicada  Canal dedicado    Papel do árbitro (Mediator)  O árbitro é obrigatório para as arquiteturas Tipo 3.  Trata-se de uma máquina virtual leve responsável por:  Manter heartbeat com ambos os nós;  Monitorar disponibilidade;  Participar do quórum;  Evitar split-brain;  Determinar qual nó permanece ativo em caso de falha de comunicação.  Requisitos mínimos  1 vCPU  512 MB de RAM  Conectividade confiável com ambos os nós  Para ambientes geograficamente distribuídos, recomenda-se hospedar o árbitro em uma terceira localização independente.    Comparação dos modelos  Característica  Tipo 1  Tipo 2  Tipo 3A  Tipo 3B  Armazenamento compartilhado  Sim  Sim  Não  Não  Necessita árbitro  Não  Não  Sim  Sim  Replicação  Não  Não  Síncrona  Síncrona  Distribuição geográfica  Não  Não  Não  Sim  Tempo de failover  Instantâneo  Instantâneo  Segundos  Segundos  Escalabilidade de armazenamento  Alta  Limitada  Limitada  Limitada  Hardware especializado  Sim  Sim  Não  Não  Proteção contra falha de site  Não  Não  Não  Sim  Recomendações de escolha  Tipo 1 – JBOD/JBOF  Ideal para:  Datacenters médios e grandes;  Ambientes com alta demanda de armazenamento;  Projetos que exigem expansão contínua de capacidade.  Tipo 2 – Chassi compartilhado  Ideal para:  Espaços físicos reduzidos;  Ambientes com necessidade de baixa latência;  Infraestruturas compactas.  Tipo 3 – Replicação entre nós independentes  Ideal para:  Uso de hardware padrão;  Maior flexibilidade de implantação;  Ambientes distribuídos geograficamente;  Estratégias de recuperação de desastres.  Casos de uso típicos  Virtualização resiliente em filiais Dois servidores compactos executam todas as cargas da filial com reinicialização automática em caso de falha.  Cluster HA para pequenas e médias empresas Permite alta disponibilidade sem a necessidade de um terceiro servidor dedicado.  Benefícios:  Implantação rápida;  Menor custo;  Possibilidade de expansão futura.  Serviços de borda (Edge Computing) Ideal para:  Bancos de dados locais;  Gateways;  Sistemas SCADA;  Aplicações industriais;  Serviços de cache.  O cluster garante disponibilidade local e gestão simplificada mesmo em ambientes remotos.  Conclusão  Os clusters de dois nós representam uma alternativa eficiente para organizações que precisam de alta disponibilidade sem investir em arquiteturas complexas de três ou mais servidores.  A plataforma vStack suporta diferentes modelos de implantação, permitindo escolher entre armazenamento compartilhado, backplane comum ou replicação síncrona entre servidores independentes.  A escolha ideal dependerá do orçamento, dos requisitos de disponibilidade, da necessidade de expansão e do nível de proteção desejado contra falhas de infraestrutura. 
Todas as categorias 96 Blog 28 hiperconvergência 7 ITSM 5 Virtualization 6 Private Cloud 1 SimpleOne 1 Solutions 26 Network 1 Stingray 1 IA 1 Performance 7 #public cloud 8 Clouds 8 GPU 2 IaaS 3 Processes 2 VDI 5 Hardware 4 DevOps 1 Managed IT 2 Security 1 #security 5 Trends 1 News 1 DPI 6 Managed DevOps 2 Practice 1
Usamos cookies para otimizar a funcionalidade do site e aprimorar nossos serviços. Para saber mais, leia nossa Política de Privacidade.
Configurações de cookies
Cookies estritamente necessários
Cookies analíticos