Instalación de servicios OpenStack

OpenStack Kolla

A traves de los artículos anteriores realizamos la creación un repositorio para el almacenamiento de las imágenes Docker utilizadas por los servicios de OpenStack para así mas tarde configurar las herramientas y los nodos que almacenaran dichos servicios. Es por ello que solo resta realizar el último paso que es el proceso de Instalación de servicios de OpenStack. Este proceso consta de las siguientes etapas:

  1. bootstrap-servers: Inicializa los nodos destino con la instalación de dependencias necesarias por el proceso de Instalación de servicios de OpenStack. Entre las tareas que este proceso realiza se encuentra:
    • La configuración del archivo /etc/hosts.
    • Asegura que los grupos sudo y kolla existan en cada uno de los nodos.
    • La instalación de dependencias, certificados y claves GPG
    • Configuración del cortafuegos.
    • Instalación y configuración del servicio de Docker.
    • Sincronización los relojes.
  2. prechecks: Realiza una validación de requerimientos necesarios por el proceso de Instalación. Donde principalmente se valida que los puertos a ser usados por los servicios habilitados se encuentren disponibles.
  3. pull: Descarga de las imágenes de los servicios de OpenStack basándose en los roles que fueron definidos para cada nodo.
  4. deploy: Despliegue de servicios. Durante este proceso se realiza las siguientes tareas para cada servicio:
    • Creación de base de datos y tablas.
    • Creación y registro de usuarios.
    • Configuración de políticas de acceso.
  5. check: Realiza una validación a traves de tareas de sanity checks donde se determina el correcto funcionamiento de algunos servicios.
  6. post-deploy: Genera el archivo openrc para el usuario admin.

Estas etapas son traducidas en argumentos utilizados por la herramienta de kolla-ansible(la cual hemos instalado y configurado previamente). De manera que nuestro proceso puede ser realizado en una iteración de los distintos argumentos mediante ciclo.

for action in bootstrap-servers prechecks pull deploy check post-deploy; do
    sudo kolla-ansible -vvv -i $inventory_file $action -e 'ansible_user=kolla' -e 'ansible_become=true' -e 'ansible_become_method=sudo' | tee $action.log
done

Nota adicional: El repositorio de GitHub ha sido actualizado para incorporar las instrucciones necesarias para realizar un Instalación de servicios OpenStack para el release de Stein.

Configuración previa a la Instalación de OpenStack

En el articulo anterior creamos un servidor el cual administra las imágenes Docker que son utilizadas durante el proceso de instalación de OpenStack. A lo largo de este articulo sera explicado el proceso de configuración previa a la instalación de OpenStack.

Soluciones de Infraestructura como Servicio como lo es OpenStack, buscan maximizar el uso de los recursos del centro de datos, por lo cual se recomienda habilitar varios módulos del kernel que nos ayuden a mejorar el desempeño en cada uno de los equipos.

La virtualización anidada es la capacidad que permite a los usuarios la creación de máquinas virtuales dentro de una máquina virtual. El proceso de habilitación de esta capacidad depende de la arquitectura del procesador que se este utilizado, el comando lscpu nos proporciona la información acerca del CPU.

$ lscpu 
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                88
On-line CPU(s) list:   0-87
Thread(s) per core:    2
Core(s) per socket:    22
Socket(s):             2
NUMA node(s):          1
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 79
Model name:            Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz
Stepping:              1
CPU MHz:               1578.328
CPU max MHz:           3600.0000
CPU min MHz:           1200.0000
BogoMIPS:              4391.44
Virtualization:        VT-x
L1d cache:             32K
L1i cache:             32K
L2 cache:              256K
L3 cache:              56320K
NUMA node0 CPU(s):     0-87
Flags:                 fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch epb invpcid_single intel_pt ssbd ibrs ibpb stibp kaiser tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm cqm rdseed adx smap xsaveopt cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local dtherm ida arat pln pts flush_l1d

En este caso la arquitectura del procesador del servidor utilizado es x86, por lo que las instrucciones para habilitar son:

