Oi, Habr!
Após o feriado de Ano Novo, relançamos uma nuvem à prova de desastres baseada em dois locais. Hoje vamos contar como funciona e mostrar o que acontece com as máquinas virtuais clientes quando elementos individuais do cluster falham e todo o site trava (spoiler – está tudo bem com eles).
Sistema de armazenamento em nuvem resistente a desastres no site OST.
O que tem dentro
Internamente, o cluster possui servidores Cisco UCS com um hipervisor VMware ESXi, dois sistemas de armazenamento INFINIDAT InfiniBox F2240, equipamentos de rede Cisco Nexus, bem como switches Brocade SAN. O cluster está dividido em dois sites - OST e NORD, ou seja, cada data center possui um conjunto idêntico de equipamentos. Na verdade, é isso que o torna à prova de desastres.
Dentro de um site, os elementos principais também são duplicados (hosts, switches SAN, rede).
Os dois locais estão conectados por rotas dedicadas de fibra óptica, também reservadas.
Algumas palavras sobre sistemas de armazenamento. Construímos a primeira versão de uma nuvem à prova de desastres na NetApp. Aqui escolhemos INFINIDAT e aqui está o porquê:
- Opção de replicação ativo-ativo. Ele permite que a máquina virtual permaneça operacional mesmo se um dos sistemas de armazenamento falhar completamente. Falarei mais sobre replicação mais tarde.
- Três controladores de disco para aumentar a tolerância a falhas do sistema. Geralmente há dois.
- Solução pronta. Recebemos um rack pré-montado que só precisa ser conectado à rede e configurado.
- Suporte técnico atencioso. Os engenheiros da INFINIDAT analisam constantemente logs e eventos do sistema de armazenamento, instalam novas versões de firmware e ajudam na configuração.
Aqui estão algumas fotos da descompactação:
Como funciona
A nuvem já é tolerante a falhas por si só. Ele protege o cliente contra falhas únicas de hardware e software. A resistência a desastres ajudará a proteger contra falhas massivas em um site: por exemplo, falha de um sistema de armazenamento (ou cluster SDS, o que acontece com bastante frequência 🙂), erros massivos em uma rede de armazenamento, etc. Bem, e o mais importante: essa nuvem salva quando um local inteiro se torna inacessível devido a um incêndio, apagão, aquisição de invasores ou pouso alienígena.
Em todos esses casos, as máquinas virtuais clientes continuam funcionando e aqui está o porquê.
O design do cluster foi projetado para que qualquer host ESXi com máquinas virtuais clientes possa acessar qualquer um dos dois sistemas de armazenamento. Se o sistema de armazenamento no site OST falhar, as máquinas virtuais continuarão a funcionar: os hosts nos quais estão sendo executadas acessarão o sistema de armazenamento no NORD para obter dados.
Esta é a aparência do diagrama de conexão em um cluster.
Isso é possível devido ao fato de um link entre switches ser configurado entre as malhas SAN dos dois locais: o switch SAN Fabric A OST está conectado ao switch SAN Fabric A NORD e da mesma forma para os switches SAN Fabric B.
Bem, para que todos esses meandros das fábricas SAN façam sentido, a replicação Ativo-Ativo é configurada entre os dois sistemas de armazenamento: as informações são gravadas quase simultaneamente nos sistemas de armazenamento local e remoto, RPO = 0. Acontece que os dados originais são armazenados em um sistema de armazenamento e sua réplica é armazenada em outro. Os dados são replicados no nível dos volumes de armazenamento e os dados da VM (seus discos, arquivo de configuração, arquivo de troca, etc.) são armazenados neles.
O host ESXi vê o volume primário e sua réplica como um dispositivo de disco (dispositivo de armazenamento). Existem 24 caminhos do host ESXi para cada dispositivo de disco:
12 caminhos conectam-no ao sistema de armazenamento local (caminhos ideais) e os 12 restantes ao sistema de armazenamento remoto (caminhos não ideais). Em uma situação normal, o ESXi acessa dados no sistema de armazenamento local usando caminhos “ideais”. Quando esse sistema de armazenamento falha, o ESXi perde os caminhos ideais e muda para caminhos “não ideais”. Isto é o que parece no diagrama.
Esquema de um cluster à prova de desastres.
Todas as redes de clientes estão conectadas a ambos os sites por meio de uma estrutura de rede comum. Cada site executa um Provider Edge (PE), no qual as redes do cliente são encerradas. PEs estão unidos em um cluster comum. Se um PE falhar em um site, todo o tráfego será redirecionado para o segundo site. Graças a isso, as máquinas virtuais do site deixado sem PE permanecem acessíveis ao cliente pela rede.
Vamos agora ver o que acontecerá com as máquinas virtuais clientes durante várias falhas. Vamos começar com as opções mais leves e terminar com as mais graves - a falha de todo o site. Nos exemplos, a plataforma principal será a OST, e a plataforma de backup, com réplicas de dados, será a NORD.
O que acontece com a máquina virtual cliente se...
O link de replicação falha. A replicação entre os sistemas de armazenamento dos dois locais é interrompida.
O ESXi funcionará apenas com dispositivos de disco locais (por meio de caminhos ideais).
As máquinas virtuais continuam funcionando.
O ISL (Inter-Switch Link) quebra. O caso é improvável. A menos que alguma escavadeira maluca desenterre várias rotas ópticas ao mesmo tempo, que seguem rotas independentes e são levadas aos locais por meio de diferentes insumos. Mas mesmo assim. Nesse caso, os hosts ESXi perdem metade dos caminhos e só podem acessar seus sistemas de armazenamento locais. As réplicas são coletadas, mas os hosts não poderão acessá-las.
As máquinas virtuais estão funcionando normalmente.
O switch SAN falha em um dos sites. Os hosts ESXi perdem alguns dos caminhos para o sistema de armazenamento. Neste caso, os hosts no local onde o switch falhou funcionarão apenas através de um de seus HBAs.
As máquinas virtuais continuam funcionando normalmente.
Todos os switches SAN em um dos sites falham. Digamos que tal desastre tenha acontecido no site OST. Nesse caso, os hosts ESXi neste site perderão todos os caminhos para seus dispositivos de disco. O mecanismo padrão do VMware vSphere HA entra em ação: ele reiniciará todas as máquinas virtuais do site OST no NORD em no máximo 140 segundos.
As máquinas virtuais executadas nos hosts do site NORD estão operando normalmente.
O host ESXi falha em um site. Aqui o mecanismo vSphere HA funciona novamente: as máquinas virtuais do host com falha são reiniciadas em outros hosts - no mesmo site ou em um site remoto. O tempo de reinicialização da máquina virtual é de até 1 minuto.
Se todos os hosts ESXi no site OST falharem, não há opções: as VMs serão reiniciadas em outro. O tempo de reinicialização é o mesmo.
O sistema de armazenamento falha em um local. Digamos que o sistema de armazenamento falhe no site OST. Em seguida, os hosts ESXi do site OST passam a trabalhar com réplicas de armazenamento no NORD. Depois que o sistema de armazenamento com falha retornar ao serviço, ocorrerá a replicação forçada e os hosts ESXi OST começarão novamente a acessar o sistema de armazenamento local.
As máquinas virtuais funcionaram normalmente todo esse tempo.
Um dos sites falha. Nesse caso, todas as máquinas virtuais serão reiniciadas no site de backup por meio do mecanismo vSphere HA. O tempo de reinicialização da VM é de 140 segundos. Nesse caso, todas as configurações de rede da máquina virtual serão salvas e ela permanecerá acessível ao cliente pela rede.
Para garantir que a reinicialização das máquinas no site de backup ocorra sem problemas, cada site está cheio apenas pela metade. A segunda metade é uma reserva caso todas as máquinas virtuais saiam do segundo site danificado.
Uma nuvem resistente a desastres baseada em dois data centers protege contra tais falhas.
Esse prazer não sai barato, pois, além dos recursos principais, é necessária uma reserva no segundo local. Portanto, os serviços críticos para os negócios são colocados nessa nuvem, cujo tempo de inatividade a longo prazo causa grandes perdas financeiras e de reputação, ou se o sistema de informação estiver sujeito a requisitos de resiliência a desastres por parte dos reguladores ou regulamentos internos da empresa.
Fontes:
Fonte: habr.com