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



¿Qué es un BMS?


El sistema de monitoreo de los sistemas de ingeniería en el centro de datos es un elemento clave de la infraestructura que afecta directamente un indicador tan importante para el centro de datos como la velocidad de respuesta del personal ante emergencias y, por lo tanto, la duración de la operación ininterrumpida. 

Muchos proveedores mundiales de equipos de centros de datos ofrecen sistemas de monitoreo BMS (Building Monitoring System). Durante el trabajo del Linxdatacenter en Rusia, tuvimos la oportunidad de conocer diferentes sistemas y encontrar enfoques diametralmente opuestos de los proveedores para operar estos sistemas. 

Le contamos cómo actualizamos completamente nuestro sistema BMS durante el año pasado y por qué.  

La raíz del problema


Todo comenzó hace 10 años con el lanzamiento del centro de datos Linxdatacenter en San Petersburgo. El sistema BMS, de acuerdo con los estándares de la industria de esos años, era un servidor físico con software instalado al que se accede a través de un programa cliente (el llamado cliente "grueso"). 

Había pocas compañías que ofrecieran tales soluciones en ese momento. Sus productos eran el estándar, la única respuesta a una solicitud existente. Y debemos darles lo que les corresponde: tanto en la actualidad como en la actualidad, los líderes del mercado en su conjunto hacen frente a su tarea básica: la entrega de soluciones funcionales para la operación de los centros de datos. 

La elección lógica para nosotros fue la solución BMS de uno de los fabricantes más grandes del mundo. El sistema seleccionado en ese momento cumplía con todos los requisitos para monitorear una instalación de ingeniería integrada, que es un centro de datos. 

Sin embargo, con el tiempo, los requisitos y expectativas de los usuarios (es decir, nosotros, los operadores de centros de datos) de las soluciones de TI han cambiado. Y los grandes proveedores, como lo muestra el análisis del mercado de soluciones propuestas, no estaban preparados para esto.

El mercado corporativo de TI ha sido fuertemente influenciado por la industria B2C. Las soluciones digitales de hoy deberían garantizar la comodidad del usuario final: este es el objetivo que los desarrolladores se han fijado. Esto es evidente en la mejora de las interfaces de usuario (UI) y la calidad de la experiencia del usuario (UX) de muchas aplicaciones empresariales. 

Una persona se acostumbra a la comodidad en todo lo que se relaciona con las herramientas digitales en la vida cotidiana, y hace las mismas demandas sobre las herramientas que utiliza para las tareas laborales. La gente espera de las aplicaciones corporativas la misma visibilidad, intuición, simplicidad y transparencia que tienen a su disposición en servicios financieros, llamadas de taxi o compras en línea. Los profesionales de TI que implementan soluciones en el entorno corporativo también buscan obtener todas las "ventajas" modernas: implementación y escalamiento simples, tolerancia a fallas y opciones de personalización ilimitadas. 

Los principales vendedores internacionales a menudo pasan por alto estas tendencias. Con base en sus muchos años de autoridad en la industria, las corporaciones que trabajan con clientes a menudo son categóricas e inflexibles. La ilusión de su propia indispensabilidad no les permite ver cómo las empresas tecnológicas jóvenes aparecen literalmente ante sus narices, ofreciendo soluciones alternativas adaptadas a un cliente específico y sin pagar de más por la marca.

Desventajas del antiguo sistema BMS 


La principal desventaja de la solución BMS obsoleta existente para nosotros fue su trabajo lento. La investigación de varios eventos relacionados con la reacción insuficientemente rápida del personal de servicio nos ayudó a comprender que a veces los eventos se mostraban en el sistema BMS con un largo retraso. Al mismo tiempo, el sistema no estaba sobrecargado o defectuoso, solo las versiones de sus componentes (por ejemplo, JAVA) estaban desactualizadas y no podían funcionar correctamente con nuevas versiones de sistemas operativos sin actualizaciones. Era posible actualizarlos solo junto con el sistema BMS, mientras que el proveedor no garantizaba la continuidad automática de la versión, es decir, para nosotros el proceso sería casi tan laborioso como la transición a un nuevo sistema, y ​​la nueva solución retendría algunas de las deficiencias del antiguo.  

Agregamos aquí algunas "cositas" más desagradables:

  1. « IP- – »; 
  2. ( BMS);

  3. «» , ;
  4. «» , . – ;
  5. «» , , ;
  6. - , , - ;
  7. – -«» . – ;

    :



  8. – , , ; 
  9. - (, );
  10. - BMS . 


BMS


