OpenStack: toda la verdad sobre el lanzamiento "real"

Woland en M. Bulgakov dijo que "un ladrillo sin razón nunca caerá sobre la cabeza de nadie". Tal vez sí, pero cuando me preguntaron hace dos años y medio si quería conocer OpenStack, era ese ladrillo muy bien velado (y ni siquiera un ladrillo, sino una losa de granito al principio). Fue 2016 que se convirtió en el llamado "punto de no retorno" para mí, sentando las bases para el rápido desarrollo de los conceptos del mundo abierto e influyendo significativamente en la mentalidad, convirtiendo mi vida futura en vacaciones. "Vacaciones", que siempre está conmigo.

2016 - hoy

OpenStack no fue amor a primera vista. La primera versión que implementé para probar fue Kilo, que rimaba fácilmente con la palabra "triste". Habiendo existido durante exactamente tres semanas, se esperaba que fuera reemplazado por Liberty, quien, bajo una envoltura atractiva, notas de lanzamiento, no pudo cumplir con las altas expectativas. Mitaka no ha aportado nuevas funcionalidades, ya que contenía muchas correcciones y "parches", y aún así (!) Se utiliza con éxito en entornos productivos. Newton, de hecho, fue un punto de inflexión en la historia de OpenStack, proporcionando tantos cambios arquitectónicos, lógicos y, como resultado, de configuración que bloquearon para siempre la ruta de actualización de la versión anterior para muchas nubes privadas. Pero fue con el lanzamiento de Ocata en 2017, según los analistas , que comenzó la "edad de oro" de OpenStack, que incluye a Pike, Queens y, sinceramente, Rocky, que está en un comienzo bajo, entrará.


Este artículo se centrará en la última versión estable de OpenStack - Queens, en algunas innovaciones y deficiencias - desde el punto de vista de una persona que estaba automatizando su implementación basada en la distribución Ubuntu 16.04 LTS (y continúa haciéndolo porque no hay límite a la perfección) .

No hay tanto material sobre Queens en la red (si excluye de la muestra la documentación e informes oficiales de la reciente Cumbre OpenStack en Vancouver), y el número de revisiones de proveedores de nube e integradores de sistemas se puede contar con los dedos de una mano. No es sorprendente que su predecesor, Pike, cuyo soporte oficial durará otros ocho meses, con cientos de usuarios resueltos y un procedimiento de actualización bien documentado, se vea más adecuado para la implementación. Nuestro equipo, que ha seguido de cerca el proceso de desarrollo de Queens desde el principio, fue más allá que muchos y lanzó con confianza lo "nuevo" en la producción. Entonces, ¿qué tan profundo era la madriguera del conejo?

(en adelante, la terminología de OpenStack se utilizará ampliamente; se supone que el lector está al menos familiarizado con la arquitectura típica)

Características útiles

1. Para mí personalmente, una buena ventaja en la nueva versión fue la expansión de la funcionalidad de la utilidad nova-manage: ¡ahora puede eliminar hosts de algunas celdas (Celdas v2) y transferirlas a otras! Pike tuvo que escribir consultas de bases de datos separadas, y ahora está disponible "fuera de la caja".
2. La creación de un rol personalizado (_member_ por defecto) para Keystone se "recorta" de la etapa de arranque. La razón de esto fue la transición final a API v3, que tiene otras formas de mecanismos de autorización y autenticación, lo que también aumenta la seguridad de la infraestructura (después de todo, también había una identificación fija para el rol de usuario ...) Sin embargo, esto no significa en absoluto que el rol de usuario no sea necesario, ya sea temprano o Tendrás que crearlo más tarde.
   

   Pronóstico: a partir de esta versión, Identity API v2 ha quedado en desuso; Es probable que su apoyo cese por completo en un año (pesimista en el lanzamiento de Stein).

3. Los agentes Neutron l3 y dhcp tuvieron la oportunidad de conmutación por error automática: conmutación automática (redistribución) de redes y enrutadores de agentes desconectados a activos. La funcionalidad DVR HA está habilitada de manera predeterminada ( [DEFAULT]/router_distributed , [DEFAULT]/l3_ha ). DVR / SNAT se asigna en un espacio de nombres separado. Al crear un enrutador, snat se crea de manera predeterminada, tomando otra dirección IP de la subred interna:
   
   Este paquete le permite cambiar rápidamente del enrutador actual al enrutador de respaldo del agente l3 que se ejecuta en otro nodo en caso de falla del servicio SNAT.
4. Toda la funcionalidad de Neutron vpn-agent se transfiere a l3-agent; en su configuración necesitas hacer la única edición:
   
   

    [agent]/extensions = vpnaas 

   
   Finalmente, la presencia de un agente vpn dejó de interferir con la construcción de la lógica de implementación automática en el caso de la inclusión de un rol (anteriormente, los agentes vpn y l3 eran mutuamente excluyentes: si coloca un paquete, el otro se elimina).
