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

Question

Gostaria de demonstrar alguns dos recursos do OpenStacks HA / FT (mais importante, migração ao vivo e replicação de armazenamento). Para isso, tenho 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 overcommit de CPU / RAM, embora eu tenha lido em algum lugar que o físico A CPU pode lidar com a supercomprometimento com máquinas 1-vcpu muito bem).

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 comprometer demais os recursos. O que eu tenho é o seguinte:

1 Nó do Controlador: 2vCPUs, 4GB de RAM - RabbitMQ, mysql, keystone, painel de controle, cinder, nova-cloud-controller e relance em contêineres lxc

2 nós Ceph: 1 vCPU, 4 GB de RAM cada - ceph

2 nós de cálculo: 2 vCPUs, 8 GB de RAM cada - nova-compute

1 Nó da rede: 1 vCPU, 2 GB de RAM - gateway quântico

Além disso, o host MAAS: 1 vCPU, 8 GB de RAM

Isso resultaria em um total de 38 GB de RAM e 10 vCPUs, por isso estou supercomprometendo um pouco.

Minha pergunta atual é se alguém tem uma arquitetura melhor em mente. Eu realmente pretendo mostrar apenas alguns recursos do OpenStack (ou Nuvens em geral).

    

Answer 1

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

• Reduza a quantidade de RAM atribuída ao MAAS, em torno de 2 GB será suficiente.
• Adicione outro nó ceph, isso ajudará você a demonstrar a resiliência ao usar o ceph e 1 nó ficar inativo.
• A supercomprometimento na CPU não é tão ruim assim, mas você não quer se comprometer demais com a memória, porque o sistema começará a trocar e tudo terá um desempenho inutilizável.
• Algo que você não menciona são os discos que você tem, esse é um grande gargalo para mim, eu tenho discos de 2 x 7200 RPMs com btrfs (raid0), mas isso não é suficiente enquanto o juju está sendo implantado.
• Além disso, você pode querer usar juju-deployer e ajustar a linha de comando que você usa para implementar, especificamente modificadores de timeout e '-s', que é um atraso entre cada chamada de "juju deploy".

Espero que isso ajude.

Felipe,

    

Answer 2

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

Esta referência demonstra configuração em 3 máquinas , mas você pode obter sneaky e implantar Juju e MaaS para a mesma máquina, se você realmente precisa. Se a sua segunda máquina estava executando o MaaS e o JuJu sob o LXD com a ponte conectada ao seu laboratório, a LAN e seu tráfego PXE poderiam passar, você deveria ser capaz de rodar tudo em containers em duas máquinas. Eu estou tentando fazer algo semelhante com VMWare Fusion VMs no meu laptop, onde eu conectei a rede interna a uma NIC Thunderbolt para permitir que as máquinas MaaS e Juju orquestrassem os dispositivos Raspberry Pi e NUC.

    

Answer 3

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

Eu não sei se o juju permite que você combine funções diferentes na mesma VM, em nossas implementações (não-juju) combinamos o controlador e as funções de rede na mesma VM (não usando containers).

    

Answer 4

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

Usando os números que você forneceu, e as sugestões para diminuições de ram mais triple-ceph 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 memória RAM disponível e apenas quatro discos para dedicar (o 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 este esquema sozinho, mas a ideia principal de mesclar nós um tanto ortogonais para ser parcimoniosa com vCpu & ram pode lhe dar tração suficiente para chegar onde você quer ir .

p.s. Veja também, helpdocs semi-oficiais para o OpenStack em um nó físico com um VM, mais o OpenStack mais relevante em um tutorial de caixa dedicado, em devstack.org