OpenStack é uma plataforma de computação em nuvem de código aberto cuja arquitetura inclui serviços de computação, armazenamento e rede, fornecendo capacidades poderosas de virtualização e funções de gerenciamento automatizado. Para garantir a alta disponibilidade da plataforma OpenStack, é necessário adotar determinadas soluções arquitetônicas e medidas técnicas. Este artigo apresentará algumas soluções comuns de arquitetura para alta disponibilidade no OpenStack.
Alta Disponibilidade do OpenStack
Para compreender como alcançar alta disponibilidade, é fundamental identificar quais serviços são propensos a indisponibilidade. Primeiramente, vamos entender de forma básica a estrutura do OpenStack.
OpenStack é composto por cinco componentes principais: Computação (Nova), Gerenciamento de Identidade (Keystone), Gerenciamento de Imagens (Glance), Gerenciamento Front-end (Dashboard) e Armazenamento de Objetos (Swift).
Nova é o componente principal responsável pelo cálculo e controle. Ele inclui serviços como nova-compute, nova-scheduler, nova-volume, nova-network e nova-api. Assim como na maioria dos outros sistemas distribuídos, o OpenStack é dividido em dois tipos de nós: nós de controle e nós de computação. Os nós de controle fornecem todos os serviços, exceto o nova-compute. Esses componentes e serviços podem ser instalados independentemente, e as combinações podem ser escolhidas conforme necessário.
Nova-compute é executado em cada nó de computação. Por enquanto, vamos assumir que ele seja confiável; caso contrário, uma máquina de backup pode ser usada para failover (embora configurar um backup para cada nó de computação possa ser muito custoso em comparação com os benefícios).
Alta Disponibilidade do Nó de Controle
Garantir a alta disponibilidade do nó de controle é o principal desafio, e diferentes componentes possuem seus próprios requisitos e soluções específicas de disponibilidade.
(1) O que acontece se o nó de controle falhar, considerando que há apenas um nó de controle gerenciando e controlando todo o sistema?
Este é o problema comum de único ponto de falha (SPoF). Alta disponibilidade não pode ser alcançada somente com uma única máquina. Com frequência, uma solução é projetada para garantir a rápida substituição da máquina com falha quando um problema ocorre, embora isso implique em custos mais elevados.
Para resolver o problema do ponto único de falha, a solução típica é utilizar dispositivos redundantes ou em espera quente. Uma vez que falhas de hardware ou erros humanos sempre podem causar falhas em um ou vários nós, e manutenção ou atualizações às vezes exigem parar temporariamente certos nós, um sistema confiável deve ser capaz de suportar a interrupção de um ou vários nós.
Modos comuns de implantação incluem: modo standby ativo-passivo, modo ativo-ativo e modo cluster
(2) Como construir nós de controle redundantes? Ou que outros métodos podem alcançar um controle altamente confiável?
Muitos podem considerar a implementação de um modo ativo-passivo, utilizando um mecanismo de heartbeat ou métodos semelhantes para backup, e alcançar Alta Disponibilidade através de failover. O OpenStack não suporta inerentemente vários nós de controle, então o Pacemaker requer que vários serviços implementem por conta própria seus próprios mecanismos de backup, monitoramento e comutação.
Uma análise mais detalhada dos serviços fornecidos pelo nó de controle revela que eles incluem principalmente nova-api, nova-network, nova-scheduler, nova-volume, além do Glance, Keystone e o banco de dados MySQL. Esses serviços são fornecidos separadamente. O nova-api, o nova-network e o Glance podem ser executados em cada nó de computação, o RabbitMQ pode operar em modo primário-secundário, e o MySQL pode utilizar um cluster redundante com alta disponibilidade.
As seguintes seções detalham esses componentes.
Soluções de Alta Disponibilidade para Componentes Principais
1) Alta Disponibilidade do nova-api e do nova-scheduler
Cada nó de computação pode executar seu próprio nova-api e nova-scheduler, garantindo o balanceamento de carga para um funcionamento adequado. Dessa forma, quando o nó de controle falha, o nova-api e os serviços relacionados nos nós de computação continuam funcionando normalmente.
2) Alta Disponibilidade do nova-volume
Atualmente, não existe uma solução perfeita de HA para o nova-volume e mais trabalho é necessário. No entanto, como o nova-volume é baseado em iSCSI, integrá-lo com DRBD ou usar uma solução de hardware de alta disponibilidade baseada em iSCSI pode alcançar alta disponibilidade.
3) Alta Disponibilidade de Serviços de Rede (nova-network)
O OpenStack já oferece várias soluções de rede com alta disponibilidade. Uma abordagem comumente utilizada é ativar o modo de alta disponibilidade usando a opção "Multi-host". Outras soluções comuns incluem Failover, Multi-nic, Gateway de Hardware e Quantum.
4) Alta Disponibilidade de Glance e Keystone
As imagens do OpenStack podem ser armazenadas utilizando o Swift, e o Glance pode ser executado em múltiplos hosts. O Pacemaker é uma solução poderosa de alta disponibilidade para gerenciar clusters de múltiplos nós, implementando a troca de serviços e recuperação após falhas, podendo ser utilizado com Corosync e Heartbeat. O Pacemaker suporta flexivelmente vários modos, como ativo-passivo, N+1 e N-N. Ao instalar o agente OCF em cada nó, ele pode determinar se outro nó está executando corretamente os serviços Glance e Keystone, ajudando o Pacemaker a iniciar, parar e monitorar esses serviços.
5) Alta Disponibilidade do Swift Object Storage
Normalmente, o sistema de armazenamento de objetos distribuído do OpenStack, o Swift, não requer configurações adicionais de HA. Isso acontece porque o Swift foi projetado com uma arquitetura distribuída (sem nó mestre), mecanismos de tolerância a falhas, redundância, recuperação de dados, escalabilidade e alta disponibilidade.
6) Alta disponibilidade do serviço de fila de mensagens (RabbitMQ)
Se o RabbitMQ falhar, as mensagens podem ser perdidas. Múltiplos mecanismos de HA podem ser utilizados:
O método de confirmação do editor notifica quando os dados são gravados no disco em caso de falha.
O mecanismo de cluster de múltiplos nós pode ser utilizado, mas falhas nos nós ainda podem levar a falhas nas filas.
O modo ativo-passivo garante o failover em caso de falha, mas a inicialização do nó de backup pode envolver atrasos ou até mesmo falhas.
Para recuperação de desastres e disponibilidade, o RabbitMQ fornece filas persistentes que armazenam mensagens não processadas em disco caso o serviço da fila falhe. Para evitar perda de mensagens devido a atrasos entre o envio e a gravação das mensagens, o RabbitMQ introduz o mecanismo Publisher Confirm para garantir que as mensagens sejam realmente escritas em disco.
Para suporte a clusters, o RabbitMQ oferece modos Ativo/Passivo e Ativo/Ativo. Por exemplo, no modo Ativo/Passivo, quando um nó falha, o nó passivo é imediatamente ativado e substitui rapidamente o nó ativo falho para continuar gerenciando a entrega de mensagens.
Construindo um OpenStack de Alta Disponibilidade
Em geral, a alta disponibilidade é alcançada estabelecendo redundância e backups. Estratégias comuns incluem:
Modo cluster. Backup mútuo entre múltiplas máquinas, em que cada instância é backupada várias vezes sem um nó central. Exemplos incluem o sistema de armazenamento de objetos distribuído Swift e o modo multi-host do nova-network.
Modo autônomo. Em alguns casos, o SPoF pode ser abordado permitindo que cada nó opere independentemente, eliminando relações mestre-escravo para reduzir o impacto de um nó de controle com falha. Por exemplo, o nova-api é responsável apenas pelo seu próprio nó.
Modo ativo-passivo. Esse modelo comum envolve um nó passivo que permanece em estado de espera e backup, fazendo a transferência quando ocorre uma falha. Exemplos incluem clusters de alta disponibilidade do MySQL e serviços como Glance e Keystone, que alcançam redundância por meio do Pacemaker e Heartbeat.
Modo ativo-ativo. Neste modo, os nós se respaldam e se apoiam mutuamente. Por exemplo, o RabbitMQ utiliza um cluster de alta disponibilidade em modo ativo-ativo, onde os nós do cluster podem replicar filas. Do ponto de vista arquitetônico, essa abordagem elimina preocupações sobre falhas na inicialização dos nós passivos ou atrasos excessivos.
Em resumo, a otimização e as melhorias do OpenStack estão em constante evolução, e sua implantação e aplicações estão sendo cada vez mais exploradas e desenvolvidas. O ajuste prático é essencial – boas ideias e projetos precisam de testes reais para serem validados.
Proteção Aprimorada do OpenStack
Embora o OpenStack reduza o risco de falha única no sistema por meio da redundância e da arquitetura de alta disponibilidade, a proteção de dados ainda é fundamental. Para garantir a continuidade dos negócios, é necessário adotar uma solução profissional de backup para prevenir a perda de dados e o impacto de falhas catastróficas.
Vinchin Backup & Recovery é uma solução de backup robusta para OpenStack que oferece backups sem agente e eficientes, com recursos como deduplicação de dados, compressão, backups incrementais, recuperação em nível de arquivo e arquivamento na nuvem, entre outros. Garante recuperação rápida, integração perfeita com o OpenStack e alta segurança dos dados, sendo a escolha ideal para gerenciar e proteger ambientes em nuvem.
Além disso, criptografia de dados e proteção contra ransomware oferecem a você dupla proteção para garantir seus backups de VM do OpenStack. Você também pode simplesmente migrar dados de um host OpenStack para outra plataforma virtual (como VMware, Hyper-V, Proxmox, XenServer, oVirt, AWS EC2...) e vice-versa.
Vinchin Backup & Recovery permite fazer backup de VMs do OpenStack em apenas 4 passos:
1. Selecione o objeto de backup.
2. Selecione o destino do backup.
3. Configure as estratégias de backup.
4. Revise e envie o trabalho.
Vinchin Backup & Recovery é confiado por milhares de empresas. Inicie hoje seu teste completo de 60 dias!
Perguntas Frequentes sobre Alta Disponibilidade do OpenStack
1. O que é a zona de disponibilidade no OpenStack?
Em OpenStack, uma Zona de Disponibilidade (AZ) é uma partição lógica dentro de um ambiente em nuvem que ajuda a distribuir cargas de trabalho para melhor tolerância a falhas e gerenciamento de recursos. Cada AZ é um domínio de falha isolado, o que significa que instâncias em diferentes AZs têm menor probabilidade de ser afetadas pelas mesmas falhas de hardware ou rede. As Zonas de Disponibilidade são normalmente utilizadas para agrupar nós de computação, enquanto serviços de armazenamento e rede também podem ter suas próprias zonas para maior resiliência e redundância. Os usuários podem especificar uma AZ ao iniciar instâncias para otimizar desempenho e confiabilidade.
2. O OpenStack é SAAS ou PaaS?
OpenStack é principalmente uma plataforma de IaaS. Ela fornece recursos de computação, armazenamento e rede virtualizados, permitindo aos usuários implantar e gerenciar infraestrutura em nuvem. Embora o OpenStack possa dar suporte a soluções PaaS executando serviços como Kubernetes ou Cloud Foundry sobre ela, sua função principal é fornecer IaaS, e não SaaS ou PaaS.
Conclusão
Garantir alta disponibilidade no OpenStack requer uma combinação de estratégias arquitetônicas e soluções técnicas para eliminar pontos únicos de falha e aumentar a resiliência do sistema. Ao implementar modos ativo-passivo e ativo-ativo, utilizar técnicas de agrupamento e otimizar componentes essenciais como Nova, Glance, Keystone e RabbitMQ, o OpenStack pode alcançar uma infraestrutura em nuvem tolerante a falhas e altamente confiável. Além disso, soluções de armazenamento distribuído como o Swift fornecem naturalmente redundância e resiliência.
