Instalación de OpenStack Pike sobre LXC con Ansible

0. Introducción

En esta entrada se detallan los pasos, a seguir para instalar OpenStack en multi-nodo con OpenStack Ansible con LXC. Aclarar que la instalación serviría para un entorno de producción pero mejorando configuraciones que influyen directamente en la seguridad y el rendimiento.

A fecha de hoy la versión de OpenStack-Ansible Queens se encuentra en “Release Candidate” para el 16 de Marzo de 2018  y la última versión estable disponible es Pike. Más info.

 

1. Esquema

En este escenario vamos a definir 3 nodos:

NODOS
  • Infra: Nodo infraestructura
  • Computer: Nodo de computación
  • Storage: Nodo de red/almacenamiento

Desde la página oficial de OpenStack Ansible, nos recomiendan desplegar el escenario desde uno de los nodos anteriores que se denominan “targets hosts” y a la máquina desde donde se despliega ansible “deployment host” para entornos de prueba. Si fuéramos a desplegarlo en un entorno real, lo ideal es utilizar un nodo independiente como deployment host.

En esta entrada, se utilizará el nodo Computer tanto de target host como de deployment host.

 

2. Preparar los nodos “físicos”

Después de realizar una primera instalación identifique los recursos que utilizaban cada uno de los nodos, los siguientes valores no tienen porque ser exactos, y son básicamente orientativos para un entorno de prueba:

Nodo: Infra

SO CPU Cores RAM Disco Interfaz 1 Interfaz 2
Ubuntu 16.04 – 64 Bits 4 8GB 50GB Modo NAT Modo Interna
Nodo: Computer

SO CPU Cores RAM Disco Interfaz 1 Interfaz 2
Ubuntu 16.04 – 64 Bits 4 4GB 50GB Modo NAT Modo Interna
Nodo: Storage

SO CPU Cores RAM Disco 1 Disco 2 Interfaz 1 Interfaz 2
Ubuntu 16.04 – 64 Bits 1 1GB 40GB 50GB Modo NAT Modo Interna

Para la creación de los discos de almacenamiento con kvm por ejemplo podemos crearlos de la siguiente forma:

Desde este enlace podemos descargar la imagen iso utilizada en cada una de las máquinas.

Para la creación de la red interna en kvm, he utilizado la interfaz que tuve que crear en esta entrada. Donde explico como crearla.

Estos nodos se pueden desplegar en cualquier plataforma, en este escenario personalmente he utilizado KVM para la creación de estas. En esta entrada omito el proceso de creación de las máquinas con KVM ya que no tiene mucha dificultad y hay bastante información en la red 🙂

3. Preparar el “Deployment Host”

Como comento en el apartado 1, la máquina Computer hará de deployment host también, por lo tanto necesitaremos realizar los siguientes pasos para dejar lista dicha máquina:

Actualizar la lista de paquetes y acto seguido los paquetes del sistema y kernel:

Seguidamente instalar los siguientes paquetes:

Por otro lado instalar los paquetes que son necesarios para los “target hosts”:

Añadir los siguientes módulos al fichero /etc/modulespara habilitar las interfaces VLAN y bond.

Finalmente reiniciar la máquina para activar algunos cambios y utilizar el nuevo kernel.

Nota: en mi caso paso del kernel 4.4.0-87-generic 4.4.0-116-generic.

Configuración la red

El despliegue de Ansible fallará si en la máquina donde se ejecuta no puede conectarse mediante SSH para conectarse a los contenedores.

También tendremos que configurar una red con una IP del rango de direccionamiento que le asignemos a la red br-mgmt (para reducir problemas de conectividad).

Por defecto en la receta el direccionamiento que trae es:

En el Apartado 7 se asigna una dirección IP de otro rango, y se explica con más detalles.

Clonar el repositorio y ejecutar bootstrap-ansible

El siguiente paso en esta máquina será clonar la ultima versión estable del repositorio oficial de OpenStack-Ansible en el directorio /opt/openstack-ansible:

El siguiente paso es ejecutar bootstrap ansible, para ello ejecutamos el siguiente script:

Este script entre algunas cosas, lo que nos hace es crear un par de claves para el usuario root, la instalación de algunos paquetes base según la distribución del sistema, instala algunos requirements (entre ellos ansible) con pip, crea un entorno virtual de python y descarga los roles de ansible destinandolos en el directorio /etc/ansible/.

Si por ejemplo listamos el directorio .ssh del usuario root, vemos como tenemos una nueva clave pública:

Info: esta clave pública deberá ser colocada en los ficheros authorized_keys de las otras máquinas. Como curiosidad al haber desplegado ansible desde una máquina “target” ya ha introducido en su propio fichero authorized_keys la clave pública generada, ya que ansible accederá por ssh a si misma a esta máquina.

4. Targets Hosts

En la máquina Infra y Storage, realizar los mismos pasos anteriores a excepción de algunos paquetes:

Actualizar la lista de paquetes y acto seguido los paquetes del sistema y kernel:

Instalar los paquetes necesarios:

Añadir los siguientes módulos al fichero /etc/modulespara habilitar las interfaces VLAN y bond.

Importante: todas las máquinas deben tener la fecha y hora configuradas correctamente, si no hemos seleccionado correctamente la zona horaria en la instalación del sistema, podemos añadir al fichero /etc/ntp.conf un servidor de hora.

Y no olvidar reiniciar el servicio:

Finalmente reiniciar la máquina para activar algunos cambios y utilizar el nuevo kernel.

5. Configuración Claves SSH

Al igual que era necesario SSH para conectarse a los contenedores LXC, Ansible utiliza también el servicio ssh para conectarse con el deploy host y los targets hosts.

Como comentamos anteriormente, necesitaremos copiar el contenido de la clave pública generada gracias al script bootstrap ansible en la máquina computer, a los ficheros /root/.ssh/authorized_keys de cada uno de los hosts.

Primero habilitar en la configuración del servicio ssh el acceso remoto con el usuario root en Infra y Storage, esto es una mala práctica y lo desactivaremos en el momento que hayamos pasado la clave:

/etc/ssh/sshd_config

Reiniciar servicio:

Desde computer pasaremos la clave pública de la siguiente forma, ejecutar la instrucción tanto para Infra como para Storage:

Una vez transferidas las claves, desactivar el acceso remoto por ssh con el usuario root:

/etc/ssh/sshd_config

Y reiniciar el servicio ssh.

Ahora si desde cualquiera de los clientes visualizamos el fichero authorized_keys, debería verse la clave pública de computer:

Nota: no ocurre absolutamente nada si cualquiera es capaz de visualizar tu clave pública, lo malo sería si tuvieran acceso a tu clave privada.

 

6. Configuración Almacenamiento

Si eres observador habrás visto que el nodo Storage tiene un segundo dispositivo asociado, el cual servirá para crear un dispositivo físico, del cual crearemos un grupo de volúmenes lógicos necesario para que OpenStack cree automáticamente volúmenes lógicos cuando sean solicitados por el usuario final.

Por lo tanto primero nos conectamos a dicho nodo y comprobamos la ruta al dispositivo con el comando lsblk. Normalmente si es el segundo dispositivo asociado a la máquina, estará etiquetado como /dev/sdb /dev/vdb.

En mi caso etiquetado como /dev/vdbcreo un volumen físico con dicho disco indicando la ruta:

Posteriormente crearemos un grupo de volúmenes denominado “cinder-volumes”:

 

7. Configuración de la red

La siguiente configuración lo he tomado de este ejemplo de entorno de producción de la documentación de OpenStack.

 

A continuación los ficheros de configuración de /etc/network/interfaces de cada uno de los nodos:

Info: el direccionamiento 10.0.0.0/24 me lo ha proporcionado KVM al utilizar la interfaz en modo NAT y he aprovechado dicho direccionamiento para utilizar el servidor dns y el acceso desde la máquina anfitriona.

Nodo: Infra – /etc/network/interfaces

Nodo: Computer – /etc/network/interfaces

Nodo: Storage – /etc/network/interfaces

Info: una vez añadida las configuraciones de red a los nodos, reiniciar las máquinas y comprobar que efectivamente hay conectividad entre las interfaces y vlan’s.

 

8. Configurar y desplegar el entorno

OpenStack-Ansible (OSA) depende de varios ficheros para construir un inventario para Ansible, necesitaremos realizar los siguientes pasos:

Copiar el contenido del directorio /opt/openstack-ansible/etc/openstack_deploy /etc/openstack_deploy

Nos movemos al nuevo directorio y renombramos el siguiente fichero, y le quitamos la extensión example:

En el fichero openstack_user_config.yml, se definen los nodos que corren los contenedores y por quien será desplegado cada servicio.

Por ejemplo, los hosts listados en la sección shared-infra_hosts incluyen la mayoría de los servicios que OpenStack requiere como Memcached, RabitMQ y las bases de datos.

Debemos editar tal fichero, adaptándolo a nuestro escenario, en mi caso:

/etc/openstack_deploy/openstack_user_config.yml

 

9. Configurar Credenciales

En el siguiente fichero /etc/openstack_deploy/user_secrets.yml, se definen las credenciales para cada uno de los servicios.

La opción keystone_auth_admin_password define la contraseña de admin tanto para la api de OpenStack como al acceso de horizon.

Con el siguiente script, se generan valores aleatorios para cada uno de los servicios definidos en el fichero:

Si quisiéramos regenerar contraseñas ya existente, bastaría con añadir la etiqueta –regen a la ejecución del script.

10. Playbooks