$ rmmod kvm-intel
$ echo 'options kvm-intel nested=y' >> /etc/modprobe.d/dist.conf
$ modprobe kvm-intel

Otro modulo del kernel que nos mejora el desempeño es vhost_net. De acuerdo a este articulo de RedHat, este modulo ayuda a reducir las operaciones de escritura, latencia y uso de CPU y se habilita a traves de la instrucción:

$ modprobe vhost_net

vhost_net

En este punto nuestros servidores o nodos destino han sido configurados para obtener un mejor desempeño. Ahora es momento de proceder con la instalación de la herramienta Kolla-Ansible y sus respectivas dependencias.

Todas instrucciones que se mostrarán a continuación pueden ser ejecutadas desde cualquier máquina que tenga conectividad a los nodos destino. En nuestro diagrama de ejemplo el servidor con nombre de undercloud mantiene conexión con el resto de nodos destino a traves de la red de administración con CIDR de «192.168.121.0/27».

Diagrama de ejemplo

Esta máquina utilizará kolla-ansible para realizar la Instalación de OpenStack. Este programa puede ser instalado de distintas formas, sin embargo en este caso sera instalado desde su código fuente.

$ wget http://tarballs.openstack.org/kolla-ansible/kolla-ansible-stable-rocky.tar.gz
$ tar -C /opt -xzf kolla-ansible-stable-rocky.tar.gz
$ mv /opt/kolla-*/ /opt/kolla-ansible
$ sudo cp /opt/kolla-ansible/etc/kolla/passwords.yml /etc/kolla/
$ pip install /opt/kolla-ansible

Como ultimo paso previo a la instalación de OpenStack, se necesita un archivo de configuración el cual especifique los detalles de la instalación (versión de OpenStack a instalar, dirección IP del VIP, dirección IP del repositorio de imágenes, habilitación de servicios, etc.). Estos son algunos de los valores utilizados en el archivo globals.yml:

openstack_release: "7.0.0"
kolla_internal_vip_address: "10.10.13.3"
docker_registry: "10.10.13.2:5000"
network_interface: "eth0"
kolla_external_vip_interface: "eth1"
api_interface: "{{ kolla_external_vip_interface }}"
storage_interface: "eth2"
cluster_interface: "eth2"
tunnel_interface: "eth1"
neutron_external_interface: "eth2"
neutron_plugin_agent: "opendaylight"

En este punto se cuenta con la configuración previa a la instalación de servicios de OpenStack. El siguiente articulo proporcionará los pasos necesarios para realizar el despliegue de los servicios de OpenStack en una configuración de Alta Disponibilidad.

Nota: El script undercloud.sh contiene las instrucciones mencionadas en este articulo

Creación de Imágenes de OpenStack usando Kolla

En el articulo anterior detallaba el proceso para la creación de imágenes de OpenStack en un repositorio Docker privado a traves del proyecto de Kolla. Dichas imágenes serán utilizadas mas parte por las tareas del proyecto de kolla-ansible durante el despliegue de servicios de OpenStack en una configuración que ofrezca Alta Disponibilidad.

Para esta serie de artículos fue necesario crear un repositorio el cual pudiera almacenar las instrucciones. La validación de este proyecto se realiza a traves de la tecnología de vagrant la cual nos permite provisionar automáticamente Máquinas Virtuales.

Con el fin de agregar mas nodos con fines mas especializados fue necesario modificar la arquitectura inicial, dando como resultado tenemos el siguiente diagrama:

Diagrama de la arquitectura de nodos

El servidor llamado «registry» realizara la creación de imágenes. Este cambio ofrece un mejor control y administración de las imágenes de OpenStack utilizadas durante el proceso de provisionamiento. Para la creación de este servidor es necesario instalar las dependencias del proyecto, para ello necesitaremos el manejador de paquetes de python(pip) y el código fuente del proyecto.

apt remove -y python-pip
apt-get install -y python-dev
curl -sL https://bootstrap.pypa.io/get-pip.py | sudo python

wget http://tarballs.openstack.org/kolla/kolla-stable-rocky.tar.gz
tar -C /opt -xzf kolla-stable-rocky.tar.gz
mv /opt/kolla-*/ /opt/kolla
pip install /opt/kolla

Una vez instalado los módulos de python, es necesario instalar e iniciar el servicio de Docker. La comunidad de Kolla utiliza el directorio de tools para los procesos Jenkins durante la validación de cambios propuestos en el código fuente, el script setup_Debian.sh nos permite instalar el servicio de Docker y el script start-registry crea un repositorio Docker privado a traves de un contenedor.

pushd /opt/kolla/tools/
./setup_Debian.sh
./start-registry
popd

Por ultimo procederemos a la creación de imágenes de OpenStack Kolla, el comando kolla-build utiliza el archivo de configuración kolla-build.ini, en este archivo es necesario especificar la IP del servidor de registry el cual almacenará las imágenes de OpenStack y también habilitaremos la publicación automática de las imágenes creadas con del valor de configuración «push».

push = true
registry = 10.10.13.2:5000

Una vez todo configurado podemos comenzar con el proceso de creación de imágenes con la ejecución del siguiente comando:

kolla-build --config-file /etc/kolla/kolla-build.ini

Instalación de OpenStack – Alta Disponibilidad (Creación de imágenes)

Últimamente he estado trabajando en la integración de Kolla como una alternativa adicional para la instalación de los servicios de OpenStack en el proyecto de XCI en OPNFV. Kolla ofrece el despliegue de servicios de OpenStack en contenedores Docker en lugar de contenedores Linux como lo hace OpenStack-Ansible. Este proyecto fue creado con el fin de simplificar el numero de variables utilizadas en el proceso de configuración.

Esta serie de artículos pretende recopilar los requisitos e instrucciones necesarias para la instalación de los servicios de OpenStack en una configuración de Alta Disponibilidad, es decir, tres nodos con roles de controlador y dos nodos con roles de computo, además un nodo adicional como medio para la ejecución de instrucciones.

Cabe mencionar que OpenStack Kolla puede ser visto como dos proyectos independientes, uno el cual controla el proceso de creación de imágenes de Docker y otro el que utiliza estas imágenes para realizar el despliegue de los servicios de OpenStack. Aunque es posible utilizar las imágenes de Docker provistas por la comunidad para el despliegue de los servicios de OpenStack, en esta ocasión las imágenes serán generadas a partir de repositorios remotos de los distintos proyectos de OpenStack.

Lo primero a realizar es la instalación de dependencias (Docker y modulos de Python) en el nodo llamado OPNFV, el cual mantendrá el catalogo de imágenes utilizadas por el resto de los nodos. La documentación oficial proporciona los siguientes pasos.

Instalación de Docker

$ sudo apt install -y software-properties-common linux-image-extra-$(uname -r) linux-image-extra-virtual
$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
$ sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"
$ sudo apt update
$ sudo apt install -y docker-ce

Instalación de OpenStack Kolla desde codigo fuente

$ sudo apt install -y python2.7 python-dev build-essential
$ curl -sL https://bootstrap.pypa.io/get-pip.py | sudo python
$ git clone https://github.com/openstack/kolla
$ cd kolla
$ sudo pip install .

Es posible generar una plantilla que facilite la configuración del proceso de creación de imágenes. Esta plantilla puede ser obtenida a traves de la ejecución de la herramienta tox utilizando el argumento de genconfig como valor de entorno.

Generacion de etc/kolla/kolla-build.conf

$ sudo pip install tox 
$ tox -e genconfig

En esta plantilla podemos especificar la ubicación del código fuente que sera utilizado por las imagenes. Por ejemplo, si se desea que la imagen para los servicios de Neutron sea generada a partir el código fuente del repositorio del día 28 de mayo del 2018. Solo es necesario localizar la sección [neutron-base] y modificar los siguientes valores de type, location y reference en el archivo kolla-build.conf.

[neutron-base]
type = git
location = https://git.openstack.org/openstack/neutron
reference = f723dfadeecc6f13cd3a1277dc13e1580a4ea5d0

