En la primera parte, hablamos de por qué decidimos reemplazar el antiguo sistema BMS de nuestros centros de datos por uno nuevo. Y no sólo cambiar, sino desarrollar desde cero para adaptarlo a sus necesidades. En la segunda parte te contamos cómo lo hicimos.
El análisis del mercado
Teniendo en cuenta los descritos en deseos y la decisión de negarnos a actualizar el sistema existente, escribimos una especificación técnica para encontrar una solución en el mercado y realizamos consultas a varias grandes empresas dedicadas únicamente a la creación de sistemas SCADA industriales.
Las primeras respuestas de ellos mostraron que los líderes del mercado de sistemas de monitoreo continúan trabajando predominantemente en servidores de hardware, aunque el proceso de migración a las nubes en este segmento ya ha comenzado. En cuanto a reservar máquinas virtuales, nadie admitía esta opción. Además, existía la sensación de que ninguno de los desarrolladores destacados del mercado demostraba siquiera comprender la necesidad de redundancia: "la nube no se cae" fue la respuesta más común. De hecho, nos ofrecieron colocar el monitoreo del centro de datos en una nube ubicada físicamente en el mismo centro de datos.
Aquí debemos hacer una pequeña digresión sobre el proceso de selección de un contratista. El precio, por supuesto, importa, pero durante cualquier licitación para la implementación de un proyecto complejo, en la etapa de diálogo con los proveedores, se comienza a sentir cuál de los candidatos está más interesado y es más capaz de implementarlo.
Esto es especialmente notable en proyectos complejos.
Según la naturaleza de aclarar las cuestiones relativas a las especificaciones técnicas, los contratistas se pueden dividir en aquellos interesados en simplemente vender (se siente la presión estándar de un gerente de ventas) y aquellos interesados en desarrollar un producto, habiendo escuchado y comprendido al cliente, haciendo una propuesta constructiva. modificaciones a las especificaciones técnicas incluso antes de la elección final (incluso a pesar del riesgo real de mejorar las especificaciones técnicas de otra persona y perder la licitación), al final simplemente están dispuestos a aceptar un 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 empresas Sunline, que respondió a la mayoría de nuestros requisitos de inmediato y estaba listo para implementar todas las necesidades relacionadas con el nuevo BMS.
Riesgos
Mientras los grandes jugadores intentaban entender lo que queríamos y mantenían una tranquila correspondencia con nosotros involucrando a especialistas del nivel de preventa, el desarrollador local programó una reunión en nuestra oficina con la participación de su equipo técnico. En esta reunión, el contratista volvió a demostrar su deseo de participar en el proyecto y, lo más importante, explicó cómo se implementaría el sistema requerido.
Antes de la reunión vimos dos riesgos de trabajar con un equipo que no tiene detrás los recursos de una gran empresa nacional o internacional:
- Los especialistas podrían sobrestimar sus capacidades y, como resultado, simplemente no lograrían hacer frente a esta situación; por ejemplo, utilizarían software complejo o diseñarían algoritmos de reserva inviables.
- Una vez completado el proyecto, el equipo del proyecto puede desintegrarse y, por lo tanto, el soporte del producto estará en peligro.
Para minimizar estos riesgos, invitamos a la reunión a nuestros propios especialistas en desarrollo. Los empleados del posible contratista fueron entrevistados minuciosamente sobre en qué se basa el sistema, cómo se planea implementar la redundancia y otras cuestiones en las que nosotros, como servicio operativo, no somos lo suficientemente competentes.
El veredicto fue positivo: la arquitectura de la plataforma BMS existente es moderna, sencilla y fiable, se puede mejorar, el esquema de redundancia y sincronización propuesto es lógico y viable.
Se abordó el primer riesgo. El segundo fue excluido después de recibir la confirmación del contratista de que estaban listos para transferirnos el código fuente del sistema y la documentación, así como de elegir el lenguaje de programación Python, que era bien conocido por nuestros especialistas. Esto nos garantizó la posibilidad de mantener el sistema nosotros mismos sin dificultades y un largo período de formación de los empleados en caso de que la empresa desarrolladora abandonara el mercado.
Una ventaja adicional de la plataforma fue que se implementó en contenedores Docker: en este entorno funcionan el kernel, la interfaz web y la base de datos del producto. Este enfoque ofrece muchas ventajas, incluida la configuración preestablecida para la mayor velocidad de implementación de la solución en comparación con la adición "clásica" y sencilla de nuevos dispositivos al sistema. El principio de "todos juntos" simplifica al máximo la implementación del sistema: simplemente desembale el sistema y podrá utilizarlo inmediatamente.
Con esta solución, es más fácil hacer copias del sistema y puede mejorarlo e implementar actualizaciones en un entorno separado, sin detener el funcionamiento de la solución en su conjunto.
Una vez minimizados ambos riesgos, el contratista proporcionó el CP. Cubrió todos los parámetros más importantes del sistema BMS para nosotros.
Reserva
El nuevo sistema BMS debía estar ubicado en la nube, en una máquina virtual.
Sin hardware, sin servidores y con 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ía en nuestra nube en dos centros de datos en San Petersburgo y Moscú. Se trata de dos sistemas totalmente funcionales que funcionan en modo de espera activo con acceso a todos los especialistas autorizados.
Los dos sistemas se aseguran mutuamente, proporcionando una reserva total tanto de potencia informática como de canales de transmisión de datos. También se han configurado medidas de seguridad adicionales, incluyendo 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 términos de gestión y análisis).
Tenga en cuenta que la redundancia como opción en la solución BMS se desarrolló específicamente para nuestra solicitud. El esquema de reserva en sí era el siguiente:
Apoyar
El punto más importante para el funcionamiento eficaz de una solución BMS es el soporte técnico.
Aquí todo es sencillo: un nuevo sistema nos costaría 35 rublos según este indicador. por mes para el SLA “respuesta dentro de 000 horas”, es decir, 8 x 35/000 = $12 por año. El primer año es gratis.
En comparación, mantener el antiguo BMS del proveedor costaba $18 000 por año, ¡con un aumento en la cantidad por cada nuevo dispositivo agregado! Al mismo tiempo, la empresa no proporcionó un gerente dedicado, toda la interacción se realizó a través de un gerente de ventas que está interesado en nosotros como comprador potencial con el correspondiente énfasis 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 realizar ajustes rápidos en cualquier aspecto del sistema, la integración a través de API, etc.
Actualizaciones
Según el CP propuesto en el nuevo BMS, todas las actualizaciones están incluidas en el coste del soporte, es decir no requieren pago adicional. La excepción es el desarrollo de funcionalidades adicionales más allá de lo especificado en las especificaciones técnicas.
El antiguo sistema requería pago tanto por las actualizaciones de firmware (como Java) como por la corrección de errores. Era imposible rechazar esto, en ausencia de actualizaciones, el sistema en su conjunto "se ralentizó" debido a las versiones antiguas de los componentes internos.
Y, por supuesto, era imposible actualizar el software sin adquirir un paquete de soporte.
Enfoque flexible
Otro requisito fundamental se refería a la interfaz. Queríamos brindar acceso a él a través de un navegador web desde cualquier lugar, sin la presencia obligatoria de un ingeniero en el territorio del centro de datos. Además, se buscó crear una interfaz animada para que la dinámica de la infraestructura fuera más clara para los ingenieros de turno.
Además, en el nuevo sistema era necesario admitir 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 los racks de equipos. Para ello, es necesario tener a su disposición todas las operaciones matemáticas habituales aplicables a los indicadores de sensores.
A continuación, fue necesario acceder a una base de datos SQL con la posibilidad de extraer de ella los datos necesarios sobre el funcionamiento del equipo, es decir, todos los registros de seguimiento de dos mil dispositivos y dos mil sensores virtuales que generan aproximadamente 20 mil variables.
También se necesitaba un módulo de contabilidad de equipos de rack, brindando una representación gráfica de la disposición de los dispositivos en cada unidad con cálculo del peso total del hardware, manteniendo una biblioteca de dispositivos e información detallada de cada elemento.
Aprobación de especificaciones técnicas y firma de convenio.
En el momento en que fue necesario comenzar a trabajar en el nuevo sistema, la correspondencia con las "grandes" empresas aún estaba muy lejos de discutir el costo de sus propuestas, por lo que comparamos el CP recibido con los costos de actualizar el antiguo BMS (ver. ), y como resultado resultó ser más atractivo en precio y cumplir con nuestros requisitos.
La elección ha sido hecha.
Después de seleccionar un contratista, los abogados comenzaron a redactar un acuerdo y los equipos técnicos de ambas partes comenzaron a pulir las especificaciones técnicas. Como usted sabe, las especificaciones técnicas detalladas y competentes son la base del éxito de cualquier trabajo. Cuanto más detalles haya en las especificaciones técnicas, menos decepciones como "pero esto no es lo que queríamos".
Daré dos ejemplos del nivel de detalle de los requisitos en las especificaciones técnicas:
- Los centros de datos de servicio están autorizados a agregar nuevos dispositivos al BMS, en la mayoría de los casos se trata de PDU. En el antiguo BMS, este era el nivel de "administrador", que también permitía cambiar la configuración variable de todos los dispositivos y era imposible separar las funciones. Esto no nos convenía. En la versión básica existente de la nueva plataforma, el esquema era similar. Inmediatamente indicamos en los términos de referencia que queríamos separar estos roles: solo un empleado autorizado debería cambiar la configuración, pero los que están de servicio deberían seguir pudiendo agregar dispositivos. Este esquema fue aceptado para su implementación.
- En cualquier BMS estándar hay tres categorías típicas de notificaciones: ROJO - debe responderse de inmediato, AMARILLO - puede observarse, AZUL - "Informativo". Tradicionalmente hemos utilizado alertas azules para monitorear cuándo se han excedido los parámetros comerciales, como cuando el rack de un cliente excede su límite de capacidad. En nuestro caso, este tipo de notificación estaba destinada a los gerentes y no era de interés para el servicio de operaciones, pero en el antiguo BMS obstruía regularmente la lista de incidentes activos e interfería con el trabajo operativo. Consideramos exitosa la lógica misma y la diferenciación de color de los pantalones de notificación y la mantuvimos, sin embargo, las especificaciones técnicas indicaban específicamente que las notificaciones "azules" debían, sin distraer a los oficiales de servicio, "verterse" silenciosamente en una sección separada, donde serán tratados por especialistas comerciales.
Con similar nivel de detalle, se prescribieron los formatos para construir gráficos y generar informes, los esquemas de las interfaces, la lista de dispositivos que debían monitorearse y muchas otras cosas.
Fue un trabajo verdaderamente creativo de tres grupos de trabajo: el de atención al cliente, que dictaba sus requisitos y condiciones; especialistas técnicos de ambas partes, cuya tarea era transformar estas condiciones en documentación técnica; equipos de programadores contratistas que implementaron los requisitos del cliente de acuerdo con la documentación técnica desarrollada... Como resultado, adaptamos algunos de nuestros requisitos sin principios a la funcionalidad de una plataforma existente, y el contratista se comprometió a agregar algo para nosotros.
Funcionamiento paralelo de dos sistemas.
Es hora de implementarlo. En la práctica, esto significó que le damos 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.
Sin embargo, 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 al nuevo sistema. Es imposible construir correctamente un sistema sin ver los dispositivos en él, que a su vez no se pueden desactivar del monitoreo mediante el sistema anterior.
Si los dispositivos podrían resistir la interrogación simultánea por parte de dos sistemas no era evidente sin pruebas reales. Existía la posibilidad de que el doble sondeo simultáneo provocara frecuentes negativas a responder de los dispositivos y recibiéramos muchos errores sobre la falta de disponibilidad de los dispositivos, lo que a su vez bloquearía el funcionamiento del antiguo sistema de monitoreo.
El departamento de redes ejecutó rutas virtuales desde un prototipo del nuevo BMS implementado en la nube hasta los dispositivos y obtuvimos los resultados:
- los dispositivos conectados a través del protocolo SNMP prácticamente nunca se desconectaron debido a solicitudes simultáneas,
- Los dispositivos conectados a través de puertas de enlace que utilizan protocolos modbas-TCP tuvieron problemas que se resolvieron reduciendo inteligentemente su frecuencia de sondeo.
Y luego comenzamos a observar cómo se estaba construyendo un nuevo sistema ante nuestros ojos, en él aparecieron dispositivos que ya conocíamos, pero en una interfaz diferente: conveniente, rápida y accesible incluso desde un teléfono.
Te contamos lo que sucedió al final en la tercera parte de nuestro artículo.
Fuente: habr.com