Dado lo anterior, nuestros principales requisitos son los siguientes:

  1. Dos máquinas independientes de reserva mutua con sincronización automática, que se ejecutan en dos plataformas de nube diferentes en diferentes centros de datos (en nuestro caso, centros de datos Linxdatacenter St. Petersburg y Moscú);
  2. Agregue nuevos dispositivos de forma gratuita;
  3. Actualización gratuita de software y sus componentes (con la excepción de mejoras funcionales);
  4. Código fuente abierto que nos permite soportar independientemente el sistema en caso de problemas del lado del desarrollador;
  5. La capacidad de recibir y usar datos de BMS, por ejemplo en el sitio web o en su cuenta personal;
  6. Acceso a través de un navegador WEB sin un cliente "grueso";
  7. Usar cuentas de usuario de dominio para acceder al BMS;
  8. La presencia de animación y muchos más pequeños y no muy deseos que se materializaron en una declaración detallada de trabajo.


Último intento




En ese momento, cuando nos dimos cuenta de que el centro de datos había superado su BMS, la solución más obvia era actualizar el sistema existente. "No cambian caballos en el cruce", ¿verdad? 

Sin embargo, las grandes corporaciones, por regla general, no ofrecen una modificación personalizada de sus décadas de soluciones "pulidas" que se venden en docenas de países. Mientras que las compañías jóvenes están probando la idea o el prototipo de un producto futuro para consumidores potenciales y confiando en las revisiones de los usuarios en el desarrollo de productos, las corporaciones continúan vendiendo licencias para un producto que alguna vez fue genial, pero, por desgracia, desactualizado y no flexible.

Y sentimos la diferencia de enfoque en nosotros mismos. En el curso de la correspondencia con el fabricante del antiguo BMS, rápidamente se hizo evidente que la actualización del sistema existente por parte del vendedor de hecho nos llevaría a comprar un nuevo sistema con una transferencia semiautomática de la base, altos costos y dificultades durante la transferencia, que incluso el propio fabricante no pudo predecir. Por supuesto, en este caso, el costo del soporte técnico de la solución actualizada creció y quedó la necesidad de comprar licencias para la expansión.

Y la peor parte es que el nuevo sistema no pudo satisfacer completamente nuestros requisitos de redundancia. El sistema BMS actualizado podría implementarse, como quisiéramos, en una plataforma en la nube, lo que nos permitiría abandonar el hardware, pero la opción de reserva no estaba incluida en el precio. Para hacer una copia de seguridad de los datos, tendríamos que comprar un segundo servidor BMS virtual y un conjunto adicional de licencias. Con un costo de una licencia de aproximadamente $ 76 y el número de direcciones IP de 1,000 unidades, se acumulan $ 76,000 de gastos adicionales solo para las licencias de la máquina de respaldo. 

La "cereza" en la nueva versión de BMS fue la necesidad de comprar licencias adicionales "para todos los dispositivos", incluso para el servidor principal. Aquí es necesario aclarar que hay dispositivos conectados al BMS a través de puertas de enlace. La puerta de enlace tiene una dirección IP, pero controla varios dispositivos (en promedio 10). En el antiguo BMS, esto requería una licencia para la dirección IP de la puerta de enlace, las estadísticas se veían así: "Direcciones IP / licencias 1000, dispositivos 1200". El BMS actualizado funcionaba según un principio diferente y las estadísticas se verían como "direcciones IP 1000, dispositivos / licencias 1200". Es decir, el proveedor en la nueva versión cambió el principio de asignación de licencias, y tuvimos que comprar aproximadamente 200 licencias adicionales. 

El presupuesto de la "actualización" como resultado consistió en cuatro puntos: 

  • el costo de la versión en la nube y sus servicios de migración; 
  • licencias adicionales al paquete existente para dispositivos conectados a través de puertas de enlace;
  • costo de la versión de respaldo de la nube;  
  • conjunto de licencias para la máquina de respaldo. 

¡El costo total del proyecto fue de más de $ 100,000! Y esto sin mencionar la necesidad de comprar licencias para nuevos dispositivos en el futuro.

Como resultado, nos dimos cuenta de que sería más fácil para nosotros, y quizás más barato, pedir un sistema creado desde cero, teniendo en cuenta todos nuestros requisitos y brindando la posibilidad de modernización en el futuro. Pero aquellos que querían desarrollar un sistema tan complejo todavía tenían que encontrar, comparar propuestas, elegir e ir con el finalista desde TK hasta la implementación ... Lea sobre esto en la segunda parte del material muy pronto. 

All Articles