Una migración es un proyecto, no un ticket.
La plataforma de alto tráfico de un editor, rediseñada para escalar, probada bajo carga y trasladada a nuestro bare metal. El impacto visible para el cliente fue una ventana de unos cinco minutos dentro de una operación de dos horas.
En este artículo 4 secciones
- El grupo de sitios de alto tráfico de un gran editor tenía que mudarse de datacenter a nuestro bare metal, rediseñado para escalar por el camino. El tráfico de las noticias de última hora es su negocio, y cada lector vería un mal cutover.
- Diseñamos primero la plataforma: una caché de edge de dos niveles sobre SAN all-flash, un balanceador de carga ajustado para recuentos de conexiones muy altos, una capa de base de datos con separación de lecturas y escrituras y una capa de caché de objetos.
- Después la demostramos con una prueba de carga a escala completa, antes de mover a un solo lector real.
- El cutover fue una operación de dos horas con una ventana DNS visible para el cliente de unos cinco minutos, con una ruta de rollback en cada fase.
Se trata de sitios de noticias y estilo de vida donde el pico de tráfico es el negocio. Una migración que los tumba, o que los levanta más lentos, es visible para cada lector en mitad de una noticia de última hora. Esto nunca iba a ser un ticket. Era un proyecto con una noche de cutover.
Por qué un solo equipo para todo el trabajo
El trabajo necesitaba dos cosas a la vez, de un solo equipo: la ingeniería para rediseñar las capas de caché y de base de datos, y la infraestructura propia (SAN enterprise all-flash, un fabric de red real) donde aterrizarla. Juntamos a los ingenieros y el metal, y la noche del cutover fue responsabilidad nuestra.
La plataforma, tal como se diseñó
La intención del diseño eran tres cosas a la vez: rediseñar para escalar caché y base de datos, hacer el cutover con una ventana mínima y acotada, y llevar cada pieza del nuevo diseño intacta a través del cutover. Esto es en lo que se convirtió.
Caché de edge Varnish de dos niveles
HAProxy delante
ProxySQL en cada nodo web
Clúster Percona XtraDB
Valkey + Sentinel
Lo determinista gana a lo elegante
La base de datos se movió con un hot backup reciente en lugar de con una puesta al día por replicación en vivo. Fue una decisión de diseño con un razonamiento declarado: un backup es determinista, así que lo que hay en el backup es lo que tiene el nuevo clúster, sin estado de replicación que desenredar en el peor momento posible. La ruta más elegante existe, y la descartamos a propósito. En la noche del cutover quiere la mudanza cuyo resultado ya conoce.
Mover los datos deprisa significó retransmitirlos en dos saltos: por internet público hasta un relay de staging, y después por la LAN interna a velocidad de línea, convirtiendo una copia limitada por el cifrado en unos pocos minutos. En el destino, el clúster se reconstruyó desde el backup y se resincronizó nodo a nodo.
Y una sincronización del sistema de ficheros llevaba una lista de exclusiones quirúrgica para que la migración no pudiera pisar la configuración del nuevo hogar: la configuración del puntero a la base de datos, el drop-in de la caché de objetos y el montaje de la caché de dos niveles se preservaron explícitamente. El único fragmento de estado que una restauración de base de datos borra en silencio, la activación del plugin de purga de caché, se había mapeado de antemano con su reactivación lista para dispararse. Eso es lo que significa diseñar el cutover dos veces: una hacia delante, y otra para todo lo que podría morder por el camino.
Los datos, en dos saltos
Internet público hasta un relay de staging, después la LAN interna a velocidad de línea. Minutos, no horas.
Clúster restaurado desde el hot backup
Resincronizado nodo a nodo.
Movimiento del sistema de ficheros, protegido
Una lista de exclusiones protege la nueva arquitectura de ser pisada.
El DNS cambia
La ventana visible: unos cinco minutos.
El único ajuste que se borra en silencio, reactivado
A tiempo, porque se había mapeado de antemano.
“No movimos sus servidores. Reconstruimos su plataforma y la aterrizamos en la nuestra, en una ventana de unos cinco minutos, planificada de antemano.”
En qué se convirtió la relación
La migración fue el punto de entrada, no el final. Los sitios hermanos siguieron el mismo patrón, y la disciplina operativa llegó como parte de la construcción y no como una venta adicional posterior: hot backups frecuentes de la base de datos y snapshots del sistema de ficheros retenidos, cachés de edge ajustadas, una capa de monitorización del rendimiento para toda la flota y validación con pruebas de carga antes del lanzamiento. La relación se asentó en «operamos y hacemos evolucionar la plataforma», no en «la alojamos».
Respuestas directas
¿Pueden migrar un sitio de alto tráfico sin tumbarlo?+
Planificamos una ventana acotada y la declaramos de antemano. En este proyecto: unos cinco minutos de propagación DNS visible para el cliente dentro de una operación de dos horas.
¿Backup y restauración o replicación para migrar una base de datos?+
Ambas son legítimas. Aquí elegimos un hot backup reciente porque es determinista: lo que hay en el backup es lo que tiene el nuevo clúster, sin estado de replicación que desenredar en mitad del cutover. La ruta elegante no siempre es la segura.
¿Qué debe incluir un plan de rollback de migración?+
Una ruta de rollback en cada fase, y una ruta documentada de vuelta al origen hasta que la nueva plataforma se haya ganado la confianza.
¿Rediseñan durante una migración o solo mueven cosas?+
Si la mudanza merece un proyecto, normalmente merece también el rediseño. Esta plataforma ganó por el camino una caché de edge de dos niveles, una capa de base de datos con separación de lecturas y escrituras y una capa de caché de objetos. El lift-and-shift a veces es lo correcto, pero es una decisión, no un valor por defecto.
¿Planifica una mudanza? Tráiganos la plataforma, no un ticket.
Diseño, prueba de carga, playbook de cutover, cuerdas de rollback. Le diremos la ventana honesta antes de la noche, y sujetaremos la red.
Hable con un ingenieroHa llegado al final.
Ponga la lectura a trabajar
¿Qué está ejecutando?
Cuéntenos la carga de trabajo, el tráfico y los requisitos de recuperación. Empiece por el configurador de servidores o repase los detalles con un ingeniero.
Escrito por los ingenieros que construyen y operan la infraestructura que describe.Hable con un ingeniero