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
2.4 KiB
Stack técnico: qué se puede correr en un rack Linux
Opciones de software libre
- redroid — Android real en contenedores Docker, GPU acelerada, arm64 y amd64, orquestable con Kubernetes. Es lo mejor para densidad: ~2 GB RAM por instancia, de 30 a 60 instancias en un nodo de 32 cores/128 GB. No ensucia el host y soporta acceso remoto.
- Cuttlefish (Google/AOSP) — dispositivo virtual configurable sobre KVM, imágenes AOSP oficiales. Más pesado, pero es el estándar si importa la fidelidad al SO. Hay patrones de escalado sobre Kubernetes publicados.
- Waydroid — LXC + binder, rendimiento nativo sin encoding de vídeo, pero pensado para una instancia en escritorio, no para densidad.
Orquestación y control
- GADS — activo, iOS + Android, integra Appium.
- DeviceFarmer / STF — fork comunitario de OpenSTF; Google lo abandonó en 2020 y va lento con versiones nuevas de Android.
- Encima: Appium/UIAutomator2 para conducir, scrcpy para ver, ADB sobre TCP para todo.
Lo que un rack no resuelve
Ese rack no sirve para el caso TikTok/Instagram, y esa es exactamente la razón por la que GenFarmer vende cajas con teléfonos físicos de $400 en vez de vender software para tu servidor.
Play Integrity con atestación por hardware, ausencia de sensores reales, strings de GPU, falta de baseband e IMEI legítimo — la detección de emulador es prácticamente determinista desde 2025.
El cuello de botella nunca fue cómputo, fue identidad y confianza del dispositivo. Un rack te da CPU infinita y cero confianza.
Por eso el mercado real es hardware caro y lento, no servidores.
El mecanismo exacto — por qué a un contenedor le falta una clave grabada en fábrica que ningún software puede producir — está en capa_identidad.md.
Donde el rack sí es imbatible: laboratorio de testing de tu propia app. Con oasis_mobile hay
APK que necesita probarse en matriz de versiones de Android y en escenarios multi-dispositivo —
dos APKs que se tienen que ver entre sí. redroid + Appium en un rack resuelve eso de verdad,
incluido el bloqueo de capa 1 anotado.
Ver ../02_device_lab/ para el montaje concreto.