Thread by @irontec

Un cliente del ámbito de la energía solar nos propone un reto: llevar a cabo la ingesta de miles de datos por segundo desde múltiples emisores, asumiendo el procesado, almacenamiento y posterior explotación de dichos datos. Lo hemos conseguido y te contamos cómo. Hilo va.

Aunque podríamos pararnos a hablar de las diferentes piezas de este proyecto de #BigData, hoy nos centraremos en mostrarte cómo hemos desplegado más de mil contenedores para la parte de recepción, procesado, caché e inserción en BBDD de todos esos datos.

Empezamos por el principio: Desde el equipo de desarrollo y en coordinación con el equipo de sistemas de Irontec, se diseña una arquitectura con los siguientes elementos: #MQTT, #Redis, #ClusterBBDDRelacional, #Elasticsearch…

En el proyecto hay cientos de elementos mandando información. Por tanto, la idea consiste en que por cada emisor (en este caso, por cada instalación solar), tengamos un flujo completo de recepción y procesado de datos, aislando los problemas que pudiera tener cada uno, del resto.

¿Cómo lo conseguimos? Con un pequeño stack (o pila de procesos: recepción, caché y procesado) que se empaqueta en forma de contenedor. Este pequeño stack hay que desplegarlo cientos de veces, de manera automática, a través de un panel de gestión que controla el cliente.

Además, cada pequeño stack está compuesto por 3 contenedores, lo cual nos lleva a tener que gestionar miles de contenedores. Cada contenedor tiene su función, uno para la recepción, otro para el caché y otro para el procesado e inserción.

Cuando quieres gestionar unos pocos contenedores, el orquestador a utilizar (o no) es una decisión con varias opciones. Sin embargo, cuando hablamos de tal volumen de contenedores la respuesta de la industria #FLOSS nos lleva claramente a @kubernetesio

El proyecto (hijo de @Google) tiene una demostrada capacidad a la hora de gestionar clusters (agrupación de varias máquinas o servidores) de pocos nodos o de varios cientos.

El dimensionamiento del clúster de #Kubernetes es un proceso crítico, aunque por suerte tenemos flexibilidad tras el despliegue inicial, teniendo en cuenta que es posible empezar con pocas máquinas e ir creciendo, ajustando así el coste de la infraestructura en base al uso real

En este sentido, algunas decisiones eran evidentes desde la primera lectura de la documentación, como por ejemplo, la separación de los nodos de gestión de los de carga de trabajo.

Otras soluciones pudimos deducirlas del entorno de pre: consumo de RAM/CPU por contenedor/POD, y con ello el dimensionamiento de cada nodo de trabajo. Otro día hablaremos de #prometheus, os lo prometemos (chiste malo del departamento de chistemas).

Y por último, aprendimos "the hard way" cómo sortear el límite de contenedores por nodo debido al uso de IPV4.

github.com/kelseyhightowe….

En el proyecto, durante el despliegue y gestión de Kubernetes, nos ha sido muy útil #Rancher (ahora bajo el paraguas de @SUSE_Spain), concretamente usamos dos de sus productos.

Por un lado, #RKE, un sistema de despliegue de kubernetes certificado por la @CloudNativeFdn que nos permite definir nuestro clúster en un fichero YAML y poder aplicar metodologías de infraestructura como código. Esto hace posible escalar el clúster, cambiar roles en nodos, etc.

Y, por otro lado, tenemos la herramienta visual de gestión de clústeres Rancher (si, la verdad es que se han lucido con los nombres y genera un poco de confusión).

Se trata de una herramienta muy potente y totalmente agnóstica de la distribución de Kubernetes que usemos. Podemos gestionar clústeres on-premise (en nuestra propia infraestructura) desplegados con RKE y otros como los que ofrecen los principales proveedores cloud.

En el departamento de sistemas de @irontec adoramos la consola y nos encanta vivir entre yamls, comandos kubectl y git. Pero reconocemos la utilidad de herramientas que faciliten las tareas a otras personas (y a nosotros mismos más de una vez).

Y con esto llegamos al final. Si vemos que realmente interesa el tema, podríamos hablaros sobre cómo usamos las tecnologías FLOSS para dar respuesta a diferentes casuísticas. ¿Tienes un reto? ¿Te gustaría contarnos tu idea o proyecto? Déjanos un comentario y lo analizamos ;)