O que acontece se um controlador de nuvem OpenStack morrer?

Question

Estou lendo sobre o OpenStack e como podemos recriar uma nuvem no estilo EC2 / S3 para nosso desenvolvimento interno e estou tendo dificuldades em encontrar informações sobre como o controlador de nuvem OpenStack fornece redundância da nuvem serviços de gerenciamento.

Eu sei que posso configurar vários nós Swift e Nova, mas nenhum documento / artigo / howto / wiki contém informações sobre:

a) o que acontece se o nó do controlador de nuvem morrer; e b) como configurar controladores de nuvem redundantes.

Parece-me que, embora seja massivamente escalável, existe um grande ponto único de falha incorporado no OpenStack.

Alguém com mais experiência no OpenStack pode esclarecer como tudo funciona em termos de alta disponibilidade?

    

Answer 1

Existem algumas opções de configuração de alta disponibilidade para o OpenStack. Dois possíveis pontos únicos de falha são os seguintes serviços, que tradicionalmente são executados apenas em um único nó ("controlador de nuvem"):

• Serviço de API (nova-api) que campos solicitações recebidas
• serviço de rede (nova-network) que lida com problemas de rede (DHCP, DNS, NAT, etc.)

Para a nova-api, acredito que você possa executar várias instâncias em diferentes nós físicos, já que o estado é mantido no banco de dados externo.

Para configurar o serviço de rede para ser executado no modo de alta disponibilidade, você precisa usar a opção de configuração --multi_host em seu arquivo de nova configuração. Consulte a documentação do OpenStack em Opções de disponibilidade de alta disponibilidade existentes para redes

    

Answer 2

Não ando brincando com o OpenStack, mas se o controlador de nuvem for realmente um ponto único de falha: uma maneira de evitar problemas seria dedicar dois servidores para isso e configurar o Heartbeat v2 (ou o Corosync / Pacemaker como é chamado hoje em dia) entre eles no modo ativo-passivo.

Dessa forma, se o servidor principal morrer por qualquer motivo, o outro pegará sua carga de trabalho em (milli) segundos.

    

Answer 3

"... Ainda melhor: o nó do controlador agora hospeda apenas componentes de plataforma que não são serviços internos do OpenStack (o MySQL e o RabbitMQ são daemons padrão do Linux). Portanto, o administrador da nuvem pode passar a administração deles para uma entidade externa , Database Team, um cluster RabbitMQ dedicado, desta forma, o nó controlador central desaparece e acabamos com um monte de nós de computação / API, que podemos escalar quase linearmente. "

link