Escalado elástico: añadir y quitar servidores de Zaris sin tiempo de inactividad

La capacidad nunca es la adecuada por mucho tiempo. El tráfico crece, llega un lanzamiento, termina una temporada — y el almacén que dimensionaste el trimestre pasado está o bien al límite o bien medio ocioso. La pregunta que decide si eso es una tarea o una crisis es simple: ¿puedes cambiar el tamaño de un almacén en marcha sin tumbarlo?

Para Zaris la respuesta es sí, con una asimetría importante que vale la pena reconocer de entrada. Escalar hacia afuera — añadir servidores — es la dirección fácil, segura y sin pérdidas, y ocurre en vivo mientras el almacén sigue sirviendo. Escalar hacia adentro — quitar servidores — también está soportado, pero es una operación deliberada y monitorizada porque la data del servidor que se va tiene que ir a algún sitio primero.

Este post recorre ambas direcciones: hacer crecer un almacén con Add-ZrServer, reducirlo con Remove-ZrServer, por qué la reducción necesita un drain, y dónde encaja la consola web.

El almacén tiene una forma deseada

Bajo el escalado elástico hay una idea: la forma de un almacén Zaris se describe mediante un StoreDefinition canónico — el conjunto deseado de servidores y particiones que se supone que el almacén debe tener. Es la fuente de verdad de cómo debería verse el clúster, no un recuento en marcha de cómo se ve en este momento.

Zaris corre bajo un modelo de supervisor: el supervisor posee esa definición canónica y conduce continuamente las instancias en marcha hacia ella. Así que escalar no es un montón de pasos manuales que secuencias a mano — cambias la forma deseada, y el supervisor reconcilia el clúster en vivo para que coincida. Add-ZrServer y Remove-ZrServer son cómo un operador edita esa forma deseada, y el supervisor hace el trabajo de llegar hasta ahí.

Escalar hacia afuera: en vivo y sin pérdidas

Añadir capacidad es un único cmdlet. Lo apuntas al almacén y le das el nuevo servidor:

# Grow the store by adding a server to its definition
Add-ZrServer -Store orders -Server zaris-c.example.com:7861

# Check the resulting set
Get-ZrServer -Store orders

Cuando haces esto, el almacén reparticiona en vivo. Las particiones se redistribuyen para que el nuevo servidor tome su parte, la data migra a sus nuevos propietarios, y el almacén sigue sirviendo lecturas y escrituras todo el tiempo — no hay ventana de stop-the-world. En pruebas hemos hecho crecer un almacén de 6 particiones a 8 de esta forma mientras permanecía en línea.

La garantía que importa aquí: el escalado hacia afuera es sin pérdidas. Ninguna escritura confirmada se pierde durante la migración. La data se mueve a los nuevos propietarios, la propiedad se conmuta, y una escritura que el almacén le dijo a un cliente que había comprometido sigue estando ahí al otro lado de la repartición. Eso es lo que hace de añadir capacidad una operación rutinaria — puedes reaccionar a la carga haciendo crecer el almacén durante el tráfico, no durante una ventana de mantenimiento.

Escalar hacia adentro: drain, luego remove

Quitar un servidor es donde aparece la asimetría, y es física, no una limitación que puedas esquivar con un flag. Un servidor que se va está conteniendo data — su parte de las particiones. Si simplemente desapareciera, esa data desaparecería con él.

Así que la reducción es una operación de drain-then-remove, no un apagado instantáneo. Antes de que un servidor saliente se vaya, sus particiones deben migrar su data a los servidores que se quedan. Solo una vez que ese drain del plano de datos se completa, el servidor saliente ha entregado verdaderamente todo lo que tenía bajo su responsabilidad, y solo entonces es seguro que se vaya.

# Remove a server from the store's definition — this initiates the drain
Remove-ZrServer -Store orders -Server zaris-c.example.com:7861

Remove-ZrServer edita la forma deseada para excluir ese servidor, y el supervisor trabaja el almacén hacia la nueva definición moviendo las particiones del servidor saliente a las restantes antes de que salga. El modelo mental a sostener es: subir capacidad es instantáneo y seguro; bajar capacidad es una migración controlada. Trata una reducción como una operación deliberada y monitorizada — arráncala, observa el progreso del drain, y confirma que la data ha aterrizado en los servidores restantes antes de considerar que el servidor se ha ido. Arrancar un servidor sin dejarlo drenar es como pierdes la data que contenía.

Observarlo desde la consola

No tienes que ejecutar nada de esto a ciegas. La consola web tiene una vista de Servers que muestra el conjunto actual de servidores que respaldan un almacén y te deja gestionarlo. Es el lugar natural para:

• Ver el conjunto en vivo — qué servidores están en el almacén ahora mismo, frente a la definición deseada hacia la que el supervisor reconcilia.
• Observar aterrizar un escalado hacia afuera — confirmar que un servidor recién añadido ha tomado sus particiones y está sirviendo.
• Monitorizar un drain de escalado hacia adentro — seguir cómo las particiones de un servidor saliente migran antes de que se vaya, para que sepas que el drain está hecho en lugar de adivinarlo.

Para la reducción en especial, esa visibilidad es la clave. Un drain es un movimiento de data real con un principio y un final, y la vista de Servers es cómo distingues la diferencia.

El resumen honesto

El escalado elástico en Zaris se reduce a editar una forma deseada y dejar que el supervisor reconcilie el almacén en marcha hacia ella:

• Escalar hacia afuera (Add-ZrServer) es la dirección fácil y segura — en vivo, reparticionando en el sitio, y sin pérdidas. Crece con la carga cuando lo necesites.
• Escalar hacia adentro (Remove-ZrServer) está soportado y es seguro cuando lo dejas drenar — la data del servidor saliente migra primero a los supervivientes, así que planifica la bajada de capacidad como una operación deliberada y monitorizada en lugar de un apagado instantáneo.

Dimensiona para el tráfico que tienes, no para el que temías, y cambia de idea después — hacia arriba sin ceremonia, hacia abajo con cuidado.