El proceso de instalación requiere de 3 playbooks principales:

  • El playbook setup-hosts.yml prepara los servicios de OpenStack y la infraestructura para los target hosts, construir contenedores y instalar componentes comunes dentro de ellos.
  • El playbook setup-infrastructure.yml instala los servicios: Memcached, el servidor repositorio, Galera, RabbitMQ y rsyslog.
  • Y el playbook setup-openstack.yml instala los siguientes servicios, keystone, glance, cinder, nova, neutron, heat y horizon.

Comprobar integridad de ficheros yml

Podemos comprobar después de haber modificado o añadido lineas a un fichero de configuración yml o playbook, si la sintaxis es correcta o lo que es lo mismo si cada una de las sangrías son correctas. Para ello debemos ubicarnos en el directorio /opt/openstack-ansible/playbooks y correr la siguiente instrucción:

Ejecutar los playbooks para instalar OpenStack

Para empezar nos posicionamos en el siguiente directorio:

Y ejecutamos el primer playbook, el denominado setup-hosts.yml:

El tiempo aproximado de la ejecución total del playbook fue de unos 12 minutos.

Ejecutamos el segundo playbook:

Tiempo aproximado: 20 minutos.

Al finalizar el segundo playbook es posible verificar si se ha creado satisfactoriamente el cluster con galera:

Playbook final:

Tiempo aproximado: 40 minutos.

 

11. Verificación

Para verificar que la instalación ha finalizado correctamente, debemos hacer lo siguiente en un nodo de infraestructura, en este escenario seria Infra.

Nota: También es posible hacer el siguiente paso desde un nodo de computación, pero ya que estamos desplegando sobre linux containers vamos a hacer uso del contenedor desplegado para ello.

Verificar la API

Existe un “contenedor de utilidad” que nos proporciona un entorno CLI para configuración adicional o de testeo.

Primero deberemos ejecutar la siguiente instrucción, para localizar el nombre exacto del contenedor:

Posteriormente nos conectamos al contenedor directamente con:

Utilizamos las credenciales de admin:

Ahora podriamos ejecutar algún comando que hiciera uso de la api, como por ejemplo:

Verificar dashboard (horizon)

Ahora con un navegador web, podemos acceder al panel web utilizando la dirección IP que definimos en la opción external_lb_vip_address en el fichero /etc/openstack_Deploy/openstack_user_config.yml.

En mi caso es: 10.0.0.69

Nota: el dashboard utiliza HTTPS en el puerto 443.

Ahora para autenticarnos con el usuario admin la contraseña es la definida en la opción keystone_auth_admin_password en el fichero /etc/openstack_deploy/user_secrets.yml.

En este caso la contraseña es la de la clave: 024b8b581a06ebed15a3fbae41c

Ahora si accedemos desde el navegador web:

El pase de diapositivas requiere JavaScript.

Verificar virtualización anidada 

Para que el usuario final sea capaz de levantar instancias (maquinas virtuales) dentro de estos nodos. Tendremos que tener habilitada la virtualización anidada en nuestra máquina anfitriona, pasandole así la posibilidad de virtualizar a las máquinas virtuales KVM.

Si, por ejemplo dentro de uno de los nodos en este caso Computer, ejecutamos la siguiente instrucción:

Nota: si al ejecutar la instrucción anterior, nos dice que no esta instalado, ejecutar: apt install libvirt-bin.

Podemos observar que nos etiqueta “FAIL” al comprobar la virtualización por hardware.

Apagamos todas las máquinas virtuales y deshabilitamos el módulo kvm-intel kvm-amd dependiendo de nuestro procesador:

Activamos la función de anidamiento:

Esta característica duraría hasta el próximo reinicio de la máquina anfitriona, si quisiéramos hacer este cambio permanente bastaría con añadir la linea en el fichero /etc/modprobe.d/kvm.conf:

  1. Ahora desde Virt-manager, hacemos doble clic en la máquina virtual y pinchamos en el icono “Mostrar detalles de hardware virtual”.
  2. Nos desplazamos a la opción CPUs en la barra lateral y en la sección de configuración, marcamos la casilla de “Copiar configuración de la CPU del anfitrión”.

Info: esto no se recomienda para un uso general, esto debería solo habilitarse cuando sea necesario, como se da al caso en este escenario.

Ahora arrancamos la máquina y si ejecutamos el comando anterior, veremos como ahora si nos devuelve PASS:

Y ya tendríamos nuestro Openstack instalado en multi nodo, si quieres saber más puedes mirar la siguiente entrada donde muestro los primeros pasos con OpenStack Ansible.

Referencias

https://docs.openstack.org/project-deploy-guide/openstack-ansible/pike/overview.html

https://docs.openstack.org/project-deploy-guide/openstack-ansible/pike/app-config-prod.html 

https://github.com/nuagenetworks/nuage-openstack-ansible/wiki/Configure-OSA-Multi-node-Environment

 

Autor entrada: CharlieJ

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *