Consideraciones para una Raspberry Pi en funcionamiento prolongado

 (dzombak.com)
1 puntos por GN⁺ 2024-02-18 | 1 comentarios | Compartir por WhatsApp
  • Para mantener una Raspberry Pi sin intervención durante semanas o incluso años, hay que diseñar de antemano una ruta de recuperación automática ante fallas
  • La guía reemplaza el artículo anterior sobre reducir el desgaste de la tarjeta SD con una serie más amplia sobre confiabilidad, que reúne respuestas por tipo de problema y consejos de monitoreo
  • Los principales riesgos se dividen en fallas de conexión WiFi, interrupciones de servicios, crashes por inestabilidad de hardware, firmware o drivers, y desgaste o saturación de capacidad de la tarjeta SD
  • Los problemas de la tarjeta SD pueden mitigarse eligiendo una microSD adecuada, evitando usar swap, reduciendo escrituras, usando un sistema de archivos raíz de solo lectura y ejecutando fsck cuando sea necesario
  • Desactivar journaling puede reducir el desgaste, pero aumenta el riesgo de corrupción del sistema de archivos ante crashes o cortes de energía, por lo que no encaja con el objetivo de estabilidad a largo plazo

Puntos de falla que conviene revisar primero en operación prolongada

  • Para mantener una Raspberry Pi en línea durante mucho tiempo, hay que evaluar cómo se recuperará ante cada situación de falla, y comparar también los beneficios y riesgos de cada solución
  • El autor usa Raspberry Pi en su casa como transmisor FM de baja potencia y como monitor de energía de un UPS, entre otros usos
  • La serie Raspberry Pi Reliability recopila tipos de problemas que el autor experimentó y sus formas de resolverlos, e incluye principalmente consejos de monitoreo con Uptime Kuma
  • Esta serie busca ser una guía más completa que el artículo anterior sobre reducir el desgaste de la tarjeta SD, y los artículos enlazados funcionan como reemplazos actualizados

