CMDB4 min readEquipo de Eywo

La red virtual en la CMDB: del grupo de puertos al switch leaf

Entre una máquina virtual y la red física se encuentra una capa que la mayoría de las CMDB no ven: conmutadores virtuales, grupos de puertos y enlaces ascendentes de host. Sin embargo, aquí es precisamente donde se decide qué servicios afectará un cambio en la red.

El equipo de red está planeando mover un grupo de puertos a un nuevo conmutador distribuido. En papel, es un cambio de configuración rutinario en vCenter. En la práctica, alguien del equipo de operaciones pregunta: “¿Qué aplicaciones se ejecutan en ese grupo de puertos?” El administrador de virtualización abre la consola y comienza a revisar las máquinas virtuales. El ingeniero de redes determina qué enlaces ascendentes y conmutadores de acceso llevan el tráfico. Los propietarios de los servicios se enteran del cambio cuando algo deja de responder.

Por qué la red virtual suele estar ausente de la CMDB

Una CMDB clásica registra servidores, aplicaciones y dispositivos de red físicos. La red virtual se encuentra entre ellos y cambia con frecuencia: los grupos de puertos aparecen con nuevos proyectos, las VLAN se reagrupan, los hosts obtienen nuevos enlaces ascendentes. Los registros manuales no pueden mantenerse al día con dicha capa, y el descubrimiento automático a menudo la almacena solo como un atributo de una máquina virtual en lugar de como un elemento en sí mismo, con relaciones.

El resultado es una brecha en el mapa de dependencias. El impacto de un cambio se calcula en los servidores, pero no en la red que los conecta. Y los cambios de red son aquellos que afectan a más servicios a la vez.

Cómo lo maneja Stilla

En Stilla, los conmutadores virtuales y los grupos de puertos son elementos de la CMDB en sí mismos, con sus relaciones:

  • Conmutadores virtuales – distribuidos y estándar, vinculados a los hosts que los utilizan.
  • Grupos de puertos y VLAN – qué conmutador están en, qué VLAN transportan y qué máquinas virtuales y adaptadores VMkernel están conectados a ellos.
  • Enlaces ascendentes de host – qué tarjetas de red físicas transportan el tráfico y a qué conmutadores de acceso.

El mapa de dependencias, por lo tanto, se ejecuta sin interrupción desde el servicio de negocio a través de la aplicación y la máquina virtual hasta el grupo de puertos, el enlace ascendente y el conmutador físico. El cálculo de impacto para un cambio o una interrupción utiliza el mismo gráfico que todo lo demás en el producto – incidencias, cambios, planes de aplicación de parches y situaciones de monitorización.

Los discos pertenecen al servidor, los discos compartidos son elementos propios

Organizamos el almacenamiento de la misma manera. Los discos de una máquina virtual se registran en el inventario del servidor, donde naturalmente pertenecen, y durante el descubrimiento se vinculan automáticamente al datastore en el que se encuentran. Solo un disco con vida propia es un elemento de CMDB separado: un disco compartido de un clúster o un disco RDM asignado directamente desde la matriz. Esto evita que el mapa crezca con miles de elementos sin valor informativo, mientras se muestra qué servidores y servicios dependen de un datastore o LUN específico.

La comprobación de calidad de datos “Discos y almacenamiento” señala inconsistencias – por ejemplo, un disco sin vínculo a un datastore o un disco compartido que solo un nodo del clúster puede ver.

Qué significa esto para las operaciones

La próxima vez que el equipo de red planee mover un grupo de puertos, crearán un cambio y, antes de que se apruebe, Stilla muestra:

  • qué máquinas virtuales y adaptadores VMkernel dependen del grupo de puertos,
  • qué enlaces ascendentes y conmutadores de acceso transportan el tráfico,
  • qué aplicaciones y servicios de negocio se verán afectados y si la redundancia los protege,
  • qué propietarios de servicios se ven afectados por la interrupción y cuándo están disponibles sus ventanas de mantenimiento.

Los propietarios de los servicios aprueban la interrupción con el impacto concreto en mano, no con un aviso genérico de “mantenimiento de red”. Y si algo sale mal después del cambio, las situaciones de monitorización se coinciden con el cambio que probablemente las causó, gracias a la misma topología.

Cómo obtener los datos en la CMDB

La red virtual se puede cargar en Stilla a través de la API de descubrimiento – incluyendo coincidencia con elementos existentes, sincronización completa y retiro de lo que ya no existe en vCenter – o importando archivos CSV y Excel. Un conector que recopilará los datos de vCenter automáticamente está en preparación.

Un mapa que termina en el servidor solo responde a la mitad de la pregunta. Un mapa que se ejecuta hasta el conmutador físico le permite planificar cambios de red con tranquilidad.

Stilla Standard
Para organizaciones que desean una CMDB fiable y procesos de ITSM gestionados.

Comparar ediciones →