5. Glance-Registry (proxy para interactuar con la base de datos en API v1) ha sido declarado un servicio desactualizado, ahora puede configurarlo y solo necesita el servicio de api-vistazo. No hay sorpresas, pero se discutirán un poco más tarde.
6. Mamma mia! Heat-dashboard se entrega en un paquete separado (panel enchufable) para Horizon. El complemento ha sufrido muchos cambios, pero la funcionalidad más inesperada fue ... arrastrar y soltar objetos en el proceso de generación de plantillas. Es más fácil ver una vez:
   
   
   
7. Se agregó soporte para volumen multi-adjunto en Cinder: la capacidad de conectar un solo disco a múltiples máquinas virtuales. Hasta ahora, esta funcionalidad se ha implementado solo para un número limitado de controladores compatibles con el servicio: LVM, NetApp / SolidFire, Dell EMC ScaleIO y Oracle ZFSSA; de hecho, este es un gran paso adelante para todo el proyecto (la implementación del mecanismo tomó más de dos años ).
   

   Pronóstico: para Ceph RBD aún no se ha anunciado la compatibilidad con el volumen múltiple de Cinder; lo más probable es que se espere no antes de un año (optimistamente, en el lanzamiento de Stein).

Bichos molestos

(Se descubrieron los siguientes errores al implementar OpenStack Queens en la distribución Ubuntu 16.04.4 LTS (Xenial Xerus); existe la posibilidad de que no aparezcan en otras distribuciones de Linux)

1. En la comunidad Linux, existe un "mantenedor": un especialista que mantiene / mantiene / dirige un determinado componente de software (en un caso particular, un paquete binario). Entonces, los mantenedores de Ubuntu nuevamente (existía un error en la versión de Pike) proporcionaron paquetes para el servicio regular de base de datos de series temporales: Gnocchi. Instalarlos en un entorno Python 2.7 a través de apt "rompe" algunos de los servicios relacionados que se ejecutan en libapache2-mod-wsgi: Keystone, Cinder, Nova Placement, Horizon. El triste caso es cuando desea utilizar un método único para entregar paquetes al sistema. Sin embargo, mientras que para Gnocchi al menos intentaron compilar paquetes, para Octavia solo existen pip y git.
2. No pretendo decirlo, pero tal vez los mismos mantenedores participaron en la creación de paquetes nova-compute. Al menos, esto explicaría por qué cuando se instalan en el sistema (conjuntos de kernel 116, 119 y 124; versiones de paquete de 17.0.1 a 17.0.4) el instalador "se cae" con un error:
   
   

    Setting up nova-compute-libvirt (2:17.0.1-0ubuntu1~cloud0) ... adduser: The user 'nova' does not exist. dpkg: error processing package nova-compute-libvirt (--configure): subprocess installed post-installation script returned error exit status 1 dpkg: dependency problems prevent configuration of nova-compute-kvm: nova-compute-kvm depends on nova-compute-libvirt (= 2:17.0.1-0ubuntu1~cloud0); however: Package nova-compute-libvirt is not configured yet. 

   
   Aquí está la cosa: durante la instalación, se ejecuta un script que debería crear el grupo del sistema nova y el usuario del sistema nova. El script falla con el error, la instalación se bloquea y se agrega una solución a la automatización: realice los gestos mencionados antes de instalar los paquetes. Por cierto, este error aún no está cerrado.
   

   UPD: en el proceso de redacción del artículo, el error finalmente se confirmó y estableció la prioridad promedio. En el momento de resolver el problema (las dependencias cíclicas de los paquetes de Nova entre sí), el responsable de la propuesta propuso otra solución alternativa: primero instale el paquete nova-common, luego nova-compute. En el futuro cercano podemos esperar la versión de los paquetes 17.0.5, sin este inconveniente.

3. Al probar el funcionamiento del servicio Neutron FWaaS, resultó que cuando se elimina un firewall de un enrutador distribuido, no sucede nada ... absolutamente. El cortafuegos cambia del estado "en línea" al estado eterno de "eliminación pendiente", y puede resolver el problema utilizando consultas en la base de datos o eliminando todo el enrutador (este error existía en la versión de Pike). El principal problema en este momento es que la solución (¡que realmente resuelve!) Se propuso hace unos meses, pero aún no se ha llegado a la última versión estable.
4. Ya en la etapa de prueba de carga de la infraestructura, se descubrió que el "procesador de neutrones openvswitch EATING CPU AAAAAAA" - en modo inactivo, el agente de openvswitch cargó uno de los núcleos del procesador al 100%:
   
   

    $ ps aux | grep 16233 neutron 16233 99.5 0.0 311112 143156 ? Rs 19:47 67:11 /usr/bin/python2 /usr/bin/neutron-openvswitch-agent --config-file=/etc/neutron/neutron.conf --config-file=/etc/neutron/plugins/ml2/openvswitch_agent.ini --log-file=/var/log/neutron/neutron-openvswitch-agent.log $ time strace -c -p 16233 % time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 100.00 0.000362 0 95725 epoll_wait 0.00 0.000000 0 15 read 0.00 0.000000 0 6 open 0.00 0.000000 0 6 close 0.00 0.000000 0 6 stat 0.00 0.000000 0 15 fstat 0.00 0.000000 0 20 sendto 0.00 0.000000 0 79 41 recvfrom 0.00 0.000000 0 2 setsockopt 0.00 0.000000 0 94 epoll_ctl ------ ----------- ----------- --------- --------- ---------------- 100.00 0.000362 95968 41 total real 0m10.300s user 0m0.324s sys 0m2.576s 

   
   Los desarrolladores del servicio encontraron la solución al problema lo antes posible; La solución se proporciona en la versión del paquete Neutron 12.0.1-0ubuntu1.1.

