Ventanas de mantenimiento: lo que se hace bajo carga en su lugar

Dos clases de trabajo planificado

El trabajo planificado se divide en dos grupos. El primero lo absorbe el diseño: un controlador de storage que recibe firmware nuevo, un leaf switch que se sustituye, un host de hipervisor que baja para memoria, un par de firewalls que pasan una actualización. El segundo cambia algo que en ese momento no tiene pareja: un cutover de plataforma, la sincronización final de una migración de storage, un cambio de esquema irreversible. El primer grupo se hace bajo carga. El segundo recibe una ventana, y la ventana se diseña en lugar de limitarse a anunciarse.

Lo que absorbe el diseño

Una cabina HPE 3PAR tiene dos nodos controladores que sirven los mismos volúmenes, con cada host conectado a través de dos fabrics Brocade independientes. El firmware entra en un nodo cada vez. Mientras reinicia, la capa multipath de los hosts mantiene la E/S fluyendo por las rutas supervivientes, y el nodo se reincorpora antes de tocar el segundo. El mismo patrón se aplica en cada capa que se construyó en pares. Los leaves Cisco Nexus 9000 se despliegan en pares, con cada host en bond sobre ambos, de modo que un switch puede recibir una actualización o una sustitución mientras el otro enlace lleva el tráfico. Los hosts de hipervisor se vacían con live migration antes de hacerles nada, y las máquinas virtuales vuelven después. Los routers de edge mantienen sesiones con más de un carrier, y una sesión se drena antes de tocar su router.

Nada de esto es inusual en un datacenter serio. Lo que importa es si los pares se ejercitan. Una pareja que existe en el diagrama pero no ha llevado producción es una suposición, y el momento de descubrir que era una suposición no es durante el cambio.

Verifique la pareja antes de tocar el principal

La disciplina útil es la comprobación que ocurre antes del cambio. Antes de bajar un controlador, se pregunta a cada host conectado cuántas rutas activas mantiene hacia la cabina. Un host que informa de una sola ruta se arregla primero, porque para ese host la ventana llegaría sin invitación. Antes de tocar un switch, se lee el bond de cada host para confirmar que ambos miembros están arriba y pasan tráfico, y se confirma que el segundo switch está reenviando y no simplemente encendido. Antes de vaciar un host, se confirma que el destino de la migración tiene margen para lo que viene.

# on each attached host, before controller work: every LUN should show two or more active paths
$ multipath -ll | grep -c 'active ready'

# before switch work: both bond members up and passing traffic
$ grep -E 'Slave Interface|MII Status' /proc/net/bonding/bond0

Después se hace el cambio, y las mismas lecturas se toman de nuevo mientras la pareja se reincorpora. El resultado es trabajo planificado que no le interrumpe, que es distinto del trabajo planificado que no se comunica: el cambio está en nuestro registro y, donde toca su plataforma, en su bandeja de entrada, con el mecanismo indicado.

Los cambios que merecen una ventana

La ventana es la respuesta correcta cuando un paso es irreversible, cuando el componente por su naturaleza no tiene pareja en ese momento, o cuando el procedimiento del fabricante exige que el servicio se detenga. El cutover de plataforma es el caso habitual: en el momento en que el tráfico pasa del entorno antiguo al nuevo, hay un intervalo, normalmente acotado por la propagación del DNS o el movimiento de una VIP, durante el cual el servicio está «en tránsito».

Una ventana bien diseñada se reconoce. Nombra el componente y el mecanismo, para que sepa qué cambia y por qué no puede hacerse bajo carga. Indica el impacto visible para el cliente esperado por separado de la duración de la operación: una operación de dos horas puede tener un impacto visible de minutos, y el aviso dice cuál es cuál. Tiene un punto de decisión y un rollback ensayado, no solo descrito. Se acuerda con usted: si un cambio puede tocar su tráfico, acordamos primero el momento con usted. Y termina con un informe que compara lo real con lo anunciado.

Cómo leer un aviso de mantenimiento

Tres preguntas le dicen la mayor parte de lo que necesita sobre el diseño que hay bajo cualquier plataforma, la nuestra incluida: cuál es el componente, por qué no puede hacerse bajo carga, y cuál es el impacto visible esperado frente a la duración de la operación. Un aviso que responde a las tres es un plan. Los nuestros los escribimos para que las respondan.