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

6.5 KiB

Raw Permalink Blame History

Usabilidad

Cómo se trabaja con esto en el día a día. No la instalación —eso está en ansible/README.md— sino cómo se usa una vez montado, y qué decisiones de diseño hacen que sea llevadero o insufrible.

Un solo punto de control

45 dispositivos son ingobernables si hay que entrar a cada blade. Por eso todo pasa por el coordinador:

     tú                    coordinador                    45 Android
   ┌────┐    ssh      ┌──────────────────┐    adb     ┌───┬───┬───┐
   │    │ ──────────► │  fleet · adb     │ ─────────► │ · │ · │ · │
   └────┘             │  devices.txt     │            └───┴───┴───┘
                      └──────────────────┘

devices.txt lo genera Ansible a partir del inventario y de la RAM real de cada blade. Nunca se edita a mano: si cambia la flota, se relanza playbooks/coordinator.yml y se regenera.

Órdenes

fleet connect            # conecta adb a toda la flota
fleet list               # qué hay conectado, y cuántos faltan
fleet install app.apk    # instala en todos
fleet shell '<cmd>'      # ejecuta en todos
fleet ip                 # IP de cada Android
fleet reboot             # reinicia todo

Todas son idempotentes o inocuas. connect se puede lanzar mil veces. Ninguna borra nada. La única destructiva del proyecto es playbooks/destroy.yml, y exige -e confirmar=si.

Por qué `fleet list` dice "declarados" y "conectados"

declarados: 45 · conectados: 43

Esa resta es el diagnóstico más útil del sistema. Si no cuadra, hay dos contenedores caídos y se sabe al instante, sin mirar 15 blades. El siguiente paso es playbooks/status.yml, que dice en qué nodo.

Flujos de trabajo reales

Probar una APK nueva en toda la flota

ansible-playbook playbooks/apk.yml -e apk_local_path=~/oasis-0.9.1.apk

Un solo comando desde el portátil: copia el APK al coordinador, conecta la flota e instala en los 45. Sale un recuento de ok / FALLO por dispositivo.

El caso de los dos APKs que se tienen que ver

Es el que motivó el proyecto. Con redroid_network_mode: macvlan:

fleet ip                                  # cada Android con su IP real de LAN
fleet install oasis-A.apk                 # ...o instalar distinto en cada mitad
adb -s 10.0.0.20:5555 install oasis-B.apk

Los dos se ven como pares de red de verdad, no a través de traducciones. Es lo más cerca de "dos móviles en la misma wifi" sin tener dos móviles.

Mirar una instancia concreta

scrcpy -s 10.0.0.20:5555

Ventana con la pantalla del Android, ratón y teclado. Para depurar algo visual no hay nada mejor.

Comprobar una propiedad en toda la flota

fleet shell 'getprop ro.build.version.release'
fleet shell 'pm list packages | grep oasis'

Decisiones de diseño

Decisión	Por qué
Preflight de solo lectura	Se puede lanzar contra hardware ajeno sin miedo. Contesta "¿qué hay aquí y sirve?" sin tocar nada
Instancias automáticas por RAM	No hay que calcular ni mantener un número por blade. Se amplía la RAM y el siguiente despliegue se ajusta solo
`fleet` en el PATH	`fleet list`, no `/opt/granja/fleet.sh list`
Playbooks pequeños y con nombre obvio	`preflight`, `provision`, `devices`, `apk`, `status`, `destroy`. Se adivina cuál usar
Todo relanzable	`site.yml` es idempotente. Ante la duda, se relanza
Errores que dicen qué hacer	El fallo de binder no dice "error": dice que el módulo estaba en uso, que la config persistente ya está escrita y que basta reiniciar ese blade
`destroy.yml` conserva los datos	Borrar `/data` exige un segundo flag. Lo destructivo nunca es el camino por defecto

Problemas conocidos

Ordenados por probabilidad. Están documentados porque son inevitables, no porque sean fallos.

1 · Binder, la primera vez

Síntoma: el playbook falla con "faltan devices binder tras el modprobe".

Causa: el módulo ya estaba cargado y en uso, así que no se pudo recargar con los parámetros nuevos.

Solución: la configuración persistente ya quedó escrita. Reinicia ese blade y relanza. Pasa una sola vez por máquina.

2 · macvlan: el anfitrión no ve a sus propios contenedores

Síntoma: adb desde un blade no encuentra los Android de ese mismo blade.

Causa: limitación del driver macvlan, no un error de configuración.

Solución: no es un problema en este diseño — el coordinador es un blade distinto y desde fuera sí se llega. Por eso apk.yml se ejecuta siempre desde el coordinador. Si algún día montas adb en un nodo de carga, es esto.

3 · El primer arranque de redroid tarda

Síntoma: fleet connect falla justo después de site.yml.

Causa: un Android recién creado tarda en levantar por primera vez, sobre todo con render por software y 45 a la vez.

Solución: esperar y reintentar. fleet connect es inocuo y se puede repetir.

Ergonomía del hardware

Cosas que no son software pero deciden si esto se usa o se abandona:

El ruido manda. 70–85 dB significa que no se puede estar en la misma habitación sin protección. Todo el trabajo tiene que ser remoto — de ahí que no haya nada en el diseño que exija tocar el chasis en marcha.

El LCD frontal es el mejor amigo en el arranque. Configura la red de la CMC con su asistente, sin cable serie ni portátil enganchado. Es el camino corto la primera vez.

Encender por ventanas cambia el hábito. Si el chasis no está siempre en marcha (y no debería, ver costes.md), el flujo pasa a ser: encender → esperar arranque → fleet connect → trabajar → apagar. Merece la pena tener eso en un script y no en la cabeza.

Pendiente

GADS — UI web con la flota, vista de pantallas y Appium integrado. Es el salto de calidad cuando se pasa de una decena de dispositivos. No está automatizado a propósito: montar un despliegue de Node sin poder probarlo sería complejidad sin verificar
Script de encendido/apagado por ventanas contra la CMC vía RACADM
fleet watch — un panel de estado que se refresque solo
Registro de auditoría en fleet — hoy no deja rastro de quién hizo qué (hallazgo S10 en seguridad.md)

6.5 KiB Raw Permalink Blame History Unescape Escape