Arquitectura de un despliegue virtual OpenStack (Juju/MAAS) con 1 nodo físico

Question

Me gustaría demostrar algunas de las características de OpenStacks HA/FT (lo más importante es la migración en vivo y la replicación de almacenamiento). Para ello tengo una máquina con 32 GB de RAM y un Xeon e3v2 de 4 núcleos (8 subprocesos). Hasta ahora he logrado poner en funcionamiento MAAS y Juju, pero no estoy seguro de la cantidad de nodos virtuales que puedo implementar de manera segura (y la relación de sobrecompromiso de CPU/RAM, aunque leí en alguna parte que la CPU física puede manejar bastante bien el compromiso excesivo con máquinas de 1 vcpu).

Actualmente, la VM que ejecuta MAAS usa 1 vCPU y 8 GB de RAM, Juju se ejecuta en el host. Eso me deja con 7 vCPU y 24 GB de RAM sin comprometer demasiado ningún recurso. Lo que se me ocurrió es lo siguiente:

• 1 nodo controlador: 2vCPU, 4 GB de RAM: RabbitMQ, mysql, keystone, tablero, cinder, nova-cloud-controller y vistazo en contenedores lxc
• 2 nodos Ceph: 1 vCPU, 4 GB de RAM cada uno - ceph
• 2 nodos de cómputo: 2 vCPU, 8 GB de RAM cada uno - nova-compute
• 1 nodo de red: 1 vCPU, 2 GB de RAM - puerta de enlace cuántica
• Más el host MAAS: 1 vCPU, 8 GB de RAM

Esto daría como resultado un total de 38 GB de RAM y 10 vCPU, por lo que me estoy comprometiendo un poco en exceso.

Mi pregunta real es si alguien tiene una mejor arquitectura en mente. Realmente solo planeo mostrar algunas características de OpenStack (o de las nubes en general).

Answer 1

Tengo una configuración similar y déjame sugerirte tu configuración:

• Reduzca la cantidad de RAM asignada a MAAS, alrededor de 2 GB serán suficientes.
• Agregue otro nodo ceph, esto le ayudará a demostrar resiliencia cuando use ceph y 1 nodo se caiga.
• El exceso de compromiso en la CPU no es tan malo, pero no conviene comprometerse demasiado en la memoria, porque el sistema comenzará a intercambiar y todo obtendrá un rendimiento inutilizable.
• Algo que no mencionas son los discos que tienes, esto es un gran cuello de botella para mí, tengo 2 discos de 7200 RPM con btrfs (raid0), pero no es suficiente mientras se implementa el juju.
• También es posible que desee utilizar juju-deployer y modificar la línea de comando que utiliza para implementar, específicamente los modificadores de tiempo de espera y '-s', que es un retraso entre cada llamada de "implementación de juju".

Espero que esto ayude.

Felipe,

Answer 2

Le sugiero que lo descarte si aún se está ejecutando y use LXD. No deberías tener problemasimplementando estosin MaaS y simplemente ejecutando Juju con control local de su LXD localcomo se describe aquí. Su máquina debería poder funcionar sin sudar demasiado. Si necesita MaaS para demostrarlo (realmente es bastante impresionante. Debería intentar ver los Openstack Roadshows que hace Canonical si alguno se acerca...) entonces se vuelve un poco más complicado.

Esta referencia demuestraconfigurarlo en 3 máquinas, pero puedes ser astuto e implementar Juju y MaaS en la misma otra máquina si realmente lo necesitas. Si su segunda máquina estaba ejecutando MaaS y JuJu bajo LXD con el puente conectado a la LAN de su laboratorio y su tráfico PXE podía pasar, debería poder ejecutarlo todo en contenedores en dos máquinas. Estoy intentando hacer algo similar con las máquinas virtuales VMWare Fusion en mi computadora portátil, donde he conectado la red interna a una NIC Thunderbolt para permitir que las máquinas MaaS y Juju orquesten dispositivos Raspberry Pi y NUC.

Answer 3

No tengo experiencia en el uso de juju para la orquestación de openstack, pero según mi experiencia con ceph y openstack, para fines de demostración, puede ejecutar ceph en máquinas de 2 GB sin problemas y creo que el host maas también se puede configurar con 6 GB en lugar de 8.

No sé si juju te permite combinar diferentes roles en la misma VM, en nuestras implementaciones (no juju) combinamos el controlador y los roles de red en la misma VM (sin usar contenedores).

Answer 4

Cuando se utilizan nodos físicos en un clúster pequeño, especialmente elementos de laboratorio de pruebas, un atajo típico es combinar los nodos ceph con los nodos de cómputo. Vea este conjunto de imágenes de la era ceph-0.48instrucciones para debian, o este mas modernoconfiguración de laboratorio para proxmox VE.

Usando los números que proporcionó y las sugerencias para disminuciones de RAM más triple ceph en las otras respuestas, tal vez algo como esto:

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

Actualmente estoy trabajando en una configuración de un nodo de esta naturaleza, pero tengo menos RAM disponible y solo cuatro discos para dedicar (cephOsd es mejor con varios discos). No puedo confirmar que los números anteriores funcionen para usted con un rendimiento adecuado, ya que no he probado este esquema yo mismo, pero la idea central de fusionar nodos algo ortogonales para ser parsimonioso con vCpu y ram puede brindarle suficiente tracción para llegar a donde desea ir.

ps Consulte también documentos de ayuda semioficiales para OpenStack en un nodo físico conunoVM, además del OpenStack más relevante en un tutorial de cuadro dedicado, en devstack.org