🔰 🕴🏾 🐘 Monitoreo en el centro de datos: cómo cambiamos el viejo BMS a uno nuevo. Parte 2 👩‍👩‍👧‍👦 👸🏻 🚤

En la primera parte, hablamos sobre por qué decidimos cambiar el viejo sistema BMS en nuestros centros de datos a uno nuevo. Y no solo cambia, sino que se desarrolla desde cero para satisfacer sus necesidades. En la segunda parte contamos cómo lo hicimos.

Análisis de mercado

Con base en los deseos y decisiones descritos en la primera parte , para negarse a actualizar el sistema existente, escribimos una declaración de trabajo para encontrar una solución en el mercado e hicimos consultas a varias grandes empresas que solo están involucradas en la creación de sistemas industriales SCADA.

Las primeras respuestas de ellos mostraron que los líderes del mercado de sistemas de monitoreo continúan trabajando principalmente en servidores de hierro, aunque el proceso de migración a las nubes en este segmento ya ha comenzado. En cuanto a las máquinas virtuales de respaldo, nadie admitió esta opción. Además, se tenía la sensación de que ninguno de los desarrolladores visibles en el mercado mostraba una comprensión de la necesidad de redundancia: "la nube no cae", era la respuesta más común. De hecho, se nos ofreció ubicar el monitoreo del centro de datos en una nube ubicada físicamente en el mismo centro de datos.

Aquí es necesario hacer una pequeña digresión sobre el proceso de selección de un contratista. El precio, por supuesto, es importante, pero durante cualquier licitación para la implementación de un proyecto complejo, en la etapa de diálogo con los proveedores, comienza a sentir cuál de los candidatos está más interesado y puede implementarlo.

Esto es especialmente notable en proyectos complejos.

Por la naturaleza de las preguntas de aclaración para TK, es posible dividir a los contratistas entre aquellos interesados simplemente en vender (se siente la presión estándar del gerente de ventas) y aquellos interesados en desarrollar el producto, habiendo escuchado y entendido al cliente, para hacer modificaciones constructivas a las especificaciones técnicas incluso antes de la elección final (incluso a pesar de la verdadera elección) riesgo de mejorar el TK de otra persona y perder la oferta), al final, simplemente listo para aceptar el desafío profesional y hacer un buen producto.

Todo esto nos hizo prestar atención a un desarrollador local relativamente pequeño: el grupo de compañías Sunline, que respondió a la mayoría de nuestros requisitos de inmediato y estaba listo para satisfacer todas las necesidades relacionadas con el nuevo BMS.

Los riesgos

Mientras los grandes jugadores intentaban entender lo que queríamos, y manteníamos una correspondencia pausada con la ayuda de especialistas en preventa, un desarrollador local hizo una cita en nuestra oficina con la participación de su equipo técnico. En esta reunión, el contratista demostró una vez más su deseo de participar en el proyecto y, lo más importante, explicó cómo se implementará el sistema requerido.

Antes de la reunión, vimos dos riesgos de trabajar con un equipo que no tiene los recursos de una gran empresa nacional o internacional:

Los especialistas pueden sobreestimar sus capacidades y, como resultado, simplemente no pueden hacer frente, por ejemplo, utilizarán software sofisticado o diseñarán algoritmos de respaldo poco prácticos.
Después de la implementación del proyecto, el equipo del proyecto puede separarse y, por lo tanto, el soporte del producto estará en peligro.

Para minimizar estos riesgos, invitamos a nuestros propios especialistas en desarrollo a la reunión. Los empleados de un posible contratista fueron entrevistados a fondo sobre en qué se basa el sistema, cómo se planea implementar las reservas y sobre otros asuntos en los que nosotros, como servicio de operación, no somos lo suficientemente competentes.

El veredicto fue positivo: la arquitectura de la plataforma BMS existente es moderna, simple y confiable, se puede finalizar, el esquema de respaldo y sincronización propuesto es lógico y eficiente.

Afrontaron el primer riesgo. Excluyeron el segundo, después de haber recibido la confirmación del contratista de que estaban listos para darnos el código fuente del sistema y la documentación, así como de elegir el lenguaje de programación Python que nuestros especialistas conocían bien. Esto nos garantizó la oportunidad de mantener el sistema por nuestra cuenta sin ninguna dificultad y un largo período de capacitación para los empleados en caso de que la empresa desarrolladora abandone el mercado.