Respuestas por tipo de problema y opciones que conviene evitar

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-02-18
Opiniones de Hacker News

  • En cambio empecé a comprar Lenovo mini PC; con 18 cm x 18 cm x 3 cm siguen siendo muy pequeños.
    Hoy en día se consiguen muy baratos, y vienen con un gabinete y refrigeración adecuados: https://psref.lenovo.com/syspool/Sys/PDF/ThinkCentre/ThinkCe...
    Tengo uno justo al lado: i5-8500T, 32 GB de RAM, 2 SSD, y con el autotuning de powertop el consumo en reposo ahora es de 5 W: https://wiki.archlinux.org/title/powertop

    • No tienen GPIO, I2C ni SPI. Si simplemente buscas un servidor pequeño y liviano, sirven, pero Raspberry Pi también es popular por sus capacidades de entrada/salida, que son poco comunes en equipos de consumo/oficina.
      Podrías agregar una conexión serial a un microcontrolador, pero eso hace que la solución sea menos prolija.
    • El año pasado pasé mi reproductor multimedia Kodi de una RasPi 4 a una N3350 mini PC, y no me arrepiento.
      Hace poco también migré mi NAS (N5105) y mi máquina de servicios (3215U) a mini PC usadas y Chromebooks desbloqueadas que conseguí en eBay o en mercados de pulgas. Son baratas, mantienen bajo el consumo de energía y la capacidad de cómputo está en un nivel completamente distinto al de una Pi.
    • Yo hago algo parecido, pero uso una Dell 7060.
      En Australia aparecen por miles cuando terminan los contratos de leasing. Los chips 8500T u 8700T son excelentes, pueden ejecutar Windows 11 oficialmente y traen transcodificación por hardware integrada, así que son buenos como servidores Plex.
      A una de las mías le puse 2 SSD de 2 TB y 64 GB de RAM, y funciona 24/7 sin problemas.
    • A mí me pasó igual. Compré una Dell reacondicionada y todo se volvió mucho menos problemático.
      La tarjeta SD probablemente era la principal fuente de problemas, y si además consideras el costo de conectar algo como un SSD a una RPi, ya no resultaba rentable.
    • Comparado con hardware ARM, también está bueno que puedas correr prácticamente cualquier distribución de Linux.

  • El primer consejo no debería ser activar el modo journaling del sistema de archivos.
    El primer consejo debería ser montar el sistema de archivos en modo solo lectura, montar /var en memoria y enviar todos los logs a un nodo con un UPS adecuado y NUT en ejecución, no a la RPi. Si el sistema de archivos es de solo lectura o está en un área temporal, un corte de energía se vuelve prácticamente inofensivo.
    Para una sola RPi puede ser demasiado, pero el autor dijo que usa varias repartidas por la casa.
    También es buena idea tener particiones de sistema A/B y actualizar reescribiendo una partición completa, para luego cambiar la partición activa. Así, aunque la versión nueva tenga un bug crítico, siempre queda una partición de sistema funcional y la recuperación es sencilla.
    He usado bien este enfoque durante más de 20 años con varias PC pequeñas/de placa única en distintos roles.

    • El autor enlazó unas líneas más abajo un consejo sobre una configuración de solo lectura.
      https://www.dzombak.com/blog/2021/11/Reducing-SD-Card-Wear-o...
    • Hay que usar tmpfs no solo para /var, sino también para lugares como /tmp. Eso debería aumentar mucho la vida útil de la tarjeta SD.
    • Si actualizas reescribiendo una partición completa con particiones de sistema A/B, me da curiosidad cómo es el procedimiento de actualización.
      Me pregunto cómo se crea la nueva imagen de disco y si se inicia sesión en cada dispositivo para actualizarlo o si hay automatización.
    • Si montas el sistema de archivos como solo lectura, me pregunto cómo haces las actualizaciones del sistema o instalas software nuevo.
    • Si usas algo como Docker, al montar /var en memoria podrías exceder la memoria del dispositivo.
      Tal vez tengas que mover /var/lib/docker a almacenamiento secundario.

  • En 2011 creé un producto comercial que corría en una de las primeras computadoras tipo plug de Global Scale Technologies.
    Solo vendimos unas 20 unidades, pero todas fueron devueltas por problemas de corrupción de tarjetas SD, y tuvimos que cambiar de urgencia el sistema de archivos raíz a solo lectura. Desde entonces me empezó a gustar este enfoque.
    Ese primer producto comercial era un producto de seguridad para el hogar con algunas funciones muy pequeñas de automatización del hogar; en 2021 lo publiqué como open source con un nuevo nombre, y ahora funciona en computadoras de placa única de la línea Jetson: https://github.com/hcfman/sbts-install
    Ahora también incluye modelos YOLO avanzados como disparadores. Como estaba pensado para ser un producto independiente, tenía soporte para HTTPS y también una GUI que envolvía todo el trabajo con certificados. Esa función sigue en la versión open source, así que es fácil usar certificados autofirmados para llamadas REST entre dispositivos.
    Además mantuve y amplié el enfoque de overlayFS en memoria con múltiples particiones, y el instalador primero instala un sistema sbts-base para que otros puedan usarlo como su propio sistema base.

    • Tengo una experiencia parecida. Convertí una PC Pentium 2 de 5 dólares en una estación de trabajo sin ventilador y silenciosa, cambiando el HDD por una tarjeta CF.
      Con el tiempo, el sistema empezó a congelarse 1 o 2 segundos cada vez que escribía en disco, y fue bastante doloroso.

  • A quienes quieran hacer algo así, primero les recomendaría ver si no pueden resolver lo que necesitan con una placa pequeña como ESP32
    Consumen mucha menos energía, cuestan apenas unos dólares y son suficientes para muchos usos. Si prefieren el lado de Python, muchas placas soportan tanto MicroPython como CircuitPython
    Vale la pena revisarlo, porque puede reducir tanto el costo inicial de compra como el gasto continuo de electricidad

    • Entiendo la objeción de quienes se preocupan por el costo en tiempo y la complejidad de la programación embebida, pero para usuarios aficionados me parece una excelente recomendación que al menos vale la pena considerar
      Los proyectos hechos con microcontroladores me han resultado décadas más estables que los basados en Pi, y también hay menos preocupación de olvidar cambiar la configuración SSH por defecto y terminar formando parte de una botnet. Creo que el valor por defecto era pi:raspberry
      Además de MicroPython, el soporte de no_std Rust para ESP32C3 mejora cada mes. Para alguien que hace pequeños proyectos de automatización del hogar por diversión, las restricciones adicionales pueden hacerlo más entretenido y gratificante
      Dicho eso, para quien ya está familiarizado con Linux, una Pi suele ser mucho más fácil y, en mi experiencia, cuesta al menos unas 10 veces más. También hay que incluir en la decisión configuraciones adicionales como arranque desde SSD, arranque por red, sistema de archivos raíz de solo lectura y configuración de watchdog para lograr el mismo nivel de estabilidad, además del mayor consumo de energía, en especial el de la Pi 5
    • ¿Se puede correr un servidor de medios en un ESP32? No
      ¿Se puede correr un servidor de gestor de contraseñas en un ESP32? No. ¿Pi-hole? No. ¿Controlador Unifi? No
      Este tipo de recomendación parece imaginar que la gente usa una Pi para cosas como un controlador de puerta de cochera, pero sugerir de forma refleja un ESP32 como reemplazo de una Pi no ayuda mucho
    • El ESP32 y las placas relacionadas son bastante geniales, pero requieren una forma de pensar completamente distinta
      Cuando algo no funciona, no puedes conectar HDMI y teclado y depurar al vuelo en un entorno Linux mainline con todas las utilidades habituales
    • Una Pi Zero cuesta alrededor de 1 dólar al año en electricidad
    • En una configuración reciente un poco más compleja, uso una Pi Zero junto con varios ESP8266/32 comunicándose por HTTP y Wi-Fi
      Probé MicroPython por primera vez en vez de Arduino y me encantó; sorprendentemente, es muy estable. Antes, por los estados de energía de Wi-Fi, los proyectos solían fallar con frecuencia a largo plazo, pero hasta ahora no he tenido problemas con la estructura de MicroPython

  • Eso de que “al final casi siempre se reduce a un script que comprueba periódicamente si la conexión Wi-Fi está bien y, si no, reinicia la interfaz Wi-Fi o toda la Pi” no es un hack, sino una buena práctica
    Así como un servidor importante en un centro de datos debería tener una conexión fuera de banda, como IPMI o una toma RPDU controlable de forma remota, un servidor importante en una ubicación remota de difícil acceso debería tener un script watchdog
    Por supuesto, hay que ajustarlo al caso de uso considerando el impacto de reiniciar y el tiempo de caída hasta que se reinicie, y al menos se pueden registrar los eventos anómalos para investigarlos después
    Cuando desplegué una RPi remota, lo primero que hice fue un script watchdog sencillo en Bash. No era solo para problemas de Wi-Fi, sino para decenas de situaciones que podían romperse y arreglarse con un reinicio

    • Hoy en día, en la mayoría de las distribuciones, ese papel de watchdog lo cumple init/PID 1, es decir, systemd
      Si no se puede confiar en que init gestione servicios, entonces me pregunto de dónde viene la garantía de que el sistema va a prestar servicios
      Podríamos rehacerlo con scripts, pero ya pasamos esa etapa. Menciono mucho systemd, pero no es por favoritismo; también hay alternativas
      La mayoría de los servicios no aprovechan bien el entorno en el que existen. Parece que se espera una personalización específica del sitio, como declarar que un servidor web necesita cierto montaje
      Una directiva que se suele pasar por alto es PartOf=. Permite vincular el reinicio de un servicio o recurso con otro
      Más simple aún, probablemente NetworkManager ofrezca alguna forma de personalizar la comprobación de Wi-Fi/portal. Quizá no haga falta irse a algo completamente radical
    • De forma parecida, uso un ESP8266 para vigilar el router Wi-Fi y el módem de cable. Si hay un problema, los reinicia
      En el caso del router, intenta conectarse al SSID adecuado y hace ping al router; si cualquiera de las dos cosas falla, cambia al otro router. Tengo dos routers iguales con la misma configuración, y la alimentación está conectada a los contactos NO/NC de un relé SPDT, de modo que si uno falla basta cambiar el estado del relé para pasar al otro
      Si el router está vivo, el watchdog carga la página de estado del módem de cable y hace ping a cualquiera de tres IP dentro de la red del ISP que parecen ser el CMTS o equipos cercanos, para comprobar que la infraestructura HFC siga activa. Si la falla no se puede resolver con un reinicio, no quiero reiniciar por gusto
      Lamentablemente, no encontré forma de tener dos módems de cable con la misma MAC y alternar entre ellos, y el ISP tampoco permite dos módems en la misma cuenta, así que si falla el módem de cable no queda más que reiniciarlo y esperar que funcione
      A esto le añadí un rack de baterías que puede mantener el router y el módem funcionando más de 30 horas durante un corte de luz, y desde que lo armé en mayo de 2020 se ha mantenido en línea casi todo el tiempo. El código es horrible, pero en la práctica funciona de forma muy robusta
    • Totalmente de acuerdo. Los temporizadores watchdog son indispensables en microcontroladores y computadoras que corren software “para siempre”
      Pasan cosas que ni el código ni el diseño perfectos pueden evitar, y un temporizador watchdog rompe los bucles infinitos y reinicia. También están cosas como una nave espacial que invierte bits o caídas momentáneas de voltaje, y en una Raspberry Pi también hay que preocuparse por la corrupción de la tarjeta SD
      Entiendo que la Raspberry Pi tiene un temporizador watchdog de hardware integrado. Arduino definitivamente lo tiene
    • Es una buena práctica y, al mismo tiempo, también es un hack. No debería ser necesario, pero como los bugs existen, se vuelve necesario

  • Durante casi 10 años hemos estado operando miles de Pi en entornos de producción, y ahora estamos empezando a migrar a x86
    La relación precio/rendimiento de las Pi ya no es la de antes. Presenté esta experiencia recientemente en State of Open Con: https://youtu.be/vX-qK9mxKZI

    • Como colega CEO de una empresa de señalización digital con Raspberry Pi, me sorprendió que en la presentación no se mencionara el soporte de arranque seguro disponible desde la Pi 4
      Nuestro servicio todavía no lo usa, pero según la documentación parece bastante sólido y puede proteger los datos del disco/SD
      Todavía estamos bastante satisfechos con la Pi, y el paso a APIs más abiertas como Mesa/DRM/KMS/FFmpeg se ve muy prometedor ahora que por fin están en un estado usable
      Como el uso principal sigue siendo la señalización digital, la potencia bruta de procesamiento no es tan importante. La decodificación de video, que representa una parte importante del costo, obviamente está acelerada, y la compatibilidad hacia atrás posible en la Pi es excelente. Todavía tenemos clientes que siguen usando Pi1B+ desde hace casi 10 años, con la versión más reciente del SO que ofrecemos
    • Hay que tomar en cuenta el patrón de uso. Si pasa mucho tiempo en reposo, creo que ARM es mejor que x86
      También hay que considerar la vida útil, y ahí también creo que ARM durará más que x86. En términos de modularidad, ARM también es mejor que x86, porque es más barato tener varios dispositivos pequeños
      Pero en cuanto a escalabilidad, es decir, viabilidad comercial en la economía actual, x86 es mejor que ARM
      Además, todos los gráficos deberían estar expresados por watt. Que al pasar de 2 a 4 el rendimiento haya mejorado no es noticia; lo importante es si mejoró el rendimiento por watt
      Visto así, se nota que la Raspberry Pi 5 no tiene una mejora de rendimiento por watt tan grande como se esperaba. Parece que hemos alcanzado una cima permanente en la historia de la humanidad
      Por último, en este momento la única esperanza de avance no está en el rendimiento sino en la apertura, con JH7110, aunque el soporte 3D está atrasado
    • Me pregunto si es para manejar pantallas, o para equipos operativos que usan GPIO, como maquinaria de ensamblaje en producción
    • Me pregunto qué significa concretamente eso de migrar a x86

  • Aunque no hicimos nada de eso, varias Pi funcionaron sin problemas durante años hasta que fueron reemplazadas por modelos nuevos
    La gateway HomeKit/Zigbee y el registrador de datos ahora están en una Pi 4. Al final, parece que la clave son una buena tarjeta SD y una fuente de alimentación estable

    • De acuerdo. Yo también he usado varias Pi, y cuando fallaron fue por tarjetas SD defectuosas
      Creo que pibenchmark es una buena fuente de información: https://pibenchmarks.com/
      Antes de comprar, hay que comparar sí o sí las tarjetas SD
    • Creo que el tamaño de la muestra influye más en la experiencia
      Si operas suficientes dispositivos, todo lo que pueda salir mal va a salir mal, y también aparecerán nuevos modos de falla que ni en sueños habías imaginado
    • Las versiones antiguas de Raspbian OS, de alrededor de 2016 y anteriores, tenían activado el registro de tiempos de acceso, así que cada vez que se leía un archivo se producía una escritura
      Probablemente esa fue la razón de tantos reportes de tarjetas dañadas después
    • A mí me pasa algo parecido. Tengo varias Pi3 funcionando como servidores Cups desde hace años, y el tiempo de actividad solo se reinicia cuando hay un corte de energía. Los cortes también son muy raros
      No hice nada más que instalar Raspbian en una tarjeta micro SD, configurar Cups y conectar el USB a la impresora. Otra administra una impresora de red. Después de eso simplemente las dejé así
    • Es muy irregular. Algunas dieron problemas sin parar, y otras aguantaron mucho tiempo sin inconvenientes. No veo un patrón claro
      Ahora cambié la mayoría a SSD. Si no, se siente demasiado como tirar los dados

  • Me sorprendió que lo de las tarjetas SD no fuera lo primero, y me sorprendió aún más que el artículo no propusiera arranque por USB
    Tengo una Pi encendida casi 24/7 desde hace años, y creo que no ha dado problemas por 1) haber configurado Alpine para tocar el disco lo menos posible, y 2) no tener una tarjeta SD que pueda corromperse. No sé por qué USB es más confiable, pero empíricamente así fue

    • Mi configuración Argon Raspberry con un SSD conectado también es estable
      La única razón por la que falla es cuando se va la luz. Creo que una batería que aguante apenas 10 minutos sería más que suficiente
    • Me interesa saber cómo configurar Alpine para que casi no toque el disco
      Por ejemplo, quisiera saber si te refieres a algo como https://wiki.alpinelinux.org/wiki/Installation#Diskless_Mode
    • Tuve muchas tarjetas de Pi funcionando con SD sin problemas. Pero en una sola, la tarjeta SD de pronto se puso muy caliente, y era una Pi nueva que apenas estaba configurando
      Saqué la tarjeta y pasé esa tarjeta y la siguiente Pi a usar SSD por USB. Me dio algo de miedo. Aun así, como dije antes, también tengo una Pi funcionando como servidor Cups durante años con micro SD sin problemas
    • Totalmente de acuerdo. Todas mis fallas de RPi fueron por la tarjeta SD
      Mis dos RPi arrancan y funcionan desde USB, y llevan años funcionando bien
    • A mí igual. Arranco desde un SSD con un M.2 HAT y funciona muy bien

  • Desde 2017 tengo dos Pi funcionando casi continuamente con las mismas tarjetas SD. Hubo unos 2 o 3 cortes de luz.
    Uno es un servidor DNS/de impresión, y el otro es Kodi, con los medios en un NFS externo. Lo único que hice fue desactivar todos los logs, y nunca tuve problemas.
    Ambos usan tarjetas SanDisk de 2 GB. Recuerdo vagamente haber pensado de forma ingenua algo como “menos espacio → menor densidad de bits → mejor confiabilidad”.

    • He usado log2ram (github/azlux/log2ram) y estoy conforme con el resultado.
      Monta un disco RAM en /var y solo de vez en cuando copia los logs del disco RAM a la tarjeta SD. Gracias a eso puedo ver todos los logs sin castigar demasiado la tarjeta SD.
    • Llevo casi 10 años usando Kodi en una Pi 1 con la tarjeta SD original.
      Está encendida la mayor parte del tiempo, aunque de vez en cuando apago por accidente la fuente de alimentación USB conectada. Es una fuente pequeña de 5 puertos, casi de la misma edad, y en mi configuración el botón de encendido se presiona con demasiada facilidad.
    • Tengo una RPi funcionando sin parar desde 2014 con la misma tarjeta SD, sirviendo un sitio web del clima.
      Básicamente monté todos los logs y las páginas web en tmpfs; la DB está en la tarjeta SD y se escribe cada 5 minutos.
    • Todavía conservo mi primera Pi. Probablemente sea una Pi 1B.
      Pasó por varias instalaciones, pero ahora es un servidor DNS de respaldo. Al mirar el sistema de archivos, veo que se usa como Pi-hole desde 2018 y, salvo algunos reinicios y mudanzas, básicamente funciona 24/7.
      No escribe nada en la SD; todo va a RAM en /dev/shm. Si Pi-hole se cae, cosa que rara vez pasa, basta con volver a descargar las listas; de todos modos se descargan todos los días.
    • A mí me pasa igual. Tengo dos Raspberry Pi 3 y desde 2019 corro Pi-hole para bloquear anuncios.
      Más adelante también empecé a usarlas como DNS local y nodos de Tailscale. A veces pasaron meses sin reiniciarse, y el mayor tiempo de actividad fue de unos 11 meses. Fueron muy sólidas. Tenerlas conectadas a un UPS sin duda ayuda.

  • Se dijo que “mantener una Raspberry Pi en línea sin intervención durante semanas, meses o años es en cierta medida un arte”, pero yo arranco un kernel de NetBSD con sistema de archivos integrado.
    Por ejemplo, uso el kernel INSTALL o un kernel personalizado. Después del arranque, se puede retirar la tarjeta SD y, opcionalmente, hacer chroot a un almacenamiento conectado.
    Así funciona durante semanas, meses o años. No he tenido los problemas que menciona el autor del blog.
    El único problema que encontré está del lado del conector de alimentación cuando se usa una carcasa. Por ejemplo, con un cable de reemplazo la conexión puede quedar débil. Tal vez en las Pi más recientes haya mejorado.
    Pero se podría decir que la mayoría de las computadoras son parecidas. Los cables y conectores suelen ser piezas débiles y baratas. Si se corta la alimentación por algún movimiento, la Pi se reinicia automáticamente.