¶ Visión general
En 2018 nos dimos cuenta de que teníamos un problema que necesitaba una solución radical. A medida que el clima político mundial se volvía cada vez más impredecible, nuestra membresía crecían, experimentaban una popularidad súbita y eran golpeados con ataques de denegación de servicio y no éramos capaces de ajustar sus recursos de Internet rápida y fácilmente para satisfacer estas necesidades.
Aunque teníamos todo un armario de servidores con recursos suficientes para todos, nuestra infraestructura no estaba diseñada de forma que nos permitiera trasladar sitios web, buzones de correo electrónico y bases de datos desde servidores con una carga elevada a servidores con más capacidad.
¶ Diseño antiguo
Nuestro anterior diseño de red se creó en 2005, cuando Internet era un lugar muy diferente y May First era una organización muy distinta. Empezamos con tres servidores físicos:
- hay: panel de control de miembros
- leslie: listas de correo electrónico mailman
- viewsic: todos los servicios para miembros - sitios web, bases de datos, cuentas de correo electrónico
Nuestro diseño se basaba en la necesidad: sólo disponíamos de un servidor para los servicios para la membresía, así que juntamos el correo electrónico, los sitios web y las bases de datos, todo en el mismo servidor. A medida que crecíamos, simplemente añadíamos nuevos servidores (incluso les dimos un nombre especial: servidores MOSH).
A medida que crecíamos, seguíamos añadiendo nuevos servidores MOSH:
Durante nuestros primeros cinco años, crecimos muy rápido y añadíamos un nuevo servidor casi cada año (hay que tener en cuenta que esto era antes de la era de los servidores virtuales, así que cuando añadíamos un "nuevo servidor" significaba añadir una máquina física real a nuestro armario). Como éramos bastante pequeños, no siempre podíamos permitirnos nuevos servidores de gama profesional.
Todos estos factores hacían que nuestro diseño fuera muy útil: al concentrar todos los servicios en un único servidor, significaba que cada servidor era 100% independiente de los demás. Si un servidor tenía un fallo de hardware (sí, algo habitual en aquella época), no afectaba a ninguno de nuestros otros servidores. Este diseño nos funcionó muy bien!
¶ Los tiempos cambian
En 2011, May First ya era una organización muy diferente en un mundo muy diferente:
- Teníamos más servidores de los que cabían en nuestro armario, así que empezamos a alquilar un segundo armario de colocación.
- La capacidad de los nuevos servidores crecía más rápido que las necesidades de alojamiento, lo que nos permitía alojar muchos más recursos en un solo servidor que antes.
- Pudimos permitirnos comprar servidores de gama profesional, que eran mucho más fiables.
- La tecnología de virtualización se estabilizó y nos permitió añadir varios servidores "virtuales" a cada servidor físico.
En este punto, nuestro antiguo diseño empezó a mostrar su edad:
- Los fallos de hardware ya no eran un problema grave, por lo que la ventaja de "aislamiento" de nuestro diseño ya no era tan valiosa como antes.
- El número de servidores MOSH estaba proliferando - teníamos más de 50 de ellos. Algunos tenían cientos de sitios web, otros sólo una docena, lo que hacía que los servidores estuvieran desequilibrados.
- Cuando un sitio web sufría un ataque de denegación de servicio o se hacía popular, el rendimiento de los demás sitios del mismo MOSH se veía afectado.
- Como cada MOSH alojaba correo electrónico, sitios web y bases de datos en el mismo servidor:
- Era difícil optimizar cada MOSH para el servicio que prestaba.
- era difícil trasladar un único recurso (como un único sitio web con mucha carga) a un nuevo servidor porque para trasladar el sitio web de un miembro determinado, teníamos que trasladar todos los recursos del miembro (no sólo el sitio web, sino el sitio web, la base de datos y todos los buzones de correo electrónico).
¶ Hora de un nuevo diseño
En retrospectiva, deberíamos haber comenzado a rediseñar en 2011, pero en ese momento no comprendimos completamente el alcance del problema. No fue hasta 2018 cuando finalmente aceptamos la idea de que la única forma de solucionar este problema era empezar de cero y volver a imaginar un diseño de red fundamentalmente diferente. Llegados a este punto, presentamos una dramática propuesta para reimaginar nuestra red.
El objetivo principal del nuevo diseño era asignar de forma más flexible nuestra infraestructura informática para satisfacer las necesidades de nuestra membresía.
Para lograr este objetivo, el nuevo diseño de la red presenta dos cambios significativos:
- Los servicios web, de correo electrónico y de bases de datos están separados en servidores dedicados a cada tarea.
- Una capa de servidores "proxy" rodea a nuestros servidores de datos. Los servidores proxy reciben todo el tráfico y lo dirigen al servidor de datos adecuado para cada solicitud.
El nuevo diseño de la red proporciona la flexibilidad que necesitamos porque:
- Con el correo electrónico, las bases de datos y los sitios web separados, podemos trasladar fácilmente sólo los recursos necesarios.
- Como todo el tráfico pasa primero por el servidor proxy, no tenemos que esperar a que un cambio de nombre de dominio se propague por Internet. En su lugar, podemos mover los recursos y simplemente actualizar el servidor proxy para indicar la nueva ubicación, un proceso que lleva segundos en lugar de horas.
- Con los sitios web, podemos bloquear más eficazmente el tráfico malicioso o almacenar en caché las páginas solicitadas con frecuencia en la fase de proxy antes de que el tráfico llegue a nuestros servidores web de origen.
¶ ¿Qué significa esto para mí?
Hemos hecho todo lo posible para minimizar las molestias a nuestra membresía. En lo que respecta al cambio en el correo electrónico y las bases de datos, debería ser casi transparente:
-
El cambio de correo electrónico requiere un cambio en los registros DNS de su nombre de dominio - para que su registro de "intercambio de correo" (también conocido como MX) apunte a nuestros nuevos servidores de correo proxy (a.mx.mayfirst.org, b.mx.mayfirst.org y c.mx.mayfirst.org) en lugar del nombre de su MOSH anterior (también conocido como chavez.mayfirst.org, malcolm.mayfirst.org, etc). Y ya está. Para los miembros cuyos nombres de dominio utilicen los servidores de nombres a.ns.mayfirst.org y b.ns.mayfirst.org, trasladaremos su correo electrónico a la nueva infraestructura hasta 2023. En el caso de los miembros cuyos nombres de dominio utilicen servidores de nombres externos, nos pondremos en contacto con ustedes para pedirles que realicen los cambios.
-
El cambio de base de datos será totalmente transparente - estamos ejecutando un servidor SQL "proxy" en cada servidor web, por lo que sus sitios web seguirán conectándose a la base de datos en "localhost", pero esa conexión será proxy transparente al servidor de base de datos de red que contiene su base de datos.
Sin embargo, para los sitios web, el cambio requiere que modifique algunos aspectos de su flujo de trabajo:
- Nuevo nombre de host SSH: Para conectarse a su sitio web a través de ssh o sftp, siempre se conectará al mismo nombre de host:
shell.mayfirst.org. En otras palabras, ya no utilizarás el nombre de dominio de tu MOSH ni el nombre de dominio de tu sitio web. No importa en qué servidor de origen web esté alojado, siempre se conectará a<su-nombre-deusuario>@shell.mayfirst.org. El servidor shell le conectará de forma transparente al servidor de origen web correspondiente. - Preautorización: Primero debes acceder al Panel de control de miembros para autorizar tu acceso ssh o sftp - cuando accedas al panel de control, estarás autorizado a ssh o sftp durante las siguientes 24 horas. Puede iniciar sesión manualmente a través de su navegador, o puede automatizar este inicio de sesión en el panel de control.
- Rutas: Las rutas absolutas a los archivos de su sitio web han cambiado. Antes, tenían el formato
/home/members/<membername>/sites/<site-domain>/web. Ahora, tienen el formato/home/sitios/<web-id>/web. Cuando movemos los sitios web a la nueva infraestructura, hemos automatizado el proceso de encontrar las antiguas rutas en sus archivos de configuración y actualizarlas a las nuevas rutas, pero esta automatización no es perfecta, por lo que es posible que tenga que revisar sus archivos de configuración para asegurarse de que se han actualizado correctamente. - Trabajos programados: Los trabajos programados ahora utilizan temporizadores systemd en lugar de cron. Al mover sus trabajos programados hemos automatizado el proceso de conversión de cron a temporizadores systemd, sin embargo, es posible que desee revisar sus nuevos trabajos programados para asegurarse de que funcionan correctamente.
Afortunadamente, la nueva infraestructura trae algunas mejoras bienvenidas a la experiencia del desarrollador web:
- Ahora, puedes tener tantas cuentas de usuario ssh y sftp diferentes como quieras - todas ellas tendrán acceso al sitio web sin problemas molestos de permisos. Esto significa que puede proporcionar acceso ssh o sftp a un desarrollador web sin darle acceso a su panel de control.
- Los trabajos programados ahora soportan servicios systemd. Eso significa que si su sitio web depende de un servicio que se ejecuta siempre (como una aplicación nodejs o django) puede configurar un trabajo programado para ejecutar ese servicio. El servicio se ejecutará como un servicio systemd - asegurando que se reinicie si el servidor se reinicia. Además, puede comprobar la salida del servicio iniciando sesión a través de ssh y ejecutando los comandos
journcalctl --userosystemctl --user.
¶ ¿Cuándo se está produciendo este cambio?
El cambio en la base de datos comenzó en 2020, pero sólo para unos cuantos miembros para que tuviéramos tiempo de sobra para probar los resultados. Los cambios en el correo electrónico comenzaron a finales de 2022, pero también sólo para unos cuantos miembros (y para todos los buzones nuevos).
Durante la segunda mitad de 2023 trasladaremos de forma más activa a los miembros existentes a la nueva base de datos e infraestructura de correo electrónico. Estos cambios deberían ser transparentes para ti, ya que todo funcionará como antes.
En cuanto a los cambios del sitio web, también trasladaremos a los miembros durante la segunda mitad de 2023, pero nos pondremos en contacto personalmente con todos los miembros antes del traslado de sus sitios web para que conozcan la fecha con antelación y puedan asegurarse de que están preparados para el cambio en el flujo de trabajo.