Cómo una CMDB conecta servidores, GPU, contenedores, servicios y propietarios

Una CMDB puede conectar servidores, GPU, contenedores, aplicaciones, servicios de negocio y propietarios si trata cada elemento como un ítem de configuración o un objeto operativo vinculado, manteniendo relaciones tipadas entre ellos. Su valor real surge al conservar esas relaciones lo bastante actualizadas como para responder dudas operativas; una lista estática de activos apenas aporta utilidad en ese sentido.

Una cadena de relaciones útil puede organizarse así: el rack contiene el servidor, el servidor aloja la GPU, el clúster incluye el nodo, la carga de trabajo corre en un contenedor, el contenedor consume la GPU, la aplicación depende del servicio, el servicio pertenece al proyecto y el proyecto tiene un propietario asignado. Cuando existen estos vínculos, una sola alarma de hardware se puede rastrear hacia arriba para medir el impacto en el negocio y hacia los lados para identificar a la persona responsable de actuar.

¿Para qué sirve realmente una CMDB?

El propósito de una CMDB es representar la configuración de un entorno de TI y las relaciones que hacen posible el funcionamiento de los servicios. ServiceNow define su CMDB como un método para construir representaciones lógicas de activos, servicios y los lazos existentes entre ellos, y ese foco en las dependencias es lo que más importa en las operaciones actuales.

Un inventario estático responde a la pregunta: "¿Cuántos servidores tenemos?". Una CMDB consciente de las relaciones responde a: "¿Qué servicio corre en este servidor, qué contenedor usa esta GPU, qué proyecto es dueño de la carga de trabajo y quién debe recibir la notificación del incidente?". Estas respuestas se sitúan en niveles de valor operativo muy distintos.

El modelo operativo de referencia emplea cinco grandes dimensiones por este motivo: personas, activos, actividades, cómputo y negocio. Las categorías en sí importan menos que el principio fundamental: los recursos físicos, los recursos lógicos, las tareas, la responsabilidad y el consumo del negocio deben estar conectados.

Para la parte de inventario automatizado, cómo los centros de datos pueden descubrir y mantener inventarios precisos de hardware de forma automática explica cómo se mantienen al día los registros subyacentes.

¿Qué objetos conviene modelar?

Conviene modelar los objetos que influyen en las decisiones de operación. En la infraestructura física, esto suele abarcar centros de datos, racks, servidores, equipos de red, cabinas de almacenamiento, sistemas de alimentación y unidades de refrigeración. En cómputo, incluye tarjetas aceleradoras físicas cuando el estado y la asignación individual de cada tarjeta resultan relevantes. En la capa de plataforma, incluye clústeres, nodos, máquinas virtuales, contenedores, espacios de nombres y grupos de recursos según corresponda.

Para las aplicaciones, incorpora servicios de aplicación, servicios de modelos, bases de datos, middleware, API y sistemas de negocio donde sean necesarios para el análisis de impacto. En personas y gobernanza, incluye propietarios responsables, equipos, inquilinos, proyectos, proveedores y contratos de mantenimiento. En actividades, refleja alarmas, órdenes de trabajo, cambios, despliegues, inspecciones y tareas de envergadura donde la relación con la infraestructura sea crítica.

No crees ítems de configuración para cada campo o métrica. Una CMDB no es una base de datos de series temporales: la temperatura, el porcentaje de uso o la latencia corresponden a las herramientas de monitoreo. La CMDB debe identificar el objeto y sus dependencias para que los datos de monitoreo puedan interpretarse en su contexto adecuado.

¿Cómo modelar un servidor físico y sus GPU?

Trata el servidor y cada acelerador como objetos independientes cuando el estado individual de la tarjeta o su asignación en la planificación sean determinantes. El registro del servidor debe contener datos de identidad como fabricante, modelo, número de serie, dirección de gestión, ubicación física, línea base de firmware y estado en su ciclo de vida. Cada registro de GPU o NPU puede incluir fabricante, modelo, número de serie o identificador del dispositivo si está disponible, ranura o bus, capacidad de memoria, versión de firmware o driver asociado y estado de salud. Después, define una relación como: el servidor contiene el acelerador.

Esto permite realizar operaciones a nivel de tarjeta individual. Si una tarjeta notifica un error de memoria no corregible, la plataforma puede identificar el servidor anfitrión sin tratar al servidor completo como el único objeto existente. También puede diferenciar un servidor con ocho tarjetas sanas de otro con siete tarjetas sanas y una degradada. Esta relación gana aún más utilidad en cuanto se vincula con el sistema de planificación de tareas.

Para profundizar en cómo normalizar objetos de aceleración entre distintos fabricantes, puedes leer cómo gestionar GPU y NPU multillave.