Por ultimo solo queda iniciar el proceso de creación de imágenes, este se realiza por medio de el binario kolla-build que fue generado al momento de instalar Kolla.

kolla-build --config-file etc/kolla/kolla-build.conf

* Nota adicional: Las instrucciones previamente mencionadas han sido guardadas en el repositorio vagrant-kolla.

Revertir instalación de paquetes

No todas las actualizaciones en el sistema operativo pueden ser benéficas, en ocasiones es posible que la actualización de algún paquete cause conflictos en nuestras aplicaciones. Para estos casos es necesario revertir la actualización de paquetes.

A lo largo de este articulo explicaré los pasos necesarios para revertir instalación de paquetes de Docker para la distribución de Ubuntu.

Lo primero a realizar es obtener el nombre exacto del paquete a revertir su actualización. Es posible filtrar este nombre, a traves del comando find, del contenido de archivos del directorio /var/lib/dpkg/info/. Este directorio contiene archivos de la configuración de los paquetes instalados. El siguiente comando busca una coincidencia en las actualizaciones realizadas en las ultimas 24 horas.

$ find /var/lib/dpkg/info/ -name \*.list -mtime -1 | sed 's#.list$##;s#.*/##' | grep docker
docker-ce

Una vez que el nombre es encontrado es necesario recurrir a la tabla de versiones para conocer las versiones disponibles. Esta tabla puede ser mostrada a traves con el comando apt-cache policy.

$ sudo apt-cache policy docker-ce
docker-ce:
  Installed: 17.12.1~ce-0~ubuntu
  Candidate: 17.12.1~ce-0~ubuntu
  Version table:
 *** 17.12.1~ce-0~ubuntu 0
        500 https://download.docker.com/linux/ubuntu/ trusty/stable amd64 Packages
        100 /var/lib/dpkg/status
     17.12.0~ce-0~ubuntu 0
        500 https://download.docker.com/linux/ubuntu/ trusty/stable amd64 Packages
     17.09.1~ce-0~ubuntu 0
        500 https://download.docker.com/linux/ubuntu/ trusty/stable amd64 Packages
     17.09.0~ce-0~ubuntu 0
        500 https://download.docker.com/linux/ubuntu/ trusty/stable amd64 Packages
     17.06.2~ce-0~ubuntu 0
        500 https://download.docker.com/linux/ubuntu/ trusty/stable amd64 Packages
     17.06.1~ce-0~ubuntu 0
        500 https://download.docker.com/linux/ubuntu/ trusty/stable amd64 Packages
     17.06.0~ce-0~ubuntu 0
        500 https://download.docker.com/linux/ubuntu/ trusty/stable amd64 Packages
     17.03.2~ce-0~ubuntu-trusty 0
        500 https://download.docker.com/linux/ubuntu/ trusty/stable amd64 Packages
     17.03.1~ce-0~ubuntu-trusty 0
        500 https://download.docker.com/linux/ubuntu/ trusty/stable amd64 Packages
     17.03.0~ce-0~ubuntu-trusty 0
        500 https://download.docker.com/linux/ubuntu/ trusty/stable amd64 Packages

En este caso la versión instalada en el sistema operativo es la señalada con tres asteriscos al inicio del nombre, es decir, la versión 17.12.1~ce-0~ubuntu. Esta tabla también nos permite conocer las versiones disponibles de nuestro paquete.

Por ultimo y para por fin revertir instalación de paquetes solo queda forzar la instalación del paquete a la versión deseada.

$ sudo apt-get install docker-ce=17.09.1~ce-0~ubuntu --force-yes -y
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following packages will be DOWNGRADED:
  docker-ce
0 upgraded, 0 newly installed, 1 downgraded, 0 to remove and 0 not upgraded.
Need to get 21.0 MB of archives.
After this operation, 52.6 MB disk space will be freed.
Fetched 21.0 MB in 7s (2,693 kB/s)
dpkg: warning: downgrading docker-ce from 17.12.1~ce-0~ubuntu to 17.09.1~ce-0~ubuntu
(Reading database ... 69403 files and directories currently installed.)
Preparing to unpack .../docker-ce_17.09.1~ce-0~ubuntu_amd64.deb ...
docker stop/waiting
Unpacking docker-ce (17.09.1~ce-0~ubuntu) over (17.12.1~ce-0~ubuntu) ...
Processing triggers for ureadahead (0.100.0-16) ...
Processing triggers for man-db (2.6.7.1-1ubuntu1) ...
Setting up docker-ce (17.09.1~ce-0~ubuntu) ...
Installing new version of config file /etc/bash_completion.d/docker ...
docker start/running, process 7219

«Hola mundo» desde Jenkins

Jenkins es un proyecto de código abierto que permite la automatización de tareas para el proceso de desarrollo de software, es decir, es una de las herramienta que nos permite la implementación de la metodología de Integración Continua. Las tareas que puede manejar van desde la verificación de los estándares de codificación hasta la generación y despliegue de nuevos binarios. «Hola mundo» desde Jenkins es un articulo que pretende cubrir aquellos pasos necesarios para la adición y ejecución de tareas a un servidor de Jenkins.

Lo primero a realizar es la instalación de sus dependencias, y dado que es un proyecto escrito en Java este requiere la máquina virtual provista por el Java Runtime Environment (JRE).

# apt-get install -y software-properties-common
# add-apt-repository -y ppa:openjdk-r/ppa
# apt-get update
# apt-get install -y openjdk-8-jre

Una vez instalada la máquina virtual procedemos a la instalación del binario de Jenkins. En su sitio oficial se menciona una serie de posibles alternativas para su instalación. En esta ocasión utilizaremos la instalación propuesta para servidores Ubuntu.

# wget -q -O - https://pkg.jenkins.io/debian/jenkins.io.key | sudo apt-key add -
# sh -c 'echo deb http://pkg.jenkins.io/debian-stable binary/ > /etc/apt/sources.list.d/jenkins.list'
# apt-get update
# apt-get install -y jenkins
# echo "2.89.2" > /var/lib/jenkins/jenkins.install.InstallUtil.lastExecVersion
# export MY_JENKINS_API_TOKEN=secret
# service jenkins restart

El servicio de Jenkins es iniciado por el archivo /etc/init.d/jenkins en el puerto 8080 y un servidor web, cómo Apache o Nginx, puede ser antepuesto para realizar un mejor manejo de las peticiones de los usuarios.

Teniendo el servicio instalado ya solo sera cuestión de agregar las tareas necesarias para nuestro proyecto. Para esto nos ayudaremos de un proyecto creado por el equipo de OpenStack Infra llamado «Jenkins Job Builder» el cual nos permite la generación de tareas de Jenkins en formato XML a partir de un archivo con formato YAML.

# curl -sL https://bootstrap.pypa.io/get-pip.py | python
# pip install jenkins-job-builder
# mkdir -p /etc/jenkins_jobs/
# cat << /etc/jenkins_jobs/jenkins_jobs.ini
[jenkins]
user=admin
password=${MY_JENKINS_API_TOKEN}
url=http://localhost:8080
EOL

En la carpeta de tests del proyecto existen varios ejemplos de como crear una plantilla en formato YAML. Nuestro ejemplo sera algo sencillo, la ejecución de una instrucción en consola.

HolaMundo.yaml

- job:
    name: Hola-mundo
    description: 'Pantilla utilizada para la impresion de Hola mundo desde la consola'
    builders:
      - shell: |
          #!/bin/bash
          echo 'Hola Mundo!'

Por ultimo queda agregar la tarea en el servidor local de Jenkins. Para ello utilizaremos el binario instalado por el proyecto jenkins-job-builder con el comando update y el nombre de la plantilla creada.

$ jenkins-jobs update HolaMundo.yaml

Si deseamos la ejecución de dicha tarea lo podemos realizar seleccionando manualmente la opción Build Now desde el menú desplegable de la tarea deseada.

Utilizar Python 2 y 3 en la misma máquina

Utilizar las versiones de python 2 y 3 en el mismo equipo en ocasiones puede ser algo muy conveniente. Como ejemplo de ello esta el proyecto de Cross Community CI (XCI) de OPNFV hace uso, entre muchas cosas, del proyecto de OpenStack Bifrost para la creación de una imagen base y provisionamiento de sistema operativo. Este proyecto de Bifrost utiliza el cliente de Ansible en su versión estable 2.1.

Ahora bien, el equipo que utilizo para realizar pruebas y desarrollo tiene instalado ambas versiones de Python y durante la ejecución del cliente de Ansible en su versión 2.1.6 obtengo varios errores. Estos errores son causados por el uso del método unicode que solo se encuentra disponible en versiones 2.x de Python.

Como alternativa para solucionar este problema (sin actualizar o modificar el código fuente del cliente) es forzando al Sistema Operativo a utilizar una versión especifica de Python. La herramienta de pyenv nos permite instalar y trabajar con varias versiones de Python en la misma computadora y su instalación varia de acuerdo al Sistema Operativo utilizado.

En el caso de Sistemas Operativos con Linux su instalación puede realizarse con la siguiente instrucción en la linea de comandos:

$ curl -L https://raw.githubusercontent.com/yyuu/pyenv-installer/master/bin/pyenv-installer | bash

Para los equipos MacOS, es posible a través del manejador de paquetes brew.

$ brew install pyenv

Esta aplicación utiliza una carpeta para almacenar los binarios de las distintas versiones de Python y los archivos de configuración de los valores del usuario. Como parte de la instalación es necesario declarar la variable de ambiente PYENV_ROOT que especificará la carpeta a ser utilizada. Se recomienda agregar la declaración de esta variable en el PATH para realizarse al momento de cargar la sesión de la consola.

Bash:

$ echo 'export PYENV_ROOT="$HOME/.pyenv"' >> ~/.bashrc
$ echo 'export PATH="$PYENV_ROOT/bin:$PATH"' >> ~/.bashrc
$ echo 'eval "$(pyenv init -)"' >> ~/.bashrc

Fish:

$ echo "pyenv init - | source" >> ~/.config/fish/config.fish 

Eso nos permite que al iniciar sesión desde cualquier terminal, los valores de configuración sean automáticamente cargados. Las siguientes instrucciones son para la instalación de versiones 2.7.14 y 3.5.4 de Python.

$ pyenv install 2.7.14
Downloading Python-2.7.14.tar.xz...
-> https://www.python.org/ftp/python/2.7.14/Python-2.7.14.tar.xz
Installing Python-2.7.14...
Installed Python-2.7.14 to /Users/vjmorale/.pyenv/versions/2.7.14
$ pyenv install 3.5.4
Downloading Python-3.5.4.tar.xz...
-> https://www.python.org/ftp/python/3.5.4/Python-3.5.4.tar.xz
Installing Python-3.5.4...
Installed Python-3.5.4 to /Users/vjmorale/.pyenv/versions/3.5.4

Por ultimo queda definir la versión activa a lo largo del sistema. Esto se logra por medio del siguiente comando:

$ pyenv global 3.5.4

Nota:
Aunque en mi caso particular pyenv no soluciono mi problema, es posible tener un resultado similar en sistemas Debian a traves del uso update-alternatives.

# update-alternatives --install /usr/bin/python python /usr/bin/python2.7 1
update-alternatives: using /usr/bin/python2.7 to provide /usr/bin/python (python) in auto mode
# update-alternatives --install /usr/bin/python python /usr/bin/python3.4 2
update-alternatives: using /usr/bin/python3.4 to provide /usr/bin/python (python) in auto mode
# update-alternatives --config python

Instalación de OPNFV a través de Compass4NFV

El proyecto de Open Platform for Network Function Virtualization (OPNFV) fue iniciado en Septiembre del 2014 como resultado del trabajo de European Telecommunications Standards Institute (ETSI) Industry Specification Group NFV (ETSI ISG NFV). Su comunidad selecciona proyectos de código abierto relevantes al área de redes y se dedica a integrarlos y probar su funcionalidad y desempeño para crear una plataforma de referencia de NFV y así acelerar la transformación de las empresas y proveedores de servicios de redes.

OPNFV utiliza OpenStack como Virtual Infrastructure Management (VIM), soporta múltiples controladores de SDN(OpenDaylight, ONOS y OpenContrail) y contiene tecnológicas de aceleración de paquetes como lo esData Plane Development Kit (DPDK). Para construir esta plataforma utiliza una metodología de integración continua y automatización de pruebas de los casos de uso de NFV claves para asegurar que se cumplan las necesidades de la industria NFV.

OPNFV libera cada seis meses una versión estable de su plataforma y tiene una nomenclatura basada en nombres de rios famosos (Arno – Jun’15, Brahmaputra – Mar’16, Colorado – Sept’16, Danube – Abr’17 y Euphrates). Además de contar con cuatro herramientas para su instalación como lo son:

  1. Compass
  2. Fuel
  3. TripleO
  4. Juju

Este articulo se centra en el análisis y uso de la primera herramienta compass4nfv.

En junio del 2017, durante la cumbre de OPNVF celebrada en Pekín, China se definieron varios puntos a mejorar para el release Euphrates. Una de las propuestas es agregar Kubernetes como componente de provisionamiento en la arquitectura.

Como consecuencia se han creado varios scripts que permiten un despliegue rápido y sencillo. Estos scripts ejecutan internamente dos scripts(build.sh y deploy.sh) para la construcción y despliegue de los distintos componentes, además de declarar variables de ambiente que definen el Sistema Operativo(OS_VERSION), la plataforma de cloud(KUBERNETES_VERSION o OPENSTACK_VERSION) y rutas de archivos de configuración. Estos archivos de configuración son dos:

  1. El archivo DHA utilizado para definir el escenario a desplegar, es decir las características a utilizar y los roles de cada servidor.
  2. El archivo de red que define los rangos de red para los servidores y

Al final el despliegue de un ambiente básico queda resumido en la ejecución del siguiente comando.

$ curl https://git.opnfv.org/compass4nfv/plain/quickstart.sh | bash

Ejecutar Ubuntu en Windows 10

En mi búsqueda por ejecutar git de una forma algo mas nativa encontré con esta solución que supongo utiliza un contenedor de Ubuntu. Esta característica solo se encuentra disponibles en versiones Windows 10 con build 4332+. Dado que se requieren cambios que aun se encuentran en fase beta, sugiero la creación de un punto de restauración.

El primer paso a realizar es activar el Modo de Desarrollador en Windows, para encontrar dicha opción de manera mas rapida podemos utilizar el cuadro de búsqueda.  Mas tarde, y  después de varias pantallas de confirmación reiniciaremos nuestra computadora.

Por ultimo no queda mas que abrir una consola de PowerShell en modo administrador y ejecutar el siguiente comando el cual habilitara la característica que estamos buscando.


PS C:\Windows\system32> Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux

Una vez que la computadora haya reiniciado podemos utilizar bash como cualquier otra aplicación instalada en nuestro sistema, solo es necesario confirmar y esperar la descarga de la aplicación.

Por ultimo es necesario realizar la instalación de la distribucion de Linux a utilizar. Este paso se realiza a traves de la compra de components del  Microsoft Store.

Laboratorio virtual de SDN

Es necesario poner el practica los conceptos aprendidos en la publicación anterior y realizar alguna prueba de concepto. Para ello he creado un proyecto en Vagrant el cual instala y configura un laboratorio de Software-Defined Network (SDN). A lo largo de esta publicación explicare los pasos del proceso de instalación para las distintas herramientas utilizadas y el como ejecutar una serie de ejercicios a modo de ejemplo.

El primer conjunto de instrucciones hace referencia a la instalación de Mininet. Esta aplicación nos permite emular una red virtual mediante la creación y conexión de hosts y switches. Existen tres maneras de obtener Mininet:

  1. Descargando una máquina virtual que previamente fue configurada desde su catalogo oficial.
  2. Mediante la instalación desde paquetes binarios (Ubuntu Trusty). Esto se logra mediante la ejecución del siguiente comando:
  3. # apt-get install -y mininet
    
    
  4. Por ultimo, mediante la instalación desde el código fuente. Este es el proceso utilizado en nuestro laboratorio, y se realiza con los siguientes comandos:
  5. 
    # apt-get install -y git
    # git clone https://github.com/mininet/mininet
    # bash mininet/util/install.sh
    
    

