Device42: el inventario de racks y equipos de la sala de comunicaciones de una sede con sala de trading

Qué vas a conseguir

Que la sala de comunicaciones esté en Device42 tal como está de verdad: cada equipo en su rack y su U, con su modelo, su número de serie, quién es el responsable, a qué PDU está enchufado, qué puertos del panel de parcheo salen de él y hasta cuándo tiene garantía y soporte del fabricante. En una sede con sala de trading eso no es documentación para una auditoría: es lo que permite cambiar un switch antes de la apertura del mercado sin buscar nada.

Antes de empezar

• Acceso a Device42 con un usuario con permisos de edición en la sede, y otro de solo lectura para las exportaciones.
• El plano de la sala: filas, racks, cuadros eléctricos y por dónde entra cada circuito.
• Las credenciales de descubrimiento: una comunidad SNMP de solo lectura (mejor SNMPv3) para los equipos de red y una cuenta dedicada para los servidores, nunca la de un administrador.
• Los pedidos y contratos de soporte de los equipos (fabricante, número de contrato, fecha de fin).

1. Edificios, salas y racks: el esqueleto

En Device42 todo cuelga de la jerarquía edificio → sala → rack. Créala antes de dar de alta un solo equipo:

• El modelo de hardware (la plantilla) define el tamaño en U y la profundidad. Sin un modelo con tamaño, el equipo no se puede colocar en el rack: quedará a un lado.
• Usa Find next slot para buscar hueco y la vista Rack Layout para comprobar delante y detrás. Mover un equipo de rack quita sus conexiones de red y de alimentación: revísalas después.
• Nombres coherentes con la etiqueta física: lo que pone el equipo es lo que pone Device42.

2. Descubrir o dar de alta a mano

El descubrimiento automático rellena lo que el equipo sabe de sí mismo; lo físico lo sabe quien está en la sala.

• Red (switches, routers, cortafuegos): descubrimiento SNMP. Trae inventario, VLAN y subredes, y la tabla de MAC por puerto del switch.
• Windows: WMI (y WinRM para Hyper-V). Linux: SSH. VMware: a través de vCenter.
• iDRAC e iLO: descubrimiento IPMI de las controladoras de los servidores.
• Si la sala de trading está en un segmento aislado, un Remote Collector dentro de ese segmento hace los trabajos sin abrir la red entera al appliance.
• Programa cada trabajo (semanal basta para inventario) y revisa los errores: una credencial caducada deja el inventario congelado sin avisar.

Lo que ningún descubrimiento sabe y se da de alta a mano: el rack y la U, el responsable, los paneles de parcheo, la toma de la PDU y la fecha de fin de soporte si tu Device42 no la tiene para ese modelo.

Descubrimiento primero y mano después: si das de alta a mano y luego descubres, acabarás con duplicados que solo se distinguen por el número de serie.

3. Tipos de equipo, alimentación y parcheo

Cada equipo con su tipo y su responsable (customer en Device42: Red, Infraestructura, Tecnología de Trading). Lo que una sala de sede suele tener:

• Switches de núcleo y de acceso, routers y cortafuegos.
• Servidores de la sede: virtualización, ficheros, el servidor de datos de mercado que mantiene el equipo de trading.
• PDU: se dan de alta como Power Unit con su modelo; los puertos se crean a partir del modelo al guardar, así que elige bien el modelo antes. Enlaza la PDU con un dispositivo para tener su número de serie, compra y ciclo de vida.
• SAI (UPS): también como Power Unit. Apunta la fecha de la última sustitución de baterías.
• Paneles de parcheo: con sus puertos y lo que conecta cada uno (puerto del switch → puerto del panel → toma del puesto).

En una sala de trading cada equipo crítico tiene dos fuentes a dos PDU distintas (alimentación A y B). Si Device42 tiene las dos tomas, comprobar que una intervención en la PDU A no deja nada sin corriente es una consulta, no una visita.

