Dias atras comentaba que la experimentación con un beacon tiene muchos aspectos divertidos. Armarlo y ponerlo en funcionamiento por supuesto es uno, y para muchos el mas importante. Un segundo aspecto es poder realizar experiencias con el, como las compartidas en entrada anterior donde con cuentas simples puede evaluarse distintos circuitos de propagación basado en los reportes que nos entregan del beacon. Estamos hablando de un beacon de
WSPR, pero estoy seguro que lo que comparto en ésta entrada es válido para un beacon de cualquier otro modo, y también para cualquier otro tipo de servicio o recurso de infraestructura que nos propongamos poner en funcionamiento.
El título de ésta entrada alude, justamente, a la denominación en "jerga" informática de cualquier servicio con altisimos niveles de prestación, responde a un servicio que está disponible el 99.999% del tiempo comprometido (cinco nueves). Para transmitir la idea de que significa basta una figura, implica que el servicio en cuestión solo no estuvo disponible en horarios comprometidos 5 minutos por año. Eso es una cifra que requiere inversiones cuantiosas en recursos de infraestructura para lograrse, y aún así muy pocas instalaciones realmente lo consiguen. Si el servicio depende de una computadora solo dar un reboot toma mas que eso, o sea que en la práctica implica que no haya caidas. Posiblemente mueva a la reflexión sobre si no es una exageración para una actividad amateur siquiera plantearselo, mas de uno concordará que lo es. En ocasiones me han comentado con cierta incredulidad sobre mis esfuerzos para hacer mas robusta mi estación de concursos un ¿Para qué?, es un juego... un hobby, ¿no?.
Bueno, si lo es. Pero la gracia de un hobby es experimentar, y se experimenta para aprender, esa es la clave. Para mejorar el nivel de servicio hay que pensar, trabajar, experimentar, encontrar soluciones ingeniosas y finalmente comprender la mejor forma de abordar sensatamente el problema. Hay servicios amateurs que tienen una disponibilidad altísima, posiblemente "cinco nueves" en ocasiones, aunque no tengo datos confiables para afirmarlo. Los satelites OSCAR vienen a mi cabeza inmediatamente, algunos han fallado sin cumplir su misión, pero la mayoría funcionó continuamente por muchos años, incluso muchisimo despues de cualquier expiración sensata de su vida útil. El OSCAR-7 me viene a la cabeza, del cual aún se reportan momentos de funcionamiento luego de 40 años (!¡) de su lanzamiento, o mismo nuestro LUSAT OSCAR-19 quien superó holgadamente la década de funcionamiento. Mas terrenales, pero no menos útiles, las repetidoras de VHF-UHF son recursos que funcionan prácticamente sin interrupción, en ocasiones por meses o incluso años. Si bien la red de packet no es lo que supo ser, los nodos o BBS de esa red funcionaban en forma continua por semanas o meses por vez, y cualquiera que haya sido responsable de uno sabe también que eso no ocurre por casualidad. Si bien profesionalmente estoy habituado a gestionar proyectos de despliegue o funcionamiento de servicios de misión crítica que apuntan a los "cinco nueves" también tengo claro que los esfuerzos (y costos) involucrados en proveerlos distan de ser triviales, el enfoque que se usa en ellos tiene que ser necesariamente diferente de lo que se pone en juego en un esfuerzo amateur. Algo de eso aprendí hace bastante tiempo, tuve en funcionamiento por casi un lustro el nodo LU7DID:ABROWN (década el 90) que operaba como BBS de packet, nodo NETROM y gateway AX.25-Internet; aún hoy me cruzo con gente para el que significó sus primeros contactos con Internet, cuando tener contacto con Internet no era como hoy algo ubicuo y casi universal, sino mas bien todo lo contrario; eso, quizás, es una historia en si misma. El punto es que con su funcionamiento aprendí la esencia de lo que puede llevar ser un servicio de alta disponibilidad amateur, y llegó a funcionar en forma ininterrumpida de a semanas por vez. De alguna manera esos aprendizajes los estoy tratando de poner en juego con la baliza WSPR. Un resumen.
Para empezar la disponibilidad 99.999% las 24 días y los 7 días de la semana es una quimera, ningún servicio, excepto contadisimas ocasiones y a gran costo, lo alcanza. Es mucho mas sensato poner una ventana de funcionamiento mas reducida o una exigencia de disponibilidad mas pequeña; 80 o 90% del tiempo estaría bien, algunas horas por día también. En el ámbito amateur es una mejor estrategia no establecer una disponibilidad, sino tratar que sea lo mas alta, medirla y encontrarnos con el resultado real. Medir la disponibilidad implica que tendremos que desarrollar un método para hacer un "logging" detallado y extensivo del servicio, de manera que cuando ocurra una falla (la que ocurrirá casi siempre con nosotros lejos) nos permita luego reconstruir que pasó. Tener un logging trae el primer problema de mantenimiento, que hacer con ellos cuando crecen incesantemente. Bueno, seguramente adoptaremos alguna estrategia de retener el logging durante algunos pocos dias, lo suficiente mucho para que no se nos escape del horizonte un problema, y lo suficiente poco para que no nos ocupe recursos excesivamente. Siete dias suele ser un buen compromiso. Pero el logging tiende a "achanchar" el proceso que lo escribe cuando se hace muy grande, abrir un archivo de muchos centenares de MBytes o incluso algunos GBytes para agregar una linea de texto puede llevar un tiempo muy significativo, tanto que empieza a distorsionar el funcionamiento mismo del servicio. Por eso hay que tomar la decisión de irlos "rotando", es decir en algún momento del día (medianoche) hacer que se cierre el log del día, guardarlo y abrir uno nuevo para el día siguiente; en le proceso se puede aprovechar para eliminar el mas viejo en la lista, de tal manera que tengamos un número constante de dias guardados. Si fueran importantes o el horizonte debiera ser mas grande que una semana podría considerar que la "cola" guardada sea mayor o periódicamente sacar los logs mas viejos y guardarlos en alguna otra parte (¿un pen drive? ¿un disco externo?) por un tiempo mas prolongado (¿un mes?¿varios meses?¿un año?). En mi experiencia nunca necesité un log mas antiguo que un mes y es eso lo que guardo. A todo ésto, si no quiero encasillarme con estar todos los dias a la medianoche haciendo todas estas cosas tengo que empezar a automatizar, un recurso infaltable es instalar un utilitario tipo "
cron", casi standard en Linux pero con versiones para Windows también. Básicamente es un utilitario donde podemos programar que un determinado comando (que puede ser un script complejo incluso) se ejecute a determinada hora. Ya que tenemos algo que puede correr comandos a cualquier hora también hay que aprovechar para resguardar periódicamente el software y la configuración del servicio, porque nos encontraremos permanentemente haciendo modificaciones a uno u otro, en ocasiones triviales y facilmente reproducibles y en ocasiones muy profundas que si tuvieramos que revertirlas nos llevarían mucho trabajo. De esa forma, y al igual que los logs, podremos recurrir a una copia anterior en caso que la modificación se muestre como inconveniente o, tampoco impensable, que tengamos una falla lo suficientemente severa como para que parte de los datos, configuración o software del servicio se pierda. De esa forma vamos mirando cada vez que ocurre una falla que fue lo que la produjo y pensando como subsanarla, o al menos mitigarla. Descubriremos, con algo de estupor, que muy rápidamente aparecemos nosotros como causa de la falla. Al hacer modificaciones o mejoras, algunas incluso increiblemente sencillas (hacemos una modificación sencilla, en un sistema complejo cuando ya estamos cansados de un día de trabajo.... ¿que puede salir mal?). Pero ¿como evitamos hacer lo que en definitiva es el propósito mismo de tener el beacon o el servicio que sea?... divertirnos.... experimentar.... cambiar cosas... mejorarlas....
Es bueno comprender, y lo mas rápidamente que se pueda, que la única forma de juntar ambas tendencias opuestas, y aparentemente irreconciliables, es con método. Para empezar, nunca tocar el servicio "vivo", por simple que sea la falla o la mejora, excepto que ya esté caido y aún así no siempre es buena idea. Rápidamente uno descubre que tiene que tener una versión, un duplicado un "muletto" para desarrollo, donde uno hace las modificaciones y las prueba, antes de trasladarlas el servicio de "producción" (el que funciona). El "muletto" debe ser tan parecido al real como nos sea prácticamente posible. Y se debe desarrollar, con paciencia y perseverancia, un conjunto de pruebas mínimas para correrlas cada vez que se haga un cambio con el propósito de detectar si se rompió algo fundamental. A ese test se lo suela llamar "smoke test" (prueba de humo), y proviene del viejo método de encender un dispositivo de hardware y observar con atención (y cautela) que no salga humo. Hay que recordar que por mas que nuestros instintos digan lo contrario podemos provocar fallas grandes realizando cambios pequeños, incluso en partes del sistema aparentemente no vinculadas con el cambio. Lo que se cuenta tan sintéticamente lleva horas, dias, semanas de estudio y trabajo tanto para desarrollar los instrumentos como para identificar el software que nos permita hacerlo o nos ayude a hacerlo.
Continuando con la evolución rápidamente encontraremos que la disponibilidad está gobernada por la energía, o mas bien su disponibilidad. En un beacon WSPR es relativamente sencillo de mitigar, bastará utilizar un pack de carga de 5A/h de teléfono celular para tener una autonomía de 12 horas o más. Bastará tenerlo con un esquema de carga flotante para que esté siempre listo. El tipo de consumo (1 a 2A/h @ 5V) permite considerar alternativas, una batería de gel mas un regulador puede alimentar el servicio por horas, incluso una placa de paneles solares pequeña (como las que se venden para cargar celulares) puede ser suficiente para independizar el beacon de la red de alimentación.
¿Es realmente necesario el servicio de un beacon WSPR para que tengamos tanto cuidado con la disponibilidad? ¿Que pasa si simplemente se apaga?. La respuesta, para sorpresa de nadie es,
nada. La disponibilidad, o su mejora, no es necesaria para la red de estudio de propagación, hay muchas otras alternativas, y de última unos pocos reportes perdidos no alteran los GBytes o TBytes de información acumulada a nivel global. No es una cuestión de necesidad, es una cuestión de ansias de aprender. Cuando mejoramos la disponibilidad nos enfrentamos a problemas, los estudiamos, buscamos estrategias para solucionarlos, descubrimos que las buenas ideas no siempre son buenas, que hay veces que las malas ideas confirman que lo son y que sorprendentemente la
"navaja de Occam" (Occam's razor) es casi siempre cierta. Y alli también aplicamos el juicio y el sentido común, aplicamos un pack de recarga si ya tenemos uno, y si tenemos uno mas chico entonces acordamos con nosotros mismos que la autonomía será de unas pocas horas en vez de días, cosa que de todas maneras probablemente será suficiente. Y miraremos con cariño los avisos en Mercado Libre o en los cambalaches de FaceBook para cuando ofrezcan paneles solares chicos a buen precio. ¿Un generador?, ... ¿porque no?, ¿no quisimos siempre acaso tener uno y no queremos ver como es la mejor forma de dar energía alternativa a la estación?
Aprenderemos que en algún momento de la hoja de ruta nos encontraremos con una pared, pasada la cual nos es cada vez mas trabajoso, o costoso, mejorar. En la mejora de procesos profesional también pasa, se lo llama "plateau" y es el indicativo que lo que estamos haciendo agotó el potencial para seguir mejorando, hay que buscar otra cosa... Se pueden tomar muchas estrategias, pero la redundancia suele ser una buena opción. No tiene que ser el sistema completo, en ocasiones basta con partes de el. En el caso de una baliza es posiblemente una placa Raspberry adicional, con una configuración denominada "hot stand-by", es decir, que toma control cuando la principal por alguna razón queda fuera de servicio. Un par de relays bastarán para conmutar otros componentes como antenas por ejemplo, y algo de software para implementar todo, y backups, claro.
En realidad al beacon WSPR lo respalda una constelación de otras 5 placas Rasbpberry, el conjunto lo he llamado "
Croix du Sud" y las hosts se llaman respectivamente
GaCrux (Gamma Crucis, en la foto arriba, el beacon propiamente dicho) y las otras
ACrux (Alfa Crucis) máquina de desarrollo y "hot stand-by",
BeCrux (Beta Crucis o "Mimosa"),
DeCrux (Delta Crucis),
ECrux (Epsilo Crucis) y
KaCrux (Kappa Crucis) que no es una estrella sino uno de los cúmulos mas bonitos de los cielos australes, la "caja de joyas" o el "Joyero". Necesito todo ésto para un beacon WSPR,
claro que no :-)
Lo necesito para de paso estudiar en detalle problemas de computación de alta performance (computación paralela) y correr ciertos paquetes de software que se benefician del alto paralelismo, o en todo caso para preparar software para luego correrlo en computadores realmente grandes.
El proceso de mejora, que técnicamente se llama de "mejora continua", puede continuar tan indefinidamente como uno quiera o le haga sentido los esfuerzos incrementalmente mayores para perfeccionar aspectos cada vez mas menores (rendimientos decrecientes). Quizás no lo mencioné, pero todo ésto corre en Linux, y mi mejor estimación en éste momento es que uno puede estudiarlo por una vida y no será suficiente, siempre encontrará algo que no conocía.
Y si.... me descubrieron, poner un beacon es, después de todo una excusa. Feliz Navidad!
