Qué hacemos · Datos y web: Capas web de alta disponibilidad, N+1 en cada nivel
Cada capa de su sitio existe al menos dos veces: terminación TLS, caché de páginas, servidor web y PHP. Las direcciones flotantes se mueven solas cuando un nodo falla, y dimensionamos el stack para que funcione a plena velocidad con un nodo de cada nivel ausente.
Qué es: balanceo de carga y clustering para capas web
Una plataforma web para sitios que no pueden estar caídos: noticias, e-commerce, editoriales, front ends de SaaS. El borde termina TLS y cachea páginas, la capa web ejecuta nginx con PHP-FPM, y el conjunto está construido para que perder un nodo, reiniciar uno o parchear uno sea algo que sus visitantes nunca vean.
Cómo lo construimos
Un borde cruzado. Dos nodos de borde por propiedad ejecutan HAProxy para TLS, enrutamiento y health checks, Varnish para la caché de páginas completas, y keepalived para las direcciones flotantes. Cada borde es primario para una dirección pública y standby para la otra, de modo que ambos llevan tráfico todo el tiempo. Un script de salud degrada un borde cuyo HAProxy deja de responder, y el par toma su dirección en segundos.
Una capa web sin favoritos. Detrás del borde, dos o más nodos web ejecutan nginx y PHP-FPM con un pool por sitio, con el mismo peso. La ruta de administración está fijada a un nodo, que es también el origen de una replicación de ficheros en un solo sentido, de modo que las subidas y los cambios de plugins llegan a los demás nodos en segundos sin borrados en conflicto.
Una caché que sirve en medio de los problemas. Varnish está sobre storage all-flash respaldado por SAN con un pool de memoria acotado, lo que le permite guardar muchos más objetos de los que cabrían en RAM prácticamente a la misma velocidad. Si todos los backends están enfermos, Varnish sigue sirviendo la última copia buena de cada página hasta un día. La invalidación de caché la dirigen los eventos del CMS, de modo que un artículo publicado aparece de inmediato en lugar de esperar a un temporizador.
Reinicios que nadie ve. HAProxy reintenta y redistribuye (redispatch) una petición cuando un backend se reinicia, los health checks están ajustados para que la rotación de logs nunca provoque flapping, y PHP-FPM puede reiniciarse un nodo cada vez mientras el borde absorbe el hueco.
Dual-homed en el fabric. Cada nodo web está dual-homed en nuestro fabric con ambos enlaces en uso; cómo se construyen los bonds está en la página del fabric del datacenter.
De qué le protege
- Un único nodo web, de caché o de balanceo que falla o necesita un reinicio.
- Un problema de backend (mantenimiento de la base de datos, un pool de PHP atascado) convertido en una página en blanco: los lectores siguen recibiendo contenido cacheado.
- Reinicios de seguridad y actualizaciones de PHP que producen errores visibles.
- Un pico de tráfico que desborda PHP cuando la mayoría de las peticiones podrían servirse desde la caché.
En la práctica
Probado con carga antes del lanzamiento. En el nuevo par de bordes de una editorial de estilo de vida ejecutamos decenas de miles de usuarios virtuales durante quince minutos, sosteniendo más de diez mil peticiones por segundo con cero errores 503 y cero fallos de salud de backend.
Una actualización de seguridad de PHP en plena jornada. Parcheamos en caliente los dos nodos web de un portal deportivo, un nodo cada vez. El origen vio breves huecos de reinicio de alrededor de un segundo cada uno; el borde reintentó y sirvió contenido cacheado, y el número de errores que recibieron los visitantes fue cero.
Más caché, menos memoria. Pasar un par de bordes de una caché en RAM a storage respaldado por flash liberó una gran cantidad de memoria para otros trabajos.
Por qué EuroVPS
- N+1 en cada capa, incluidos los balanceadores, no solo «dos servidores web detrás de un proxy».
- Failover probado y medido antes de la entrega.
- La caché está diseñada para mantener su sitio en línea cuando el backend no lo está.
- Ajustamos health checks, reintentos y redispatch, los detalles que deciden si un failover de backend es invisible o solo breve.
- Los mismos ingenieros operan la red, el storage y el stack, de modo que nada cae entre equipos.
Preguntas frecuentes
- ¿Necesitamos también un CDN? No para la disponibilidad. Muchos clientes añaden uno por alcance global; el stack funciona con él o sin él, y configuramos Varnish y HAProxy para respetarlo.
- ¿Cuánto tarda un failover del borde? Segundos. Lo medimos en cada construcción y le damos la cifra en la entrega.
- ¿Pueden ejecutar WordPress, Magento y PrestaShop sobre esto? Sí, junto con Laravel y PHP a medida. Cada sitio recibe su propio pool de PHP-FPM.
- ¿Qué pasa con los usuarios identificados y los procesos de pago? Esas peticiones evitan la caché por diseño y se reparten por la capa web. Perder un nodo web mueve las peticiones nuevas a los supervivientes.
- ¿Podemos desplegar código nosotros mismos? Sí. Los despliegues aterrizan en el nodo de administración y se replican hacia fuera, o pasan por su propio pipeline a todos los nodos.
¿Quiere un sitio que siga sirviendo mientras trabajamos en él? Hable con un ingeniero.
Su próximo socio de infraestructura
Veamos su infraestructura.
Cuéntenos qué ejecuta hoy y qué necesita mejorar. Un ingeniero revisará su solicitud y le ayudará a planificar el siguiente paso.
+357 222 32280
Empecemos por su infraestructura.
Un poco de contexto nos ayuda a empezar la conversación adecuada.