161 lines
7.3 KiB
Markdown
161 lines
7.3 KiB
Markdown
# Decision: Herramienta de inventario para infraestructura Proxmox/PBS
|
|
|
|
## Contexto
|
|
- 100-500 servidores Proxmox VE y PBS
|
|
- Necesidad de saber que hay, donde esta, que IP tiene, que version corre, que clientes tiene cada PBS
|
|
- Integracion con Ansible para automatizacion
|
|
|
|
---
|
|
|
|
## Opcion A: Netbox solo (CMDB pura)
|
|
|
|
**Que es**: CMDB (Configuration Management Database) open source de referencia. Diseñada por ingenieros de red de DigitalOcean.
|
|
|
|
**Que cubre**:
|
|
- Inventario de servidores fisicos (rack, U, serial, modelo)
|
|
- IPs y subredes (IPAM completo: VLANs, prefijos, rangos)
|
|
- VMs y contenedores
|
|
- Conexiones de red (que puerto fisico va a donde)
|
|
- Contactos y tenants (clientes asociados a cada recurso)
|
|
- Custom fields (quota PBS, tamaño comercial, servidor de sync, etc.)
|
|
- API REST completa (todo automatizable)
|
|
|
|
**Que NO cubre sin plugins**:
|
|
- No descubre automaticamente lo que tienes (hay que poblarlo)
|
|
- No monitoriza estado (es un inventario, no sabe si el servidor esta caido)
|
|
- No gestiona tickets ni incidencias
|
|
|
|
**Plugins clave para vuestro caso**:
|
|
- `netbox-proxmox`: sincroniza VMs, nodos y storage desde Proxmox API
|
|
- `netbox-dns`: gestion de zonas y registros DNS (complementa vuestro PowerDNS)
|
|
- `netbox-inventory`: seguimiento de activos fisicos con ciclo de vida
|
|
|
|
**Como se pobla**:
|
|
- Manual al principio (servidores fisicos, racks)
|
|
- Automatico via API + scripts que lean de Proxmox y PBS
|
|
- Ansible como consumidor: `netbox.netbox.nb_inventory` genera inventario dinamico
|
|
|
|
**Ideal si**: quereis una fuente de verdad unica, bien estructurada, que alimente al resto de herramientas (Ansible, Prometheus, Grafana). El equipo tiene disciplina para mantenerla actualizada.
|
|
|
|
**Recursos**: 2GB RAM, 1 vCPU, PostgreSQL + Redis. Una VM pequeña.
|
|
|
|
**Veredicto**: Para vuestro caso, **Netbox solo es suficiente** como inventario si le añadis el plugin de Proxmox y lo conectais con Ansible. Es la opcion mas limpia.
|
|
|
|
---
|
|
|
|
## Opcion B: GLPI + FusionInventory (inventario + autodiscovery + ticketing)
|
|
|
|
**Que es**: Gestion de activos IT + helpdesk + autodescubrimiento. Muy extendido en entornos ITIL.
|
|
|
|
**Que cubre**:
|
|
- Todo lo de inventario (servidores, VMs, IPs, software instalado)
|
|
- Autodescubrimiento: instala un agente en cada servidor y reporta automaticamente hardware, software, paquetes, actualizaciones
|
|
- Ticketing integrado (incidencias, peticiones, cambios)
|
|
- Gestion de contratos y proveedores (util para controlar hosting OVH, licencias)
|
|
- Base de conocimiento (wiki interna)
|
|
- SLA tracking
|
|
|
|
**Que NO cubre**:
|
|
- IPAM menos potente que Netbox
|
|
- No tiene concepto nativo de "tenant/cliente" tan limpio como Netbox
|
|
- Integracion con Ansible menos directa (existe pero no es nativa)
|
|
|
|
**Ventaja diferencial**: el agente FusionInventory escanea automaticamente cada servidor y reporta: hardware, paquetes instalados, versiones, discos, red. No tienes que mantener el inventario a mano, se actualiza solo.
|
|
|
|
**Ideal si**: quereis que el inventario se mantenga solo (autodiscovery), necesitais ticketing integrado, y el equipo prefiere una herramienta "todo en uno" tipo helpdesk.
|
|
|
|
**Recursos**: 2GB RAM, 1 vCPU, MariaDB + Apache. Una VM pequeña.
|
|
|
|
**Veredicto**: Mas facil de mantener actualizado que Netbox (autodiscovery), pero menos potente como CMDB de red y menos integracion con ecosistema DevOps.
|
|
|
|
---
|
|
|
|
## Opcion C: Netbox + Ansible inventory + Prometheus service discovery (stack integrado)
|
|
|
|
**Que es**: No es una herramienta sino un patron. Netbox como SSOT, Ansible como consumidor y actualizador, Prometheus como validador.
|
|
|
|
**Flujo**:
|
|
```
|
|
Netbox (SSOT) --> Ansible (dynamic inventory) --> Configura servidores
|
|
^ |
|
|
| v
|
|
+---- Script sync <-- Proxmox API (autodescubre VMs nuevas)
|
|
|
|
|
+---- Prometheus (valida que lo que dice Netbox coincide con la realidad)
|
|
```
|
|
|
|
**Componentes**:
|
|
1. **Netbox**: inventario maestro con plugin proxmox
|
|
2. **Script de sync** (cron diario): consulta la API de cada Proxmox, crea/actualiza VMs en Netbox automaticamente
|
|
3. **Ansible `netbox.netbox.nb_inventory`**: genera inventario dinamico desde Netbox. Los playbooks siempre trabajan contra datos reales.
|
|
4. **Prometheus + netbox-prometheus-sd**: Prometheus descubre targets desde Netbox. Si un servidor esta en Netbox, se monitoriza automaticamente.
|
|
|
|
**Que cubre**:
|
|
- Todo lo de Netbox (Opcion A)
|
|
- Autodescubrimiento via API de Proxmox (no necesita agente como GLPI)
|
|
- Inventario siempre sincronizado con la realidad
|
|
- Monitoring automatico de todo lo que entra en inventario
|
|
- Ansible siempre trabaja con datos actualizados
|
|
|
|
**Que requiere**:
|
|
- Mas trabajo inicial de integracion (scripts de sync, configurar plugins)
|
|
- El equipo tiene que entender el flujo completo
|
|
- Necesita Prometheus y Grafana (que ya deberian desplegarse de todos modos)
|
|
|
|
**Ideal si**: quereis construir un ecosistema integrado donde añadir un servidor a Netbox automaticamente lo provisione con Ansible y lo monitorice con Prometheus. La opcion mas potente a largo plazo.
|
|
|
|
**Recursos**: Netbox VM (2GB) + Prometheus/Grafana (ya necesario para monitoring).
|
|
|
|
**Veredicto**: Mas esfuerzo inicial, pero es el objetivo final al que llegareis con cualquiera de las otras opciones. Si vais a desplegar Prometheus y Ansible de todos modos, tiene sentido empezar con este enfoque.
|
|
|
|
---
|
|
|
|
## Comparativa rapida
|
|
|
|
| Criterio | A: Netbox solo | B: GLPI+Fusion | C: Netbox+stack |
|
|
|----------|---------------|----------------|-----------------|
|
|
| Esfuerzo inicial | Medio | Bajo | Alto |
|
|
| Mantenimiento | Manual + API | Automatico (agente) | Automatico (API) |
|
|
| IPAM (gestion IPs) | Excelente | Basico | Excelente |
|
|
| Autodiscovery | Con plugin/script | Nativo (agente) | Con script |
|
|
| Ticketing | No (necesita otra tool) | Integrado | No |
|
|
| Integracion Ansible | Nativa | Plugin | Nativa |
|
|
| Integracion Prometheus | Plugin | No directa | Nativa |
|
|
| Tenants/clientes | Excelente | Basico | Excelente |
|
|
| Curva de aprendizaje | Media | Baja | Alta |
|
|
| Comunidad Proxmox | Fuerte | Media | Fuerte |
|
|
| Escalabilidad | 10000+ | 5000 | 10000+ |
|
|
|
|
---
|
|
|
|
## Mi recomendacion para vuestro caso
|
|
|
|
**Opcion C**, pero implementada en fases:
|
|
|
|
1. **Semana 1-2**: Desplegar Netbox con plugin proxmox. Importar servidores fisicos y que sincronice VMs automaticamente.
|
|
2. **Semana 3-4**: Conectar Ansible con inventario dinamico de Netbox. Primer playbook de hardening base.
|
|
3. **Mes 2**: Añadir script de sync PBS (datastores, clientes, quotas como custom fields en Netbox).
|
|
4. **Mes 2-3**: Conectar Prometheus con Netbox para service discovery automatico.
|
|
|
|
Resultado: cualquier servidor nuevo que se añada a Proxmox aparece en Netbox automaticamente, se configura con Ansible, y se monitoriza con Prometheus. Sin intervencion manual.
|
|
|
|
---
|
|
|
|
## Nota sobre datos especificos de PBS que modelar en Netbox
|
|
|
|
Custom fields recomendados para vuestro modelo de negocio:
|
|
|
|
| Campo | Tipo | Ejemplo |
|
|
|-------|------|---------|
|
|
| `pbs_commercial_size_gb` | Integer | 100 |
|
|
| `pbs_quota_gb` | Integer | 600 |
|
|
| `pbs_reservation_gb` | Integer | 500 |
|
|
| `pbs_sync_server` | Text | pbs3343.vpn9.com.es |
|
|
| `pbs_sync_day` | Integer | 15 |
|
|
| `pbs_password` | Secret (via Vault) | - |
|
|
| `pbs_pve_host` | Text | ns31157129.ip-51-91-154.eu |
|
|
| `pbs_status` | Choice | active / migrated / suspended |
|
|
| `pbs_last_gc` | DateTime | auto-updated |
|
|
| `pbs_last_verify` | DateTime | auto-updated |
|
|
| `pbs_used_space_gb` | Integer | auto-updated |
|