Royal Fakap

En OpenStack Queens, los desarrolladores han introducido un nuevo método para descargar imágenes: descarga web, que permite al usuario final "cargar" una imagen por referencia. Érase una vez, cuando Image API v1 aún no estaba en desuso y no fue reemplazado por API v2, esta funcionalidad existía. Parece que lo que pudo haber salido mal ...


En la configuración del servicio vistazo-api, ambos métodos de carga de imágenes, directamente y por referencia, están habilitados de forma predeterminada ( [DEFAULT]/enabled_import_methods ). En pos del objetivo simple de probar la opción, apago uno de los métodos, sobrecargo el servicio y ¡me apresuro!

 CRITICAL glance [-] Unhandled error: ValueError: tuple.index(x): x not in tuple ERROR glance Traceback (most recent call last): ERROR glance File "/usr/bin/glance-api", line 10, in <module> ERROR glance sys.exit(main()) ERROR glance File "/usr/lib/python2.7/dist-packages/glance/cmd/api.py", line 97, in main ERROR glance fail(e) ERROR glance File "/usr/lib/python2.7/dist-packages/glance/cmd/api.py", line 71, in fail ERROR glance return_code = KNOWN_EXCEPTIONS.index(type(e)) + 1 ERROR glance ValueError: tuple.index(x): x not in tuple 

Después de jugar con el parche, vuelvo a sobrecargar el servicio:

 glance-api[26538]: ERROR: Value for option enabled_import_methods is not valid: Value should start with "[" systemd[1]: glance-api.service: Main process exited, code=exited, status=4/NOPERMISSION systemd[1]: glance-api.service: Unit entered failed state. systemd[1]: glance-api.service: Failed with result 'exit-code'. 

En serio, ¿o qué? La opción en la configuración ha adquirido la siguiente forma inadecuada:

 [DEFAULT]/enabled_import_methods = [glance-direct] 

Por supuesto, un error fue cuidadosamente abierto por mí. Los desarrolladores al momento de resolver el problema incluso publicaron un anuncio sobre estos problemas conocidos, conocidos por ellos y enviaron un compromiso a la rama maestra del proyecto. Dos meses después del descubrimiento del error, la solución "se fue" para un lanzamiento futuro; Los afortunados propietarios de Queens deberán esperar los paquetes de Glance versión 16.0.2.
Todo está bien, eso termina bien.

"No pierdas la cabeza, balancea los músculos"

Durante el trabajo de automatización de la implementación (que también involucra los pasos de configuración y pruebas funcionales), Queens demostró ser fuerte, no sobrecargada con nuevas características, sin una "muleta" que sobresalía de todas partes, estableciendo el listón alto para su sucesor.

Sin embargo, a pesar de que Queens es el decimoséptimo (!) Lanzamiento de OpenStack, la tendencia general se ha mantenido durante muchos años: "lo imprevisto no es previsible por intuición imprevista ". Esta cita de la pista del Proyecto Atlantida, en mi opinión, describe de la mejor manera toda la gama de sensaciones recibidas al interactuar con el producto. Por un lado, el despliegue de servicios regulares (Keystone, Glance, Swift, Cinder, Nova, Neutron, Horizon) con configuraciones básicas ha sido depurado durante mucho tiempo y no causará problemas incluso para un ingeniero novato. Por otro lado, cuando se trata de introducir servicios relativamente jóvenes, comienza el "feriado" antes mencionado: resuélvelo como quieras en la escasa documentación, prepárate para pasar días mirando el código y sentado en el popular rastreador de errores.

Sin embargo, todo este sufrimiento es solo un efecto secundario del síndrome de Estocolmo. Pero, de hecho, el ejercicio de pila abierta sacude el cerebro más rápido que cualquier juego lógico, desarrolla habilidades útiles exponencialmente, se mantiene constantemente en buena forma y ciertamente no te deja aburrir. OpenStack definitivamente no era mi amor a primera vista, reducido a calor blanco y desmayo, pero definitivamente merece un poco de amor ahora. Y si está listo para casi tocarlo a través de la oscuridad de las consolas, impulsado por la necesidad de darse cuenta de sí mismo (y hacer que el mundo del código abierto sea un poco mejor), tal vez este sea su camino.