Arquitetura de uma implantação virtual OpenStack (Juju/MAAS) com 1 nó físico

Question

Gostaria de demonstrar alguns dos recursos HA/FT do OpenStacks (mais importante ainda, migração ao vivo e replicação de armazenamento). Para isso, possuo uma máquina com 32 GB de RAM e um Xeon e3v2 com 4 núcleos (8 threads). Até agora consegui colocar o MAAS e o Juju em funcionamento, mas não tenho certeza sobre o número de nós virtuais que posso implantar com segurança (e a taxa de alocação excessiva de CPU/RAM, embora eu tenha lido em algum lugar que a CPU física pode lidar muito bem com overcommitting com máquinas 1-vcpu).

Atualmente, a VM que executa o MAAS usa 1 vCPU e 8 GB de RAM, o Juju é executado no host. Isso me deixa com 7 vCPUs e 24 GB de RAM sem sobrecarregar nenhum recurso. O que eu descobri é o seguinte:

• 1 nó controlador: 2vCPUs, 4GB de RAM - RabbitMQ, mysql, keystone, dashboard, cinder, nova-cloud-controller e Glance em contêineres lxc
• 2 nós Ceph: 1 vCPU, 4 GB de RAM cada - ceph
• 2 nós de computação: 2 vCPUs, 8 GB de RAM cada - nova-compute
• 1 nó de rede: 1 vCPU, 2 GB de RAM - gateway quântico
• Mais o host MAAS: 1 vCPU, 8 GB de RAM

Isso resultaria em um total de 38 GB de RAM e 10 vCPUs, então estou me comprometendo um pouco demais.

Minha verdadeira pergunta é se alguém tem uma arquitetura melhor em mente. Na verdade, pretendo mostrar alguns recursos do OpenStack (ou das nuvens em geral).

Answer 1

Eu tenho uma configuração semelhante e deixe-me sugerir sua configuração:

• Reduza a quantidade de RAM atribuída ao MAAS, cerca de 2 GB serão suficientes.
• Adicione outro nó ceph, isso ajudará você a demonstrar resiliência ao usar ceph e 1 nó ficar inativo.
• Overcommit na CPU não é tão ruim, mas você não quer overcommit na memória, porque o sistema começará a trocar e tudo ficará com desempenho inutilizável.
• Algo que você não menciona são os discos que você tem, isso é um grande gargalo para mim, tenho discos de 2 x 7200 RPMs com btrfs (raid0), mas não é suficiente enquanto o juju está implantando.
• Além disso, você pode usar o juju-deployer e ajustar a linha de comando usada para implantar, especificamente modificadores de tempo limite e '-s', que é um atraso entre cada chamada de "implantação do juju".

Eu espero que isso ajude.

Filipe,

Answer 2

Eu sugiro que você jogue fora se ainda estiver em execução e use o LXD. Você não deve ter problemasimplantando issosem MaaS e apenas executando Juju com controle local do seu LXD localconforme descrito aqui. Sua máquina deve ser capaz de funcionar sem suar muito. Se você precisar de MaaS para demonstrá-lo (é realmente incrível. Você deve tentar conferir os Openstack Roadshows que a Canonical faz se alguém chegar por perto...), então fica um pouco mais complicado.

Esta referência demonstraconfigurando em 3 máquinas, mas você pode ser sorrateiro e implantar Juju e MaaS na mesma outra máquina se realmente precisar. Se sua segunda máquina estivesse executando MaaS e JuJu no LXD com a ponte conectada à LAN do seu laboratório e seu tráfego PXE pudesse passar, você deveria ser capaz de executar tudo em contêineres em duas máquinas. Estou tentando fazer algo semelhante com VMs VMWare Fusion em meu laptop, onde conectei a rede interna a uma NIC Thunderbolt para permitir que as máquinas MaaS e Juju orquestrem dispositivos Raspberry Pi e NUC.

Answer 3

Não tenho experiência em usar juju para orquestração openstack, mas pela experiência com ceph e openstack, para fins de demonstração você pode executar ceph em máquinas de 2 GB sem problemas e acho que o host maas também pode ser configurado com 6 GB em vez de 8.

Não sei se o juju permite combinar diferentes funções na mesma VM, em nossas implantações (não juju) combinamos o controlador e as funções de rede na mesma VM (sem usar contêineres).

Answer 4

Ao usar nós físicos em um cluster pequeno, especialmente coisas do tipo test-lab, um atalho típico é combinar os nós ceph com seus nós de computação. Veja este conjunto de era ceph-0.48instruções para debian, ou este mais modernoconfiguração de laboratório para proxmox VE.

Usando os números que você forneceu e as sugestões para diminuições de RAM mais ceph triplo nas outras respostas, talvez algo assim:

1. 3vCpu + 8gb == RabbitMQ/keystone/glance/etc + cephMon1/Osd1
2. 2vCpu + 10gb == novaComp2/Net2/Vol2 + cephMon2/Osd2/Httpd2/Rgw2
3. 2vCpu + 10gb == novaComp3/Net3 + cephMon3/Osd3
4. 1vCpu + 2gb == novaQuantum4
5. 1vCpu + 3gb == MAAS_host5

Atualmente estou trabalhando em uma configuração de um nó dessa natureza, mas tenho menos RAM disponível e apenas quatro discos para dedicar (cephOsd é melhor com vários discos). Não posso confirmar se os números acima funcionarão para você com desempenho adequado, não tendo tentado esse esquema sozinho, mas a ideia central de mesclar nós um tanto ortogonais para ser parcimonioso com vCpu e ram pode lhe dar tração suficiente para chegar aonde deseja.

ps Veja também, helpdocs semi-oficiais para OpenStack em um nó físico comumVM, além do tutorial OpenStack mais relevante em uma caixa dedicada, em devstack.org