¿Cómo se conectan los contenedores a las GPU?

Los contenedores se conectan a las GPU a través de los datos de asignación en tiempo de ejecución y del planificador. La tarjeta física se conoce mediante el descubrimiento de hardware, y el nodo se identifica en el inventario del clúster. Kubernetes u otro orquestador sabe qué carga de trabajo se asignó al nodo y qué recurso de dispositivo se le otorgó. La CMDB o el servicio de relaciones combina estas fuentes en una asignación activa.

El reto reside en que esta relación cambia con frecuencia. Un contenedor puede destruirse y volver a crearse, una carga puede migrar a otro nodo, una reserva de GPU puede liberarse y un nodo puede drenarse. Por tanto, las relaciones entre contenedores y GPU no pueden sostenerse a mano. Requieren sincronización guiada por eventos o sondeos frecuentes desde el planificador y el estado del clúster.

Conserva el historial en los casos donde ayude a investigar incidencias. Durante un análisis post-incidente, quizá necesites saber qué contenedor ocupaba una tarjeta a las 12:06, incluso si ese contenedor ya no existe en el sistema.

¿Cómo se vinculan aplicaciones y servicios a los contenedores?

Las aplicaciones y los servicios de negocio se conectan mediante metadatos de despliegue, descubrimiento de servicios, topología de ejecución y reglas claras de propiedad. Un contenedor puede pertenecer a un Deployment o StatefulSet de Kubernetes, y esa carga de trabajo puede formar parte de un espacio de nombres, aplicación, servicio de modelo o proyecto. Un endpoint de inferencia o una API se pueden asociar al servicio que los expone, y el servicio se puede vincular a una aplicación empresarial o a un departamento corporativo.

Ciertas dependencias se detectan automáticamente, mientras que otras requieren metadatos explícitos. La propiedad de negocio es un caso claro. Un escáner no siempre puede deducir el responsable de una aplicación analizando solo el tráfico de red, por lo que ese dato debe provenir de un registro de proyecto, un catálogo de servicios, metadatos del repositorio de código o un campo manual verificado.

Por esta razón, las fuentes automáticas y manuales necesitan reglas de autoridad bien definidas. Si la automatización detecta que una carga de trabajo se trasladó a otro nodo, debe ser la automatización quien actualice ese vínculo. Si el departamento de finanzas reasigna el proyecto a otro centro de coste, el registro empresarial autorizado debe ser la fuente prioritaria.

¿Qué tipos de relación debe usar una CMDB?

Utiliza tipos de relación que transmitan significado operativo real, como contiene, aloja, ejecuta en, depende de, conectado a, alimentado por, refrigerado por, propiedad de o consumido por. Evita usar un enlace genérico como "relacionado con" para todo, porque la propagación del impacto depende del sentido y del significado del vínculo.

Si la aplicación A depende de la base de datos B, un fallo en la base de datos afecta a la aplicación. Si el rack R contiene el servidor S, una avería en el servidor no implica que el rack entero haya fallado. Si el servidor S recibe energía del circuito de PDU P, un corte en ese circuito dejará sin servicio al servidor. Las relaciones tipadas permiten a la plataforma razonar sobre estas diferencias con criterio.

También aportan mucha mayor precisión a las consultas. Un operador puede preguntar: "Muestra todos los servicios de negocio que dependen de nodos refrigerados por esta CDU", o bien: "Identifica al propietario de cada carga de trabajo vinculada a esta GPU en este momento".

¿Cómo mantener precisas las relaciones?

Mantén la precisión de las relaciones combinando descubrimiento automático, sincronización de eventos, flujos de trabajo de cambio e histórico temporal. El descubrimiento automático es idóneo para los datos que las máquinas registran de forma directa: números de serie, modelos de dispositivo, direcciones IP, posición en rack cuando está monitorizada, pertenencia al clúster, estado de los contenedores y asignaciones del planificador. Los flujos de cambio se adaptan a acciones controladas como mover equipamiento, transferir la propiedad, modificar cuotas o retirar un equipo. La sincronización de eventos gestiona relaciones muy dinámicas como Pods y reservas de contenedores, mientras que las instantáneas ayudan a reconstruir el pasado.

La exactitud también exige reglas claras de resolución de conflictos. Supongamos que la CMDB indica que un servidor está en el rack A, pero el sistema de escaneo lo sitúa en el rack B. No sobrescribas el conflicto sin determinar antes qué fuente tiene prioridad. La plataforma debe señalar la discrepancia, aplicar una jerarquía de fuentes predefinida o generar una tarea de conciliación. Una CMDB fiable declara con transparencia de dónde procede cada dato.

¿Cómo ayuda una CMDB en el análisis de impacto?

