Imagen tomada del sitio: https://www.muycomputer.com/wp-content/uploads/2023/05/FreeBSD.png
Imagen tomada del sitio: https://it-notes.dragas.net/featured/datacenter.webp
Buenos días/tardes/noches estimados blurtters que les gusta el Open-Source!
En esta ocasión vamos a continuar hablando de un caso de éxito para corregir los problemas de una empresa que tenía una solución en la nube con AWS, sustituyendolo con una solución basada en FreeBSD.
Pruebas del Mundo Real
Por mi parte ya no escuche más de ellos. Después de semanas, uno de los desarrolladores me contactó urgentemente debido un desarrollador Junior cometió un desafortunado error y borró un proyecto completo desde una de las "Jails". Les expliqué que las instantaneas locales eran restaurables con un comando, y él estaba
emocionado. El restauró tanto la "Jail" de desarrollo como la que tenía la base de datos dos minutos antes de que ocurriera el "percance", y reiniciaron inmediatamente.
Me di cuenta que este evento podría cambiar algunos de sus procedimientos y criterios.
Ya hace meses que no se nada de ellos. Esta mañana, recibí una llamada de su administrador, del cual no escuchaba desde el principio. y me dijo como estaban yendo las cosas en estos meses.
Lecciones Aprendidas
Primeramente, esta persona tiene buenas habilidades de comunicación y comerciales pero pocos antecedentes técnicos. El es de mente abierta y tiende a estudiar cuidadosamente las cosas que se le proponen. Actualmente el no descarta a priori, si haber analizado los pros y los contras..
Ellos rentaron servidores con cPanel y estaban insertando su contenido dentro de ellos. Los desarrolladores que llegaron hace unos años sugirieron hacer una transición tecnológica, eliminando estos servidores "obsoletos" y metodologías "anticuadas", empujandolo todo a la nube y contenerizandolo todo. Cuando hablamos la primera vez, el me dijo que ellos "tuvieron suerte en hacer la transición debido a que sus cargas se habían incrementado enormemente y los antiguos servidores probablemente no hubieran podido manejar la carga”, en vez de ello la autoescalación los salvó. Yo tenía algunas reservas sobre la autoescalación sin controles particulares, Pero yo no puedo imponer mis elecciones a otros.
Para acortar la historia: viendo lo que había ocurrido con el error del desarrollador junior (y lo fácil que fue el poder arreglarlo y reiniciar todo), ellos decidieron incrementar el uso de las jails de FreeBSD y reducir, al menos en cargas secundarias, el uso de sus nube gestionada con Kubernetes. Conforme ellos transicionaron a las Jails, sin embargo, ellos notaron algunas lentitudes. Estas lentitudes empeoraron día a día. De acuerdo con los desarrolladores, era apropiado volver a tener de nuevo el autoescalamiento (“necesitamos más podeeeeeerrr!!!”) pero, afortunadamente, su jefe decidió investigar con cuidado. Y se dieron cuenta de que estas cargas (basadas en Laravel) estaban almacenando sesiones en archivos. Con el paso del tiempo, estos millones de archivos (varios gigabytes al día) ralentizaron todo debido, a que para operaciones específicas, Laravel escaneaba el directorio completo. En otras palabras, en la “nube-cloud,” ellos necesitaban mucho más poder del necesario (y muchisimo más espacio en disco, pero eso era más barato) para soportar esta carga, lo caul de hecho era innecesaria. Después de darse cuenta de esto, ellos movieron las sesiones a Redis. No es necesario decir que todo se volvio extremadamente más rápido, incluso comparado con configuraciones anteriores en Kubernetes y autoescalamiento.
En ese punto, era claro que uno de los problemas con su configuración es (como frecuentemente ocurre) una pobre optimización. Hoy día, hay una tendencia a las prisas, funciones "lanzalas ahí", características, bibliotecas, plugins, etc. sin considerar las interacciones y consecuencias. Si funciona está bien. Incluso si ello incrementa la complejidad computacional exponencialmente solo para que, por ejemplo, cambien el colo de un icono (ejemplo absurdo, pero es para dar una idea).
Ellos comenzaron entonces a mover inclusive las cargas de trabajo principales de Laravel (gracias a la optimización implementada). Hasta este punto, ellos empezaron a mover algunos de los sitios de Wordpress incluso cuando ellos estaban extremadamente preocupados. Dentro del cluster, cada día, a intervalos bastante irregulares. la carga se podía elevar y todo volvía a hacerse extremadamente lento hasta que el autoescalamiento comenzaba a elevar los límites impuestos previamente. CPU al 100% en todos los contenedores, y los desarrolladores notaron que la carga venía desde una serie de procesos "php". Recrear los contenedores ayudaba por algunos minutos, pero no resolvía el problema.
Para su gran sorpresa, todo esto no ocurría en las jails de FreeBSD. La carga era significativamente menos, sin ninguno de los picos de carga antes mencionados, Satisfechos, ellos decidieron usar ésto como su configuración final.
Uno de los desarrolladores, sin embargo, quizo llegar al fondo del problema y decidió correr algunas pruebas: el movió algunos de estos sitios de WordPress a la máquina virtual de Alpine Linux, en Docker.
En ese punto, los picos comenzaron otra vez, saturando el CPU de la máquina Alpine.
Sin entrar en detalles, ellos eventualmente se dieron cuenta que había una vulnerabilidad en uno (o varios) de los muchos plugins instalados en los sitios de WordPress, que habían sido explotados para inyectar un proceso, probablemente un minador de criptomonedas. El nombre dado al proceso era "php" - así que los desarrolladores al no ser expertos en sistemas, no se preocuparon en entender mejor si en realidad ea un proceso de php o era otro proceso pretendiendo serlo. En FreeBSD, todo esto no ocurría debido a que el ejecutable inyectado no podía correr (no había la compatibilidad Linux activada en el servidor.
Hasta entonces, ellos consideraban estos picos (gastos) como algo orgánico y no se preocuparon demasiado sobre ellos. Pagando para tener a sus amigables intrusos minando.
Conclusión
Ellos pidieron mi ayuda, en la medida de lo posible, para mover otros servicios a FreeBSD. No será fácil, probablemente necesitaremos usar bhyve bastante, pero ellos decidieron que esta es la plataforma en la que desean enfocarse en los años por venir.
Sin lugar a dudas, esta es una historia de éxito de FreeBSD e, indirectamente, de la administración correcta y cuidadosa de los recursos propios. Con demasiada frecuencia, hay esta creencia superficial de que la nube, con sus recursos "infinitos", es la solución a todos los problemas. Y que los Kubernetes son la mejor solución para todo. Yo, por otra parte siempre he creído que existe la herramienta correcta para todo. Puedes clavar un clavo con un desarmador, pero no es la herramienta mas apropiada ni eficiente.
Al día de hoy ellos gastan como 1/10 de lo que ellos solían gastar anteriormente, ellos tienen más control sobre sus datos y las herramientas que usan. Sin duda, todo esto fue causado por una pobre optimización y control de aquellos que gestionan la infraestructura, pero la preguna es: ¿qué tan seguido la gente decide al final que está bien gastar más (especialmente si es el dinero de alguien mas) en lugar de volverse locos por unas horas detras de tal situación para resolverla?
Mientras que teniendo recursos limitados y definidos (aunque elevados) presentan diferentes problemas - pero de optimización. Y en la era de ahorros de energía y recursos, debería ser más sabio dar más importancia a la optimización.
"La abundancia lleva al desperdicio".
Imágen tomada del sitio https://www.rhyous.com/wp-content/uploads/2010/12/FreeBSD-Box.png
Bueno, les deseo éxito en todo lo que hagan en relación al software opensource.
Estamos a la espera de sus comentarios, hasta la próxima publicación donde continuaremos con más sobre éste caso de éxito usando FreeBSD.
@cosmicboy123 fuera!
Si lo deseas puedes votar por mi como witness para poder aumentar las capacidades de un servidor.
https://blurtwallet.com/~witnesses?highlight=cosmicboy123
Integrate al grupo de Telegram de @team-mexico 😀 donde yo y otros usuarios de México y de otros países de habla hispana compartimos experiencias y opiniones así como nuestros propios posts. Una gran iniciativa de @cristo
| 👉Entra a https://t.me/TeamMexico 👈