Una ventaja adicional de la plataforma fue que se implementó en contenedores Docker: en este entorno, el núcleo, la interfaz web y la función de base de datos del producto. Este enfoque ofrece muchas ventajas, incluida la configuración preestablecida para la velocidad de implementación más alta de la solución en comparación con los "clásicos" y la simple adición de nuevos dispositivos al sistema. El principio de "todos juntos" simplifica la implementación del sistema tanto como sea posible: es suficiente para desempaquetar el sistema y puede operarlo de inmediato.

Con tal solución, es más fácil hacer copias del sistema, y es posible mejorarlo e implementar actualizaciones en un entorno separado sin detener la solución en su conjunto.

Después de minimizar ambos riesgos, el contratista proporcionó KP. Resolvió todos los parámetros más importantes del sistema BMS para nosotros.

Reserva

Se suponía que el nuevo sistema BMS estaba en la nube en una máquina virtual.

Sin hardware, sin servidores y todos los inconvenientes y riesgos asociados con este modelo de implementación: la solución en la nube nos permitió deshacernos de ellos para siempre. Se decidió que el sistema funcionará en nuestra nube en dos sitios de centros de datos en San Petersburgo y Moscú. Estos son dos sistemas completamente funcionales que funcionan en modo de espera activo con acceso para todos los especialistas autorizados.

Los dos sistemas se aseguran entre sí, proporcionando una reserva completa tanto para la potencia informática como para los canales de transmisión de datos. También se establecen medidas de seguridad adicionales, incluida la copia de seguridad de datos y canales, sistemas, máquinas virtuales en general y una copia de seguridad separada de la base de datos una vez al mes (el recurso más valioso en la perspectiva de la gestión y el análisis).

Tenga en cuenta que la redundancia como una opción de la solución BMS se desarrolló específicamente para nuestra solicitud. El esquema de respaldo en sí se veía así:

Apoyo

El punto más importante para la operación efectiva de una solución BMS es el soporte técnico.

Aquí todo es simple: un nuevo sistema nos costaría 35,000 rublos en este indicador. por mes para el SLA "respuesta dentro de 8 horas", es decir, 35,000 x 12/80 = $ 5,250 por año. El primer año es gratis.

A modo de comparación: el soporte del antiguo BMS del proveedor cuesta $ 18,000 dólares al año con un aumento en la cantidad por cada nuevo dispositivo agregado. Al mismo tiempo, la compañía no proporcionó un gerente dedicado, toda interacción tuvo lugar a través de un gerente de ventas que está interesado en nosotros como un comprador potencial con el énfasis correspondiente en el procesamiento de solicitudes.

Por menos dinero, recibimos soporte completo del producto, con un gerente de cuenta que participaría en el desarrollo del producto, con un único punto de entrada, etc. El soporte se volvió mucho más flexible, gracias al acceso directo a los desarrolladores para ajustes operativos en cualquier aspecto del sistema, integración a través de API, etc.

Actualizaciones

De acuerdo con el KP propuesto en el nuevo BMS, todas las actualizaciones están incluidas en el costo del soporte, es decir, No requieren pago adicional. Una excepción es el desarrollo de una funcionalidad adicional más allá de la especificada en los Términos de Referencia.

El antiguo sistema asumía el pago tanto por actualizar el firmware del software libre (como Java) como por corregir errores. Era imposible rechazar esto, en ausencia de actualizaciones, el sistema en su conjunto "se desaceleró" debido a versiones antiguas de componentes internos.

Y, por supuesto, era imposible actualizar el software sin comprar un paquete de soporte.

Acercamiento flexible

Otro requisito fundamental se refería a la interfaz. Queríamos proporcionar acceso a él a través de un navegador web desde cualquier lugar, sin la presencia de un ingeniero en el centro de datos. Además, nos esforzamos por crear una interfaz animada, de modo que la dinámica del funcionamiento de la infraestructura fuera más visible para los ingenieros de servicio.

También en el nuevo sistema, era necesario proporcionar soporte para fórmulas para calcular el funcionamiento de sensores virtuales en sistemas de ingeniería, por ejemplo, para la distribución óptima de energía eléctrica entre bastidores con equipos. Para hacer esto, debe tener a su disposición todas las operaciones matemáticas habituales aplicables a los indicadores de los sensores.