Una vez que tenemos instalado Mininet, el cual necesitaremos para la emulación de nuestra infraestructura, pasaremos a la instalación de un controlador. En este caso utilizaremos OpenDayLight (ODL), el cual ofrece una plataforma funcional de SDN. Distintas versiones de OpenDayLight son ofrecidas desde su repositorio oficial, por lo tanto solo es necesario realizar dos acciones:

  1. Instalar la maquina virtual de java
    
    # apt-get update -y
    # apt-get install -y software-properties-common
    # add-apt-repository -y ppa:openjdk-r/ppa
    # apt-get update -y
    # apt-get install -y openjdk-8-jdk
    
    
  2. Descargar, descomprimir e inicar la version de OpenDayLight deseada
    
    $ odl_release=0.6.0-Carbon
    $ odl_distribution=distribution-karaf
    $ wget https://nexus.opendaylight.org/content/groups/public/org/opendaylight/integration/$odl_distribution/$odl_release/$odl_distribution-$odl_release.tar.gz
    $ tar xf $odl_distribution-$odl_release.tar.gz
    $ cd $odl_distribution-$odl_release
    $ export JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64/jre
    $ ./bin/start
    
    

Una vez iniciado el servicio de karaf, necesitaremos agregar mas funcionalidades que nos ayudaran a visualizar y conectar nuestro infraestructura virtual. Esto se logra a traves de la instalación de features desde el servicio.


./bin/client feature:install odl-dlux-core odl-dluxapps-topology odl-restconf odl-l2switch-switch

Dado que Mininet fue escrito en python es posible crear una aplicación que nos genere una infraestructura virtual dinámicamente, el siguiente ejemplo muestra como utilizar clases y modulos para generar una infraestructura virtual con Mininet.

from mininet.topo import Topo

class MyTopo( Topo ):
    "Simple topology example."

    def __init__( self ):
        "Create custom topo."

        # Initialize topology
        Topo.__init__( self )

        # Add hosts and switches
        leftHost = self.addHost( 'h1' )
        rightHost = self.addHost( 'h2' )
        leftSwitch = self.addSwitch( 's3' )
        rightSwitch = self.addSwitch( 's4' )

        # Add links
        self.addLink( leftHost, leftSwitch )
        self.addLink( leftSwitch, rightSwitch )
        self.addLink( rightSwitch, rightHost )


topos = { 'mytopo': ( lambda: MyTopo() ) }"

Por ultimo es necesario especificar la URL de la API del Controlador(OpenDayLight), en nuestro ejemplo este servicio se encuentra instalado en la misma máquina por lo que se utilizara la dirección del localhost. Los siguientes dos comandos nos permitirán capturar información necesaria para mostrar los componentes, el primero es para generar y conectar la infraestructura virtual con el controlador y el segundo solo que generará trafico.

# mn --custom ~/topologies/example01.py --topo mytopo --controller=remote,ip=127.0.0.1,port=6633
*** Creating network
*** Adding controller
*** Adding hosts:
h1 h2
*** Adding switches:
s3 s4
*** Adding links:
(h1, s3) (s3, s4) (s4, h2)
*** Configuring hosts
h1 h2
*** Starting controller
c0
*** Starting 2 switches
s3 s4 ...
*** Starting CLI:
mininet> pingall
*** Ping: testing ping reachability
h1 -> h2
h2 -> h1
*** Results: 0% dropped (2/2 received)

Uno de los features instalados (DLUX para ser mas precisos) en el Controlador nos permite acceder mediante un portal a ODL. Escribiendo la URL http://10.0.0.2:8181/index.html en cualquier navegador de internet y especificando las credenciales del usuario «admin» con la contraseña «admin«.