Una CMDB apoya el análisis de impacto transformando un fallo de bajo nivel en una ruta de dependencias fácil de recorrer. Imagina que un acelerador notifica un error grave de memoria. El análisis descendente permite revisar la tarjeta física, el servidor, el histórico de temperaturas, el firmware y los eventos de hardware relacionados. El análisis ascendente sigue la asignación activa hasta el contenedor, y de ahí a la instancia de inferencia, el servicio de modelo, la aplicación, el proyecto y el departamento de negocio. El análisis horizontal localiza al propietario directo, al equipo de operaciones, al fabricante, al contrato de mantenimiento y a la orden de trabajo en curso.

El reporte de incidencia resultante es mucho más completo. En lugar de una alerta genérica como "error de GPU en nodo 17", puede indicar: "Esta tarjeta da soporte a dos instancias de inferencia. Hay un servicio de negocio degradado. El proyecto X es dueño del servicio. El equipo Y es el responsable operativo. La tarjeta cuenta con contrato de mantenimiento Z vigente". Ese es el beneficio práctico de disponer de datos de relación estructurados.

¿Cómo ayuda una CMDB en la planificación?

Una CMDB puede aportar un contexto operativo que el planificador de tareas no recopila por sí mismo. El orquestador conoce la disponibilidad de recursos y la ubicación de las cargas, mientras que la CMDB puede añadir información física y operativa como el dominio de fallo, el rack, la línea de alimentación eléctrica, la zona de refrigeración, el estado de mantenimiento planificado, la propiedad de negocio y el estado de salud del hardware.

Por ejemplo, un planificador puede considerar que dos nodos están igualmente libres, mientras que la CMDB refleja que uno de ellos tiene una ventana de mantenimiento programada o está en un rack con una advertencia activa de refrigeración. Que el orquestador aplique esos datos de forma directa depende de la arquitectura, pero contar con la base de relaciones pone ese contexto a su alcance. Esto resulta valioso en infraestructuras de IA, donde la salud a nivel de tarjeta y la topología física condicionan entrenamientos de larga duración.

¿Cómo ayuda una CMDB en el reparto de costes?

Una CMDB facilita el reparto de costes vinculando el consumo de recursos con proyectos, inquilinos, aplicaciones y responsables. Las métricas de uso pueden indicar que una GPU estuvo reservada durante 10 horas, y el modelo de relaciones especifica qué proyecto fue dueño de la carga a lo largo de esas 10 horas. La telemetría de una API puede registrar cuántas peticiones a modelos o tokens se consumieron, y el grafo de dependencias asocia esas llamadas a una clave, un servicio, un proyecto, un cliente y un equipo responsable.

Sin esta red de relaciones, las herramientas de costes pueden calcular importes totales pero no logran justificar a quién corresponden. Por esa razón, el inventario, la planificación, la pasarela de servicios y la medición de consumo deben compartir los mismos identificadores.

¿Es una CMDB lo mismo que la gestión de activos?

No. La gestión de activos y la CMDB se solapan, pero responden a preguntas diferentes. La gestión de activos se concentra sobre todo en la propiedad, las compras, el ciclo de vida financiero, las garantías, la ubicación física y la retirada de equipos. La CMDB se centra en la configuración y las relaciones necesarias para mantener los servicios en funcionamiento.

Un mismo servidor físico coexiste en ambas perspectivas. El registro de activo se ocupa de la fecha de adquisición y la amortización, mientras que el registro de configuración se interesa por el clúster al que pertenece el servidor, qué servicios dependen de él y qué impacto causará si se apaga. Ambos registros deben estar vinculados, pero no tienen que ser idénticos.

La comparativa detallada entre estas categorías se aborda en cuál es la diferencia entre CMDB, DCIM, ITOM, AIOps y plataformas de gestión cloud.

¿Cuál es el modelo mínimo útil para una CMDB?

Empieza por identidad, ubicación, dependencia, propiedad e historial de cambios. En un entorno de cómputo moderno, deberías poder trazar una ruta desde la ubicación física hasta el servidor, el acelerador, el nodo del clúster, la carga de trabajo, la aplicación o servicio, el proyecto y, por último, el propietario.

No necesitas representar todas las relaciones imaginables desde el primer día. Un modelo de dependencias contenido y riguroso resulta más útil que uno inmenso en el que nadie confía. Un ejemplo de plataforma diseñada sobre este principio de relaciones compartidas es Sensaka.

Si tuviera que implementar esto desde cero, elegiría tres preguntas operativas prioritarias, como el impacto en el negocio de una avería de hardware, la propiedad de los recursos y la atribución de costes. Modelaría únicamente las relaciones necesarias para responder con fiabilidad a esas tres dudas, y solo después ampliaría el alcance cuando esa base demuestre ser sólida.