Además, se requería acceso a la base de datos SQL, con la capacidad de extraer de ella los datos necesarios sobre el funcionamiento del equipo, es decir, todos los registros sobre el monitoreo de dos mil dispositivos y dos mil sensores virtuales que generan unas 20 mil variables.

También necesitábamos un módulo para equipos de contabilidad en el rack, que proporcionara una representación gráfica de la ubicación de los dispositivos en cada unidad con el cálculo del peso total del hardware, manteniendo una biblioteca de dispositivos e información detallada sobre cada elemento.

Armonización de los conocimientos tradicionales y firma de un acuerdo

En ese momento, cuando era necesario comenzar a trabajar en el nuevo sistema, la correspondencia con las compañías "grandes" todavía estaba muy lejos de discutir el costo de sus propuestas, por lo que comparamos el KP recibido con los costos de actualizar el antiguo BMS (ver la primera parte ), y Como resultado, resultó ser más atractivo en términos de precio y correspondiente a nuestros requisitos.

La elección ha sido hecha.

Después de elegir un contratista, los abogados comenzaron a redactar un contrato y los equipos técnicos de ambos lados pulieron las especificaciones técnicas. Como saben, un conocimiento pormenorizado detallado y competente es la base para el éxito de cualquier trabajo. Mientras más detalles en TK, menos decepciones como "pero no nos gustó eso".

Daré dos ejemplos del nivel de detalle de los requisitos en TK:

BMS , PDU. BMS «», , . . . , : , . .
BMS : – , – , – «». «» , , . , BMS . , , «» , , «» , .

Con un grado similar de detalle, formatos de gráficos e informes, esquemas de interfaz, una lista de dispositivos que necesitaban ser monitoreados, y se prescribieron muchas otras cosas.

Fue un trabajo verdaderamente creativo de tres grupos de trabajo: servicio al cliente, que dictaba sus requisitos y condiciones; especialistas técnicos de ambos lados cuya tarea era convertir estas condiciones en documentación técnica; equipos de programadores de contratistas que implementaron los requisitos del cliente para la documentación técnica desarrollada ... Como resultado, adaptamos algunos de nuestros requisitos sin principios a la funcionalidad de una plataforma existente, algo que el contratista se comprometió a agregar para nosotros.

Operación paralela de dos sistemas.

Es tiempo de implementación. En la práctica, esto significa que le estamos dando al contratista la oportunidad de implementar un prototipo de BMS en nuestra nube virtual y proporcionar acceso a la red a todos los dispositivos que requieren monitoreo.

Además, el nuevo sistema aún no estaba listo para funcionar. En esta etapa, era importante para nosotros mantener el monitoreo en el sistema antiguo y al mismo tiempo dar acceso a los dispositivos del nuevo sistema. Es imposible construir un sistema normalmente sin ver dispositivos en él, que a su vez no pueden desconectarse del monitoreo por el sistema antiguo.

Si los dispositivos pueden soportar el sondeo simultáneo por dos sistemas no era obvio sin pruebas reales. Era posible que una doble encuesta simultánea condujera a la denegación frecuente de respuestas de los dispositivos y recibiríamos muchos errores debido a la falta de disponibilidad de los dispositivos, lo que a su vez bloquearía el funcionamiento del antiguo sistema de monitoreo.

El departamento de red lanzó rutas virtuales desde el prototipo del nuevo BMS implementado en la nube a los dispositivos, y obtuvimos los resultados:

los dispositivos conectados a través del protocolo SNMP prácticamente no se desconectaron debido a llamadas simultáneas,
Los dispositivos conectados a través de puertas de enlace que utilizan protocolos modbas-TCP tuvieron problemas que se resolvieron mediante una reducción razonable en la frecuencia de su sondeo.

Y luego comenzamos a observar cómo se estaba construyendo un nuevo sistema ante nuestros ojos, que ya nos resultaba familiar a los dispositivos, pero en una interfaz diferente: conveniente, rápida y accesible incluso desde el teléfono.

Hablaremos sobre lo que sucedió como resultado en la tercera parte de nuestro artículo.

Monitoreo en el centro de datos: cómo cambiamos el viejo BMS a uno nuevo. Parte 2