URUS probó Kubernetes en diferentes formas: una implementación independiente de metal desnudo en Google Cloud, y luego movió su plataforma a Mail.ru Cloud Solutions (MCS). Igor Shishkin (
t3ran ), administrador sénior de sistemas de URUS, le dice a Igor Shishkin (
t3ran ), administrador senior de sistemas de URUS, cómo elegir un nuevo proveedor de la nube y cómo lograr migrar a él en dos horas récord
¿Qué hace Urus?
Hay muchas formas de mejorar la calidad del medio ambiente urbano, y una de ellas es hacer que sea ecológico. Esto es exactamente en lo que está trabajando la empresa URUS - Smart Digital Services. Implementa soluciones que ayudan a las empresas a monitorear importantes indicadores ambientales y reducir los impactos ambientales negativos. Los sensores recopilan datos sobre la composición del aire, el nivel de ruido y otros parámetros, y luego los envían a una única plataforma "Urus-Ekomon" para su análisis y preparación de recomendaciones.
¿Cómo es el trabajo de "Urus" dentro
Un cliente típico de URUS es una empresa ubicada en o cerca de un área residencial. Puede ser una fábrica, puerto, depósito ferroviario o cualquier otra instalación. Si nuestro cliente ya recibió una advertencia, fue multado por contaminación ambiental, o quiere hacer menos ruido, reducir la cantidad de emisiones nocivas, se dirige a nosotros y ya le ofrecemos una solución llave en mano para el monitoreo ambiental.
Un gráfico de monitoreo de concentración de H2S muestra las emisiones nocturnas regulares de una instalación cercanaLos dispositivos que utilizamos en URUS contienen varios sensores que recopilan información sobre el contenido de ciertos gases, niveles de ruido y otros datos para evaluar la situación ambiental. El número exacto de sensores siempre está determinado por una tarea específica.
Dependiendo de la medida específica, los dispositivos con sensores pueden ubicarse en las paredes de edificios, postes y otros lugares arbitrarios. Cada uno de estos dispositivos recopila información, la agrega y la envía a la puerta de enlace de recepción de datos. Allí guardamos datos para almacenamiento a largo plazo y preprocesos para análisis posteriores. El ejemplo más simple de lo que obtenemos después del análisis es un índice de calidad del aire, también conocido como AQI.
Al mismo tiempo, muchos otros servicios funcionan en nuestra plataforma, pero básicamente son de naturaleza de servicio. Por ejemplo, el servicio de notificación envía notificaciones a los clientes si alguno de los parámetros monitoreados (por ejemplo, el contenido de CO
2 ) ha excedido el valor permitido.
¿Cómo almacenamos los datos? La historia de Kubernetes en metal desnudo
El proyecto de monitoreo ecológico URUS tiene varios almacenes de datos. En una de ellas, tenemos los datos "en bruto": lo que recibimos directamente de los propios dispositivos. Este almacenamiento es una cinta "magnética", como en los casetes antiguos, con un historial de todos los indicadores. El segundo tipo de almacenamiento se usa para datos preprocesados: datos de dispositivos enriquecidos con metadatos sobre conexiones de sensores y lecturas de dispositivos, afiliación con organizaciones, ubicaciones, etc. Esta información le permite evaluar dinámicamente cómo cambió un indicador en particular durante un cierto período de tiempo . Utilizamos el almacenamiento de datos en bruto, incluso como copia de seguridad y para restaurar datos preprocesados, en caso de necesidad.
Cuando buscábamos formas de resolver el problema de almacenamiento hace varios años, teníamos dos opciones para elegir una plataforma: Kubernetes y OpenStack. Pero dado que este último se ve bastante monstruoso (solo mira su arquitectura para ver esto), entonces nos decidimos por Kubernetes. Otro argumento a su favor fue el control de software relativamente simple, la capacidad de cortar de manera más flexible incluso los nodos de hierro en recursos.
Paralelamente al desarrollo de Kubernetes, también estudiamos formas de almacenar datos, mientras guardamos todos nuestros almacenamientos en Kubernetes en nuestro hardware, recibimos una excelente experiencia. Todo lo que habíamos vivido en Kubernetes: almacenamiento completo, sistema de monitoreo, CI / CD. Kubernetes se ha convertido en nuestra plataforma todo en uno.
Pero queríamos trabajar con Kubernetes como un servicio y no involucrarnos en su apoyo y desarrollo. Además, no nos gustó cuánto nos costó su contenido en metal desnudo, ¡y el desarrollo siempre fue necesario para nosotros! Por ejemplo, una de las primeras tareas fue integrar los controladores Kubernetes Ingress en la infraestructura de red de nuestra organización. Esta es una tarea engorrosa, especialmente si imagina que en ese momento no había nada listo para la gestión programática de recursos como registros DNS o asignación de IP. Más tarde comenzamos a experimentar con un almacén de datos externo. No llegamos a la implementación del controlador de PVC, pero incluso entonces quedó claro que este era un gran campo de trabajo, para lo cual era necesario seleccionar especialistas individuales.
Migración a la solución temporal de Google Cloud Platform
Nos dimos cuenta de que esto no podía continuar más y transferimos nuestros datos de metal desnudo a Google Cloud Platform. De hecho, para la compañía rusa no había muchas opciones interesantes: además de Google Cloud Platform, solo Amazon ofrecía un servicio similar, pero aún así nos decidimos por una solución de Google. Entonces nos pareció económicamente más rentable, más cercano a Upstream, sin mencionar el hecho de que Google es una especie de PoC Kubernetes en producción.
El primer problema grave apareció en el horizonte en paralelo con el crecimiento de nuestra base de clientes. Cuando fue necesario para nosotros almacenar datos personales, nos enfrentamos a una elección: o trabajamos con Google y violamos las leyes rusas, o estamos buscando una alternativa en la Federación Rusa. La elección, en general, era predecible. :)
Cómo vimos el servicio en la nube perfecto
Al comienzo de la búsqueda, ya sabíamos lo que queríamos obtener del futuro proveedor de la nube. Qué servicio buscamos:
- Rápido y flexible . Para que podamos agregar rápidamente un nuevo nodo o implementar algo en cualquier momento.
- Barato Estábamos muy preocupados por el problema financiero, ya que teníamos recursos limitados. Ya sabíamos que queríamos trabajar con Kubernetes, y ahora la tarea era minimizar su costo para aumentar o al menos mantener la efectividad del uso de esta solución.
- Automatizado . Planeamos trabajar con el servicio a través de la API, sin gerentes y llamadas telefónicas o situaciones en las que necesita levantar manualmente varias decenas de nodos en modo de emergencia. Como la mayoría de nuestros procesos están automatizados, esperábamos lo mismo de un servicio en la nube.
- Con servidores en la Federación Rusa . Por supuesto, planeamos cumplir con la ley rusa y ese mismo 152-FZ.
En ese momento, los proveedores de Kubernetes aaS eran pocos en Rusia, mientras que elegir un proveedor, era importante para nosotros no comprometer nuestras prioridades. El equipo de Mail.ru Cloud Solutions, con el que hemos comenzado a trabajar y seguimos trabajando, nos ha proporcionado un servicio totalmente automatizado con soporte API y un panel de control conveniente en el que está Horizon, con el que podríamos aumentar rápidamente un número arbitrario de nodos.
Cómo logramos migrar a MCS en dos horas
En tales reubicaciones, muchas empresas enfrentan dificultades y fracasos, pero en nuestro caso no lo fueron. Tuvimos suerte: como ya estábamos trabajando en Kubernetes antes del inicio de la migración, solo arreglamos tres archivos y lanzamos nuestros servicios en una nueva plataforma en la nube, en MCS. Permítame recordarle que para ese momento finalmente habíamos dejado el metal desnudo y vivíamos en Google Cloud Platform. Debido a que el movimiento en sí no tomó más de dos horas, más un poco más de tiempo (aproximadamente una hora) para copiar datos de nuestros dispositivos. Luego, ya usamos Spinnaker (un servicio de CD de múltiples nubes para proporcionar Entrega Continua). También lo agregamos rápidamente al nuevo clúster y continuamos trabajando como de costumbre.
Gracias a la automatización de los procesos de desarrollo y CI / CD Kubernetes en URUS está ocupado por un especialista (y este soy yo). En algún momento, otro administrador del sistema trabajó conmigo, pero luego resultó que ya habíamos automatizado toda la rutina principal, y desde el lado de nuestro producto principal había más y más tareas y tenía sentido dirigir recursos a esto.
Recibimos del proveedor de la nube lo que esperábamos, ya que comenzamos la cooperación sin ilusiones. Si hubo incidentes, en su mayoría técnicos, que pueden explicarse fácilmente por la relativa frescura del servicio. Lo principal es que el equipo de MCS elimina rápidamente fallas y responde rápidamente a las preguntas en mensajería instantánea.
Si comparamos la experiencia con Google Cloud Platform, en su caso ni siquiera sabía dónde está el botón de comentarios, ya que simplemente no era necesario. Y si sucedió algún problema, Google mismo envió notificaciones unilateralmente. Pero en el caso de MCS, una gran ventaja, creo que están lo más cerca posible de los clientes rusos, tanto geográfica como mentalmente.
Como vemos trabajando con nubes en el futuro
Ahora nuestro trabajo está estrechamente relacionado con Kubernetes, y nos satisface completamente en términos de tareas de infraestructura. Por lo tanto, no planeamos migrar desde algún lugar, aunque constantemente estamos introduciendo nuevas prácticas y servicios para simplificar las tareas rutinarias y automatizar otras nuevas, aumentar la estabilidad y la confiabilidad de los servicios ... Ahora estamos lanzando el servicio Chaos Monkey (específicamente, estamos usando chaoskube, pero esto no cambia el concepto: ), que se creó originalmente en Netflix. Chaos Monkey hace una cosa simple: en un momento arbitrario elimina un bajo arbitrario en Kubernetes. Esto es necesario para que nuestro servicio viva normalmente con el número de instancias n - 1, por lo que nos acostumbramos a estar preparados para cualquier mal funcionamiento.
Ahora veo el uso de soluciones de terceros, las mismas plataformas en la nube, como la única adecuada para empresas jóvenes. Por lo general, al comienzo del viaje tienen recursos limitados, tanto humanos como financieros, y construir y mantener su propia nube o centro de datos es demasiado costoso y requiere mucho tiempo. Los proveedores de la nube pueden minimizar estos costos, pueden obtener rápidamente los recursos necesarios para que los servicios funcionen aquí y ahora, y pagar estos recursos de hecho. En cuanto a la compañía Urus, por ahora seguiremos siendo fieles a Kubernetes en la nube. Pero quién sabe, tal vez tendremos que expandirnos geográficamente o implementar soluciones basadas en algunos equipos específicos. O tal vez la cantidad de recursos consumidos justifique sus propios Kubernetes en metal desnudo, como en los viejos tiempos. :)
Lo que aprendimos de nuestra experiencia con los servicios en la nube
Comenzamos a usar Kubernetes en metal desnudo, e incluso allí fue bueno a su manera. Pero sus puntos fuertes se revelaron precisamente como un componente aaS en la nube. Si establece una meta y automatiza todo lo más posible, podrá evitar el bloqueo del proveedor y moverse entre los proveedores de la nube tomará un par de horas, y las células nerviosas permanecerán con nosotros. Podemos asesorar a otras empresas: si desea iniciar su servicio (en la nube), con recursos limitados y velocidad máxima para el desarrollo, comience ahora alquilando recursos en la nube y construya su centro de datos después de que Forbes escriba sobre usted.