{"id":80952,"date":"2020-05-10T01:42:22","date_gmt":"2020-05-09T23:42:22","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/monitoring-v-czode-kak-my-menyali-staruyu-bms-na-novuyu-chast-2"},"modified":"2020-05-10T01:42:22","modified_gmt":"2020-05-09T23:42:22","slug":"monitoring-v-czode-kak-my-menyali-staruyu-bms-na-novuyu-chast-2","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/monitoring-v-czode-kak-my-menyali-staruyu-bms-na-novuyu-chast-2","title":{"rendered":"Monitoreo en el centro de datos: c\u00f3mo cambiamos nuestro antiguo BMS por uno nuevo. Parte 2","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Monitoreo<\/p>\n

En la primera parte, hablamos sobre por qu\u00e9 decidimos cambiar nuestro antiguo sistema BMS en nuestros centros de datos por uno nuevo. Y no simplemente cambiarlo, sino desarrollarlo desde cero seg\u00fan nuestras necesidades. En la segunda parte, contamos c\u00f3mo lo hicimos.
\n<\/a><\/noindex><\/p>\n

An\u00e1lisis del mercado<\/h2>\n

\nTeniendo en cuenta lo descrito en parte anterior<\/a><\/noindex> las peticiones y la decisi\u00f3n de no actualizar el sistema existente, redactamos un pliego de condiciones para buscar soluciones en el mercado y enviamos solicitudes a varias grandes empresas que se dedican exclusivamente a crear sistemas SCADA industriales.\u00a0<\/p>\n

Las primeras respuestas de ellas mostraron que los l\u00edderes del mercado de sistemas de monitoreo contin\u00faan trabajando predominantemente en servidores f\u00edsicos, aunque el proceso de migraci\u00f3n a la nube en este segmento ya ha comenzado. En cuanto a la disponibilidad de m\u00e1quinas virtuales, esta opci\u00f3n no era compatible con nadie. Adem\u00e1s, daba la impresi\u00f3n de que ninguno de los desarrolladores destacados en el mercado demostraba siquiera comprensi\u00f3n sobre la necesidad de disponer de respaldo: \u00abla nube no se cae\u00bb era la respuesta m\u00e1s frecuente. De hecho, nos ofrecieron alojar el monitoreo del centro de datos en una nube, f\u00edsicamente ubicada en el mismo centro de datos.<\/p>\n

Aqu\u00ed es necesario hacer un peque\u00f1o par\u00e9ntesis sobre el proceso de selecci\u00f3n del contratista. El precio, por supuesto, importa, pero durante cualquier licitaci\u00f3n para la implementaci\u00f3n de un proyecto complicado, en la etapa de di\u00e1logo con los proveedores, comienzas a sentir qui\u00e9n de los candidatos est\u00e1 m\u00e1s interesado y es capaz de llevarlo a cabo.\u00a0<\/p>\n

Esto es especialmente evidente en proyectos complejos.\u00a0<\/p>\n

Por la naturaleza de las preguntas de clarificaci\u00f3n sobre el pliego de condiciones, se pueden dividir a los contratistas en aquellos que est\u00e1n interesados simplemente en vender (se siente la presi\u00f3n est\u00e1ndar de un gerente de ventas) y en aquellos interesados en desarrollar un producto, escuchando y comprendiendo al cliente, haciendo correcciones constructivas en el pliego de condiciones incluso antes de la elecci\u00f3n final (a pesar del riesgo real de mejorar un pliego de otro y perder la licitaci\u00f3n), y en \u00faltima instancia, simplemente dispuestos a aceptar el reto profesional y crear un buen producto.<\/p>\n

Todo esto nos llev\u00f3 a prestar atenci\u00f3n a un desarrollador local relativamente peque\u00f1o: el grupo de empresas \u00abSanline\u00bb, que respondi\u00f3 a la mayor\u00eda de nuestras demandas de inmediato y estaba dispuesto a satisfacer todas las necesidades respecto al nuevo BMS.\u00a0<\/p>\n

Riesgos<\/h2>\n

\nMientras los grandes jugadores intentaban entender qu\u00e9 quer\u00edamos y manten\u00edan una conversaci\u00f3n pausada con la participaci\u00f3n de especialistas de nivel preventa, un desarrollador local program\u00f3 una reuni\u00f3n en nuestra oficina con la presencia de su equipo t\u00e9cnico. En esta reuni\u00f3n, el contratista demostr\u00f3 nuevamente su deseo de participar en el proyecto y, lo m\u00e1s importante, explic\u00f3 c\u00f3mo se implementar\u00e1 el sistema requerido.\u00a0\u00a0\u00a0\u00a0<\/p>\n

Antes de la reuni\u00f3n, identificamos dos riesgos al trabajar con un equipo que no cuenta con el respaldo de una gran empresa nacional o internacional:<\/p>\n

    \n
  1. Los especialistas podr\u00edan sobrestimar sus capacidades y, como resultado, no cumplir, por ejemplo, utilizar software complejo o dise\u00f1ar algoritmos de reserva inviables.<\/li>\n
  2. Tras la implementaci\u00f3n del proyecto, el equipo podr\u00eda disolverse y, por lo tanto, el soporte del producto estar\u00eda en riesgo.<\/li>\n<\/ol>\n

    \nPara mitigar estos riesgos, invitamos a nuestros propios especialistas en desarrollo a la reuni\u00f3n. Los empleados del potencial contratista fueron cuidadosamente interrogados sobre la base del sistema, c\u00f3mo se planea implementar la reserva y otras cuestiones en las que, como servicio de operaciones, no somos suficientemente competentes.<\/p>\n

    El veredicto fue positivo: la arquitectura de la plataforma BMS existente es moderna, simple y confiable, puede ser mejorada, el esquema de reserva y sincronizaci\u00f3n propuesto es l\u00f3gico y funcional.\u00a0<\/p>\n

    Hicimos frente al primer riesgo. Eliminamos el segundo al recibir del contratista la confirmaci\u00f3n de que estaban dispuestos a entregarnos el c\u00f3digo fuente del sistema y la documentaci\u00f3n, adem\u00e1s de elegir el lenguaje de programaci\u00f3n Python, bien conocido por nuestros especialistas. Esto nos garantiz\u00f3 la posibilidad de mantener el sistema por nuestra cuenta sin ninguna dificultad y sin un largo per\u00edodo de formaci\u00f3n para los empleados en caso de que la empresa desarrolladora abandone el mercado.<\/p>\n

    Una ventaja adicional de la plataforma fue que estaba implementada en contenedores Docker: en este entorno funcionan el n\u00facleo, la interfaz web y la base de datos del producto. Este enfoque ofrece numerosas ventajas, incluida la preconfiguraci\u00f3n para una velocidad de despliegue m\u00e1s alta en comparaci\u00f3n con la \"cl\u00e1sica\" y la f\u00e1cil incorporaci\u00f3n de nuevos dispositivos al sistema. El principio de \"todo junto\" simplifica al m\u00e1ximo la implementaci\u00f3n del sistema: basta con descomprimir el sistema y se puede utilizar de inmediato.\u00a0<\/p>\n

    Con esta soluci\u00f3n, es m\u00e1s f\u00e1cil hacer copias del sistema, y se pueden realizar mejoras y realizar actualizaciones en un entorno separado, sin interrumpir el funcionamiento de la soluci\u00f3n en su conjunto.\u00a0\u00a0<\/p>\n

    Despu\u00e9s de minimizar ambos riesgos, el contratista proporcion\u00f3 la propuesta comercial. En ella se trabajaron todos los par\u00e1metros m\u00e1s importantes para nosotros del sistema BMS.<\/p>\n

    Redundancia<\/h2>\n

    \nEl nuevo sistema BMS deb\u00eda estar en la nube, en una m\u00e1quina virtual.\u00a0<\/p>\n

    Sin hardware, sin servidores ni las incomodidades y riesgos asociados con este modelo de despliegue: la soluci\u00f3n en la nube nos permiti\u00f3 deshacernos de ellos para siempre. Se decidi\u00f3 que el sistema funcionar\u00eda en nuestra nube en dos ubicaciones del centro de datos en San Petersburgo y Mosc\u00fa. Estos son dos sistemas completamente funcionales que operan en modo activo en espera con acceso para todos los especialistas autorizados.\u00a0<\/p>\n

    Los dos sistemas se respaldan mutuamente, garantizando completo respaldo tanto en capacidades computacionales como en canales de transmisi\u00f3n de datos. Tambi\u00e9n se han configurado medidas de seguridad adicionales, incluidas las copias de seguridad de datos y canales, sistemas, m\u00e1quinas virtuales en general, y copias de seguridad separadas de la base de datos una vez al mes (el recurso m\u00e1s valioso en la perspectiva de gesti\u00f3n y an\u00e1lisis).\u00a0<\/p>\n

    Cabe destacar que el respaldo como opci\u00f3n de la soluci\u00f3n BMS fue dise\u00f1ado espec\u00edficamente para nuestra solicitud. El esquema de respaldo se ve\u00eda as\u00ed:<\/p>\n

    \"Monitoreo<\/p>\n

    Soporte<\/h2>\n

    Un aspecto crucial para la operaci\u00f3n efectiva de la soluci\u00f3n BMS es el soporte t\u00e9cnico.\u00a0<\/p>\n

    Aqu\u00ed todo es simple: el nuevo sistema nos costar\u00eda 35,000 rublos al mes por este indicador bajo un SLA de \"respuesta en 8 horas\", es decir, 35,000 x 12 \/ 80 = $5,250 al a\u00f1o. El primer a\u00f1o es gratis.\u00a0<\/p>\n

    Para comparaci\u00f3n: el soporte del antiguo BMS por parte del proveedor costaba $18,000 al a\u00f1o, aumentando la cantidad por cada nuevo dispositivo agregado. Adem\u00e1s, la empresa no proporcionaba un gerente dedicado; toda la interacci\u00f3n se realizaba a trav\u00e9s del gerente de ventas, quien estaba m\u00e1s interesado en nosotros como potenciales compradores, lo que influ\u00eda en la atenci\u00f3n a nuestras solicitudes.\u00a0<\/p>\n

    Por menos dinero, obtuvimos un soporte integral del producto, con un gerente de cuenta que participar\u00eda en el desarrollo del producto, con un \u00fanico punto de contacto, etc. El soporte se volvi\u00f3 significativamente m\u00e1s flexible, gracias al acceso directo a los desarrolladores para ajustes operativos sobre cualquier aspecto del funcionamiento del sistema, integraci\u00f3n a trav\u00e9s de API, etc.<\/p>\n

    Actualizaciones<\/h2>\n

    \nEn la cotizaci\u00f3n presentada para el nuevo BMS, todas las actualizaciones est\u00e1n incluidas en el costo del soporte, es decir, no requieren pago adicional. La excepci\u00f3n son los desarrollos de funcionalidades adicionales, m\u00e1s all\u00e1 de lo que se indica en las especificaciones.\u00a0<\/p>\n

    El antiguo sistema requer\u00eda pago tanto por la actualizaci\u00f3n del software gratuito integrado (como Java), como por la correcci\u00f3n de errores. No se pod\u00eda renunciar a esto; sin actualizaciones, el sistema en general 'se ralentizaba' debido a las versiones antiguas de los componentes internos.<\/p>\n

    Y, por supuesto, no se pod\u00eda actualizar el software sin comprar un paquete de soporte.<\/p>\n

    Enfoque flexible<\/h2>\n

    \nOtro requisito fundamental ten\u00eda que ver con la interfaz. Quer\u00edamos asegurar el acceso a ella a trav\u00e9s del navegador web desde cualquier lugar, sin la necesidad de que un ingeniero estuviera presente en las instalaciones del centro de datos. Adem\u00e1s, busc\u00e1bamos crear una interfaz animada para que la din\u00e1mica de funcionamiento de la infraestructura fuera m\u00e1s clara para los ingenieros de guardia.\u00a0<\/p>\n

    Adem\u00e1s, en el nuevo sistema se necesitaba garantizar el soporte de f\u00f3rmulas para el c\u00e1lculo del funcionamiento de sensores virtuales en sistemas de ingenier\u00eda, por ejemplo, para la distribuci\u00f3n \u00f3ptima de potencias el\u00e9ctricas en los racks de equipos. Para ello, es necesario tener a disposici\u00f3n todas las operaciones matem\u00e1ticas habituales aplicables a los indicadores de los sensores.\u00a0<\/p>\n

    Luego, se requer\u00eda acceso a la base de datos SQL con la capacidad de extraer la informaci\u00f3n necesaria sobre el funcionamiento del equipo; es decir, todos los registros de monitoreo de dos mil dispositivos y dos mil sensores virtuales, generando aproximadamente 20 mil variables.\u00a0<\/p>\n

    Tambi\u00e9n se necesitaba un m\u00f3dulo para el seguimiento del equipo en el rack, que proporcionara una representaci\u00f3n gr\u00e1fica de la ubicaci\u00f3n de los dispositivos en cada unidad, calculando el peso total del 'hardware', manteniendo una biblioteca de dispositivos e informaci\u00f3n detallada sobre cada elemento.\u00a0<\/p>\n

    Aprobaci\u00f3n del pliego de condiciones y firma del contrato<\/h2>\n

    \nEn el momento en que era necesario comenzar a trabajar en el nuevo sistema, la correspondencia con las grandes empresas a\u00fan estaba muy lejos de discutir el costo de sus propuestas, por lo que comparamos la oferta recibida con los costos de actualizaci\u00f3n del viejo BMS (ver la primera parte<\/a><\/noindex>), y como resultado, result\u00f3 ser m\u00e1s atractivo en precio y cumplir con nuestros requisitos.<\/p>\n

    Se tom\u00f3 la decisi\u00f3n.<\/p>\n

    Despu\u00e9s de elegir al contratista, los abogados comenzaron a redactar el contrato y los equipos t\u00e9cnicos de ambas partes a pulir el pliego de condiciones. Como es sabido, un pliego de condiciones detallado y bien estructurado es la base del \u00e9xito de cualquier trabajo. Cuanto m\u00e1s espec\u00edfico sea el pliego de condiciones, menos decepciones habr\u00e1 como 'nosotros quer\u00edamos de otra manera'.<\/p>\n

    Voy a dar dos ejemplos del nivel de detalle de los requisitos en el pliego de condiciones:<\/p>\n

      \n
    1. Los operadores del centro de datos tienen la autoridad para agregar nuevos dispositivos al BMS, siendo m\u00e1s frecuentes los PDU. En el viejo BMS, esto era a nivel de 'administrador', permitiendo tambi\u00e9n cambiar las configuraciones de todas las variables de los dispositivos, y dividir las funciones era imposible. Esto no nos satisfac\u00eda. En la versi\u00f3n b\u00e1sica existente de la nueva plataforma, el esquema era an\u00e1logo. Inmediatamente indicamos en el pliego de condiciones que quer\u00edamos dividir estos roles: solo un empleado autorizado debe cambiar las configuraciones, pero los operadores deben seguir teniendo la opci\u00f3n de agregar dispositivos. Este esquema fue aceptado para su implementaci\u00f3n.<\/li>\n
    2. \u00a0En cualquier BMS est\u00e1ndar hay tres categor\u00edas t\u00edpicas de notificaciones: ROJA - requiere una respuesta inmediata, AMARILLA - se puede observar, AZUL - 'Informativa'. Tradicionalmente, utilizamos las notificaciones 'azules' para monitorear el exceso de par\u00e1metros comerciales, por ejemplo, el l\u00edmite de potencia del rack del cliente. Este tipo de notificaciones en nuestro caso estaba destinado a los gerentes y no interesaba al servicio de operaciones, pero en el antiguo BMS saturaba regularmente la lista de incidentes activos y obstaculizaba el trabajo operativo. Consideramos exitosa la l\u00f3gica y diferenciaci\u00f3n de color de las notificaciones, y la mantuvimos, sin embargo, en los t\u00e9rminos de referencia especificamos que las notificaciones 'azules' deben caer silenciosamente en una secci\u00f3n separada, donde ser\u00e1n atendidas por especialistas comerciales sin distraer a los de guardia.<\/li>\n<\/ol>\n

      \nCon un nivel de detalle similar se definieron los formatos para la elaboraci\u00f3n de gr\u00e1ficos y la generaci\u00f3n de informes, los contornos de las interfaces, la lista de dispositivos que deb\u00edan ser monitoreados y muchas otras cosas.\u00a0<\/p>\n

      Fue realmente un trabajo creativo de tres grupos de trabajo: el servicio del cliente, que dict\u00f3 sus requisitos y condiciones; los especialistas t\u00e9cnicos de ambas partes, cuya tarea era transformar estas condiciones en documentaci\u00f3n t\u00e9cnica; y el equipo de programadores del contratista, que implement\u00f3 los requisitos del cliente seg\u00fan la documentaci\u00f3n t\u00e9cnica desarrollada... Al final, algo de nuestros requisitos no cr\u00edticos fue adaptado a la funcionalidad de la plataforma existente, y el contratista se comprometi\u00f3 a a\u00f1adir algunas cosas para nosotros.\u00a0<\/p>\n

      Trabajo paralelo de dos sistemas<\/h2>\n

      \n\"Monitoreo
      \nLleg\u00f3 el momento de la implementaci\u00f3n. En la pr\u00e1ctica, esto significaba que d\u00e1bamos al contratista la oportunidad de desplegar un prototipo de BMS en nuestra nube virtual y proporcionamos acceso de red a todos los dispositivos que requieren monitoreo.<\/p>\n

      Sin embargo, el nuevo sistema a\u00fan no estaba listo para funcionar. En esta etapa, era importante para nosotros mantener el monitoreo en el antiguo sistema y al mismo tiempo proporcionar acceso a los dispositivos desde el nuevo sistema. No es posible construir un sistema adecuadamente sin ver los dispositivos en \u00e9l, que a su vez no se pueden desconectar del monitoreo del antiguo sistema.\u00a0<\/p>\n

      Era incierto si los dispositivos soportar\u00edan un sondeo simult\u00e1neo de dos sistemas sin pruebas reales. Exist\u00eda la posibilidad de que un sondeo doble simult\u00e1neo condujera a frecuentes fallos en las respuestas de los dispositivos, y obtendr\u00edamos numerosos errores de inaccesibilidad, lo que a su vez bloquear\u00eda el funcionamiento del antiguo sistema de monitoreo.<\/p>\n

      El departamento de redes estableci\u00f3 rutas virtuales desde el prototipo de la nueva BMS, desplegada en la nube, hacia los dispositivos, y obtuvimos los resultados:\u00a0<\/p>\n