Ajustar al manual del M1000e, añadir diagramas y docs de operación
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
This commit is contained in:
s1to
parent
74bfbe9437
commit
7caa240c2e
17 changed files with 1012 additions and 423 deletions
156
GUIA.md
156
GUIA.md
|
|
@ -1,137 +1,91 @@
|
|||
# Guía de trabajo
|
||||
|
||||
Cómo seguir con esto. Estado real, qué está verificado y qué no, y por dónde continuar.
|
||||
|
||||
---
|
||||
|
||||
## Estado a 2026-08-08
|
||||
## Estado
|
||||
|
||||
| Parte | Estado |
|
||||
|---|---|
|
||||
| Investigación | **Cerrada.** Cinco documentos en `01_investigacion/` |
|
||||
| Automatización Ansible | **Escrita, sin ejecutar** contra hardware |
|
||||
| Documentación de requisitos, costes y seguridad | **Cerrada** |
|
||||
| Hardware | **Sin acceso.** Modelo de blade sin confirmar |
|
||||
| Decisión de qué vía se ejecuta | **Pendiente** |
|
||||
| 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 |
|
||||
|
||||
### Qué está verificado
|
||||
### Verificado
|
||||
|
||||
- Los 18 ficheros YAML parsean correctamente
|
||||
- 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, sin Jinja pendiente
|
||||
- El M1000e está identificado por su spec sheet oficial (Dell EMC, dic 2016)
|
||||
- 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
|
||||
|
||||
### Qué NO está verificado
|
||||
### Sin verificar
|
||||
|
||||
Y conviene tenerlo claro antes de fiarse de nada:
|
||||
|
||||
- **Nada se ha ejecutado contra hardware real.** Ni un blade, ni el sobremesa
|
||||
- Que las imágenes x86_64 de Android arranquen en la generación de CPU de estos blades —
|
||||
el riesgo real si resultan ser **M610** (Xeon 2009–2011)
|
||||
- El comportamiento de `macvlan` sobre los switches FlexIO concretos del chasis
|
||||
- Que 3 instancias por blade sean cómodas con 8 GB en carga real, no solo en el papel
|
||||
- **Las cifras de consumo son estimaciones.** El CMC da el dato real; media hora ahí sustituye
|
||||
todo `docs/costes.md` por medidas
|
||||
|
||||
---
|
||||
|
||||
## Las tres vías
|
||||
|
||||
Ninguna elegida todavía.
|
||||
|
||||
### 1 · Device lab en el rack
|
||||
|
||||
Infra legal y reutilizable. Primer uso real: probar `oasis_mobile` a escala, incluido el escenario
|
||||
de **dos APKs que se tienen que ver entre sí**. La automatización ya está escrita.
|
||||
|
||||
**Bloqueante**: sitio con 2,6–3,6 kW, extracción y tolerancia a 70–85 dB. Ver
|
||||
[docs/requisitos.md](docs/requisitos.md).
|
||||
|
||||
### 2 · Charla sobre la economía de los bots
|
||||
|
||||
Ángulo defensivo y periodístico, con demanda real. HackMadrid, hacklabs, **Hackmeeting València
|
||||
(9–12 oct 2026)**. El material está entero en `01_investigacion/`; el guion en
|
||||
[03_charla/](03_charla/).
|
||||
|
||||
**Es la vía con menos fricción**: no necesita encender nada.
|
||||
|
||||
### 3 · Reward farming
|
||||
|
||||
Ingreso pasivo, legal-gris. Márgenes malos en 2026. Documentado por completitud, no recomendado.
|
||||
|
||||
---
|
||||
- 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
|
||||
|
||||
Por orden de lo que más desbloquea:
|
||||
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
|
||||
|
||||
1. **¿Qué modelo de blade hay en el chasis?** M610 / M620 / M630. Determina CPU, generación y tipo
|
||||
de RAM — y si el proyecto es viable. → `ansible-playbook playbooks/preflight.yml`
|
||||
2. **¿Responde el CMC en red?** Si sí, da el inventario completo y el **consumo real**
|
||||
3. **¿Dónde va el chasis y quién asume la factura?** Es lo que decide, más que ninguna
|
||||
consideración técnica
|
||||
4. **¿Cuánta utilización real va a tener?** Por debajo del ~11 % la nube sale más barata que
|
||||
tenerlo 24/7. Ver [docs/costes.md](docs/costes.md)
|
||||
## Siguientes pasos
|
||||
|
||||
---
|
||||
### Sin hardware
|
||||
|
||||
## Siguientes pasos concretos
|
||||
- [ ] 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
|
||||
|
||||
### Sin tocar el hardware (se puede hacer hoy)
|
||||
### Con acceso al chasis
|
||||
|
||||
- [ ] Lanzar el **piloto de un nodo** en un sobremesa: valida el pipeline entero por ~20 €/mes.
|
||||
El bloque está comentado en `02_device_lab/ansible/inventory/hosts.yml.example`
|
||||
- [ ] Con eso, confirmar que redroid arranca, que `fleet` habla con los contenedores y que un APK
|
||||
de `oasis_mobile` se instala en toda la flota
|
||||
- [ ] Preparar la charla — el material ya está
|
||||
|
||||
### Cuando haya acceso al chasis
|
||||
|
||||
- [ ] Credenciales de fábrica del **CMC y de los 16 iDRAC** (`root`/`calvin`) —
|
||||
[docs/seguridad.md](docs/seguridad.md) S2
|
||||
- [ ] VLAN aislada para la granja y **otra** para gestión — S1 y S3
|
||||
- [ ] `preflight.yml` sobre los 16 blades → informe en `ansible/reports/`
|
||||
- [ ] 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 sobre la ampliación de RAM: es lo único que cambia la economía del proyecto
|
||||
(7,6 € → 1,7 € por dispositivo/mes)
|
||||
- [ ] Decidir la ampliación de RAM: es lo único que cambia la economía (8,0 € → 1,8 € por
|
||||
dispositivo y mes)
|
||||
|
||||
### Mejoras pendientes en el código
|
||||
### Pendiente en el código
|
||||
|
||||
- [ ] Fijar la imagen de redroid **por digest** en vez de por tag mutable — S6
|
||||
- [ ] Cortafuegos (nftables) en los blades: 5555+ solo desde el coordinador — S1
|
||||
- [ ] 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
|
||||
- [ ] Rol de GADS, cuando la flota pase de una decena de dispositivos. No está automatizado a
|
||||
propósito: montar un despliegue de Node sin poder probarlo es complejidad sin verificar
|
||||
- [ ] 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.** Es un repo de trabajo, no un producto.
|
||||
Documentación en castellano.
|
||||
|
||||
**Todo lo verificable, verificado, y lo demás dicho.** Si algo no se ha ejecutado, el documento lo
|
||||
dice. Las estimaciones van etiquetadas como estimaciones y con sus supuestos a la vista. Si
|
||||
encuentras una afirmación sin respaldo, es un fallo — corrígela o márcala.
|
||||
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 desde el resto del repositorio.
|
||||
Los hallazgos de seguridad se numeran (S1…S11 en [docs/seguridad.md](docs/seguridad.md)) y se
|
||||
referencian por número.
|
||||
|
||||
**Nada operativo de alta masiva de cuentas.** Ni proveedores de SIM, ni evasión de fingerprint, ni
|
||||
maduración. No es una postura moral: es que está bajo persecución activa en la UE y **no funciona**
|
||||
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).
|
||||
|
||||
---
|
||||
|
||||
## Qué NO se sube al repositorio
|
||||
|
||||
Está en `.gitignore`, pero conviene saber por qué:
|
||||
## Fuera del repositorio
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
| `inventory/hosts.yml` | IPs reales de los blades y posibles credenciales. Solo va el `.example` |
|
||||
| `ansible/reports/` | Informes de preflight con el inventario real del hardware |
|
||||
| `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 |
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue