7caa240c2e
Especificaciones tomadas del manual del propietario del gabinete PowerEdge M1000e (Dell, modelo BMX01, rev. A06, oct. 2019), que corrige el spec sheet comercial usado hasta ahora. Hardware: - Peso máximo 200,5 kg, no 179. Profundidad 75,5 cm - Seis fuentes y nueve ventiladores obligatorios, se usen 3 blades o 16. Toda bahía vacía necesita relleno - Conector CEI/IEC C20 a 16 A. La fuente de 3.000 W exige 200-240 V - Irrupción de 55 A por fuente durante 10 ms: un magnetotérmico de curva C salta, hace falta curva D - Temperatura de funcionamiento continuo 10-35 °C - ECM obligatorio con blades M630 de 120 W o más, o por encima de 30 °C Red: - Fabric A (ranuras A1/A2) es la Ethernet integrada de cada blade, así que no hacen falta tarjetas intermedias. Fabrics B y C sí las exigirían y no se usan - Pendiente saber si en A1/A2 hay un switch o un módulo de paso a través: cambia el montaje de red por completo Costes recalculados: el suelo fijo del chasis sube de 350 a ~500 W al contar los nueve ventiladores, los módulos de I/O y las pérdidas de las seis fuentes. 360 €/mes a 24/7, 59 €/mes por ventanas. Que las fuentes y los ventiladores sean obligatorios convierte en hecho documentado lo que antes era estimación: los pilotos parciales en el chasis son el peor caso posible. Documentación: - assets/ con cuatro diagramas SVG propios: arquitectura, chasis, stack de software y modos de red - docs/usabilidad.md: órdenes, flujos de trabajo, problemas conocidos y ergonomía del hardware - Diagramas ASCII del panel frontal, el posterior y la topología de fabrics en hardware_m1000e.md - Eliminada la parte de charla y divulgación, fuera del alcance del repo
91 lines
3.7 KiB
Markdown
91 lines
3.7 KiB
Markdown
# Guía de trabajo
|
||
|
||
## Estado
|
||
|
||
| Parte | Estado |
|
||
|---|---|
|
||
| Investigación | Cerrada, en `01_investigacion/` |
|
||
| Automatización Ansible | Escrita, sin ejecutar contra hardware |
|
||
| Requisitos, costes y seguridad | Cerrados |
|
||
| Hardware | Sin acceso. Modelo de blade sin confirmar |
|
||
|
||
### Verificado
|
||
|
||
- Los 19 ficheros YAML parsean
|
||
- La plantilla de `docker-compose` renderiza YAML válido en los dos modos de red, con puertos e
|
||
IPs bien asignados
|
||
- `fleet.sh` pasa `bash -n` una vez renderizado
|
||
- Los 4 diagramas SVG parsean y renderizan sin desbordes
|
||
- Las especificaciones del chasis vienen del manual del propietario (Dell, BMX01, rev. A06,
|
||
oct. 2019), no de estimaciones
|
||
|
||
### Sin verificar
|
||
|
||
- Nada se ha ejecutado contra hardware real
|
||
- Que las imágenes x86_64 de Android arranquen en la generación de CPU de estos blades. Es el
|
||
riesgo si resultan ser M610 (Xeon 2009–2011)
|
||
- El comportamiento de `macvlan` sobre los módulos de I/O concretos del chasis
|
||
- Que 3 instancias por blade sean cómodas con 8 GB en carga real
|
||
- Las cifras de consumo son estimaciones. El CMC da el dato real
|
||
|
||
## Preguntas abiertas
|
||
|
||
1. **Modelo de blade**: M610 / M620 / M630. Determina CPU, generación y tipo de RAM.
|
||
→ `ansible-playbook playbooks/preflight.yml`
|
||
2. **Qué módulo hay en A1/A2**: un switch conmuta entre blades dentro del chasis, que es lo que
|
||
necesita `macvlan`; un módulo de paso a través saca 16 RJ-45 y deja la conmutación a un switch
|
||
externo. Cambia el montaje de red por completo
|
||
3. **¿Responde el CMC?** Da el inventario completo y el consumo real
|
||
4. **Dónde va el chasis y quién paga la luz.** El sitio tiene que estar por debajo de 35 °C todo
|
||
el año
|
||
5. **Utilización prevista.** Por debajo del ~12 %, la nube sale más barata que tenerlo 24/7
|
||
|
||
## Siguientes pasos
|
||
|
||
### Sin hardware
|
||
|
||
- [ ] Lanzar el piloto de un nodo en un sobremesa. El bloque está comentado en
|
||
`02_device_lab/ansible/inventory/hosts.yml.example`
|
||
- [ ] Confirmar que redroid arranca, que `fleet` habla con los contenedores y que un APK de
|
||
`oasis_mobile` se instala en toda la flota
|
||
|
||
### Con acceso al chasis
|
||
|
||
- [ ] Cambiar credenciales de fábrica del CMC y de los 16 iDRAC (`root`/`calvin`) — S2
|
||
- [ ] VLAN aislada para la granja y otra para gestión — S1 y S3
|
||
- [ ] `preflight.yml` sobre los 16 blades
|
||
- [ ] Medir consumo real en el CMC y corregir `docs/costes.md`
|
||
- [ ] Decidir la ampliación de RAM: es lo único que cambia la economía (8,0 € → 1,8 € por
|
||
dispositivo y mes)
|
||
|
||
### Pendiente en el código
|
||
|
||
- [ ] Fijar la imagen de redroid por digest en vez de por tag mutable — S6
|
||
- [ ] nftables en los blades: 5555+ solo desde el coordinador — S1
|
||
- [ ] `ansible-vault` para secretos — S7
|
||
- [ ] Script de encendido y apagado por ventanas contra el CMC vía RACADM
|
||
- [ ] Rol de GADS cuando la flota pase de una decena de dispositivos
|
||
- [ ] Provisión de Debian por PXE, para no instalar 16 blades a mano
|
||
|
||
## Convenciones
|
||
|
||
Documentación en castellano.
|
||
|
||
Lo verificable se verifica y lo demás se dice. Si algo no se ha ejecutado, el documento lo indica.
|
||
Las estimaciones van con sus supuestos a la vista.
|
||
|
||
Los hallazgos de seguridad se numeran (S1…S11 en [docs/seguridad.md](docs/seguridad.md)) y se
|
||
referencian por número.
|
||
|
||
Nada de operativa de alta masiva de cuentas: está bajo persecución activa en la UE y no funciona
|
||
con este hardware, por lo que explica
|
||
[01_investigacion/capa_identidad.md](01_investigacion/capa_identidad.md).
|
||
|
||
## Fuera del repositorio
|
||
|
||
| | |
|
||
|---|---|
|
||
| `inventory/hosts.yml` | IPs reales y posibles credenciales. Solo se versiona el `.example` |
|
||
| `ansible/reports/` | Informes de preflight con el inventario real |
|
||
| `*.apk` | Binarios |
|
||
| `vault.yml`, `*.vault` | Secretos de ansible-vault |
|