hacklab/REBELION_EN_LA_GRANJA
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
REBELION_EN_LA_GRANJA/GUIA.md
s1to 7caa240c2e 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
2026-08-08 20:04:00 +02:00

3.7 KiB
Raw Permalink Blame History

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) 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.

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