4. Garantía y fin de soporte

Dos fechas distintas que se confunden a menudo:

• Fin de garantía o de contrato de soporte: lo que pagas al fabricante o al integrador. Se renueva o se deja caer.
• Fin de soporte del fabricante (last date of support): a partir de ahí no hay correcciones ni parches de seguridad, pagues lo que pagues.

• Revisa cada mes lo que vence en los próximos 90 días: el equipo de núcleo primero.
• Las fechas de fin de soporte salen de los avisos de fin de vida del fabricante. Si no están en Device42 para ese modelo, anótalas en un campo personalizado.

5. La exportación que lo mantiene honesto

Un inventario que nadie contrasta se degrada solo. Una vez al mes, exporta los dispositivos por la API (solo lectura) y busca lo que falta:

›$cred = Get-Credential›$r = Invoke-RestMethod -Uri 'https://device42.corp.example/api/1.0/devices/all/?limit=500&offset=0' -Authentication Basic -Credential $cred›$r.total_count51›$r.Devices | Where-Object { -not $_.rack -or -not $_.start_at } | Select-Object name, hw_model, roomname           hw_model                    room----           --------                    ----mad-pdu-r03b   APC AP8941 Rack PDU         Sala técnica CR-1mad-pp-r04-2   Cat6A 24-port patch panel   Sala técnica CR-1

Pagina con limit y offset hasta llegar a total_count. Lo que conviene sacar cada mes:

• Equipos sin rack o sin U, y equipos sin responsable.
• Equipos de red y servidores sin versión de firmware o de sistema: sin ella no sabes a cuáles afecta un aviso de seguridad.
• Garantías vencidas o que vencen en 90 días, y equipos pasado su fin de soporte.
• Equipos que el descubrimiento no ha visto en semanas: apagados, retirados o fuera de la red.

6. El ticket: "se ha caído un switch de acceso de la sala de trading a las 7:40"

Martes, 7:40. Una fila de puestos de trading sin red. El mercado abre a las 9:00.

1. Qué equipo es: desde el puesto afectado, el panel de parcheo lleva a mad-acc-sw02, rack R03, U36. Nadie tiene que seguir un cable con la linterna.
2. Qué hay alrededor: Device42 muestra sus dos fuentes en mad-pdu-r03a y mad-pdu-r03b. Las dos PDU tienen corriente: no es la alimentación.
3. Hay repuesto: un switch del mismo modelo en R04, marcado como no en servicio. Mismo tamaño, misma configuración de base.
4. Cambio: el técnico va directo a la U36, cambia el equipo, recoloca los latiguillos según los puertos del panel que lista Device42 y carga la configuración guardada. A las 8:25 la fila tiene red.
5. El caso con el fabricante: con el número de serie y el contrato de la ficha se abre la RMA sin buscar el pedido.
6. Después: actualizar Device42 (el equipo averiado pasa a reparación, el repuesto a producción) y anotar en la revisión mensual que el modelo está pasado su fin de soporte: es candidato a sustitución, no a otra reparación.

Si la ficha dice una U y el equipo está en otra, corrígelo ese mismo día. Un inventario que acierta nueve de cada diez veces obliga a comprobarlo todo.

Siguientes pasos

• La guía de Cisco: switches, routers y salas de comunicaciones de una sede cubre la configuración de esos equipos y el acceso de consola.
• La guía de Proveedores de conectividad cubre el inventario de circuitos, que vive al lado de este.
• El siguiente paso es un solo inventario para todo el hardware de la oficina: portátiles, monitores, bases, salas de reuniones e impresoras, junto con la sala de comunicaciones, cruzados por número de serie con Intune, Jamf, las compras y RR. HH. Es la idea del repositorio 38-it-asset-lifecycle-planner de mi GitHub, que además calcula qué toca renovar cada trimestre y cuánto cuesta.

¿Falta algo o en tu entorno es distinto? Escríbeme y lo corrijo.