Ninguna parte es un sitio: mudanzas entre centros

Mover un servidor de un bastidor a otro dentro del mismo edificio es un solo acto físico con una sola incertidumbre: ¿está ahí? Eso se modeló hace un tiempo, y lo interesante resultó ser el instante en que el destino no está ni reservado ni ocupado.

Llevar un servidor a otra ciudad no es ese mismo problema con un abrigo más grande. Es una secuencia de actos en dos lugares, con un intervalo por medio durante el cual la máquina no está en ningún centro de datos, más un lado de red, un lado de direcciones y un lado de agentes que tienen que volver a ser ciertos en el otro extremo. La tentación es reutilizar el traslado existente y quitar la comprobación que obliga a que origen y destino sean la misma sede. No se hizo, y este es el motivo.

Por qué es un segundo objeto y no un indicador

El traslado existente ya tiene origen, destino, una comprobación previa congelada, una reserva en el destino, un contador de comparación y un rastro que solo añade. Lo que parece faltar es una única comprobación de base de datos.

Añadir un indicador fundiría dos máquinas de estados en una que no encaja con ninguna. Un traslado dentro de una sede tiene nueve estados; una mudanza entre sedes tiene quince. El primero tiene dos salidas del «no lo sabemos», la segunda tres, y esa tercera es que la máquina se perdió en el camino, algo que entre dos bastidores de la misma sala no puede ocurrir. Y quitar la comprobación dejaría que cualquier traslado existente, incluso uno planificado la semana pasada, cruzara en silencio la frontera de sede.

Se comparte todo lo que de verdad es lo mismo: la misma primitiva de ocupación con su índice único parcial, el mismo historial de ubicación que solo añade y la misma costura de operaciones de iniciar, avanzar y cerrar. Los tipos de entrada del rastro están separados, para que quien lea dentro de un año pueda distinguir si una máquina se corrió dentro de una sala o si pasó una tarde en una furgoneta. Una entrada compartida de «movida» borraría esa diferencia para siempre.

Quince estados, y uno de ellos es ninguna parte

Tres estados administrativos antes de que ocurra nada físico (borrador, planificada, aprobada), nueve fases de trabajo real y tres finales. Las fases son: apagado, desmontaje, tránsito, llegada al destino, montaje, recableado, nueva medición, verificación y el estado en el que nadie sabe.

El estado que sostiene todo el diseño es in_transit. Es el único estado en curso en el que la sede de la máquina está genuinamente vacía, y el código escribe ese vacío en lugar de describirlo: la columna de sede se queda realmente vacía. En una sede, vacío significa normalmente «no establecido», y aquí significa algo más fuerte y más literal. No hay ningún centro de datos donde esté. Está en la carretera.

Sus vecinos no son eso, y a propósito. unracked significa fuera del bastidor pero todavía en el edificio, sobre un carro, así que la sede sigue siendo el origen. destination_claimed significa que llegó al otro extremo pero aún no está en un bastidor, y desde ahí pertenece administrativamente a la sede de destino. Dos fronteras separadas por una hora, y fundirlas dejaría equivocada la respuesta a «dónde está ahora la máquina 41» para una de las dos.

Desde el apagado ya no hay vuelta atrás

Las transiciones están como tabla sobre los quince estados y no como una bifurcación, por la misma razón que en todo este código: una bifurcación con rama por defecto convierte un estado recién añadido en un estado permitido, y un estado que alguien añade porque está pasando algo raro sería el primero al que se le permitiría todo.

La fila que importa sale de approved. Hasta ahí incluido, una mudanza se puede cancelar y a nadie le ha pasado nada. Desde shutting_down en adelante, cancelar desaparece. Alguien ha empezado a desmontar un servicio en marcha de un cliente; una actualización en la base de datos no deshace eso, y fingir lo contrario es una afirmación sobre el mundo físico que nadie ha verificado.

Lo que queda desde cada fase física es la fase siguiente, el «no lo sabemos» y el «salió mal». Cualquier fase física puede llegar al no saber, y eso es distinto del traslado dentro de una sede, donde eso solo se alcanza desde un estado. La razón es el alcance: dentro de una sede hay un instante en que nadie está seguro, y en una mudanza entre sedes hay seis. ¿Sigue en el bastidor viejo? ¿Está en el carro? ¿Está en la furgoneta? ¿Está en el suelo nuevo? ¿Está en el bastidor? ¿Está enchufada?

Cuatro cosas que advierte y nunca arregla

Una mudanza escribe exactamente dos cosas: la sede y la ubicación de la máquina, y la reserva de bastidor. Ninguna dirección, ninguna pertenencia de agente, ninguna VLAN, ningún tejido, ninguna arista de topología.

Esa contención es el requisito de verdad, y es justo donde la respuesta equivocada parece evidente. La máquina se fue a la otra sede, así que seguro que su prefijo de direcciones debería acompañarla. Pues no. Una dirección de un prefijo enrutado en la sede de origen no funciona en la de destino, y qué dirección debería ir allí en su lugar es algo que la plataforma no sabe. Qué agente atiende la sala nueva es una decisión de una persona. Solo la evidencia confirmada puede convertir la topología en verdad.

Cada una de esas cosas se convierte por tanto en una comprobación abierta: medida, registrada y mostrada, nunca ejecutada.

Las dos últimas son honestas sobre estar abiertas de forma permanente en lugar de quedar calladamente en «conforme». Decir que algo está conforme es una afirmación, y nadie la ha hecho.

Esa contención se vigila por la forma y no por la disciplina. Una prueba recorre el árbol sintáctico de los seis archivos de este flujo y falla ante cualquier inserción o actualización en una tabla de direcciones, agentes, red, tejido, servicio o servidores. Se demostró primero en rojo con una escritura plantada. Una segunda prueba, más antigua, hace otra pregunta, la de si un valor de sede salió de un cálculo, y aprobaría sin problema una mudanza que pasa correctamente una sede de destino. Dos preguntas, dos pruebas, y solo juntas cubren la regla.

Tres salidas del no saber

Cuando el resultado físico es incierto, alguien tiene que ir a mirar. Las tres respuestas se registran como observación y no como reversión.

Vista en el destino. La mudanza se cierra, y el rastro lleva «observada en el destino» en vez de «completada», para que siga siendo legible que hubo duda.

Vista en el origen. La reserva del otro extremo se libera y la mudanza termina como fallida y no como cancelada, porque alguien hizo trabajo físico y el traslado no llegó a producirse. La ubicación antigua no se vuelve a abrir, y es deliberado. Si la máquina ya estaba fuera del bastidor, aquellas unidades quedaron libres y puede haber otra cosa colgada ahí; reclamarlas otra vez podría poner dos máquinas en una unidad, exactamente el fallo para el que existe el índice único parcial. La máquina pertenece a la sede de origen y no está en ningún bastidor, y esa es la verdad: está sobre un carro. Devolverla es una ubicación nueva y por tanto un acto propio.

No encontrada en ninguna parte. La reserva en el destino se libera, porque guardar espacio de bastidor para hardware que no va a llegar bloquea a otra persona para nada. La máquina se queda en tránsito sin sede, y la operación termina fallida con su propio bloqueo. No se retira ni se pone en cuarentena, y eso es enfático. Esas son decisiones sobre la máquina, y «perdida» es una observación. Un equipo que aparezca la semana que viene no debería haber desaparecido mientras tanto de todas las listas.

El orden de la comprobación previa, y una cosa sobre sedes

La planificación rechaza en un orden fijo: el equipo existe, no hay ni un traslado ni una segunda mudanza en curso (dos tablas con dos índices parciales que no saben nada la una de la otra), está realmente ubicado en algún sitio, las dos sedes son distintas, la sede de destino está activa, ningún servicio estorba, y el espacio cabe.

Solo el destino tiene que estar activo. Un origen que se está desmantelando no es un obstáculo: es precisamente el motivo por el que la gente muda hardware. Invertirlo bloquearía justo la migración para la que existe la función.

La comprobación de servicio rechaza también en reserved y provisioning, y no solo en activo, lo que primero sorprende y después ya no. Una máquina con una reserva encima está comprometida; lo que hay que cancelar ahí es el pedido, no el viaje de la máquina.

Lo que anotaríamos

1. 01Una forma distinta merece un objeto distinto. Si el caso nuevo tiene seis estados más, una salida más y un periodo de no estar en ninguna parte, un indicador sobre el viejo produce una máquina que no describe ninguno de los dos casos.
2. 02Escriba «ninguna parte» de forma literal. Un valor vacío que significa «en una furgoneta» es más útil que un estado que finge que la máquina sigue en algún sitio.
3. 03Tras trabajo físico reportado, nunca revierta. Añada un estado que signifique «desconocido» y deles salidas documentadas, todas ellas observaciones.
4. 04No reabra un hueco liberado. El espacio que soltó puede estar ocupado. Volver es una ubicación nueva, con la misma comprobación de colisión que cualquier otra.
5. 05Advertir sin arreglar. Una comprobación abierta que resuelve una persona supera a una suposición automática sobre direcciones, VLAN y cableado.
6. 06Vigile la contención con una prueba sobre la forma. «Este flujo nunca escribe en esas tablas» es comprobable; «nos acordaremos de no hacerlo» no.
7. 07Revise la dirección de su regla de sede. Exigir que el origen esté sano prohibiría justo la mudanza que todo el mundo necesita.

Para dejar claro qué es esto: el trabajo de logística de centro de datos está detrás de un interruptor de despliegue apagado por omisión, con un ajuste por organización encima, así que nada de esto se puede comprar hoy. Cuatro cosas están sin demostrar. La migración se aplicó a mano en la base de datos de desarrollo y se revirtió, nunca a través del migrador. La hoja de reconciliación y el botón de cancelar no se condujeron en un navegador. No se midió una petición cruda contra las acciones con el interruptor cerrado. Y nunca se ha observado caducar de verdad una reserva de destino.

Del trabajo de plataforma de Provibr. La versión dentro de una sola sede, y por qué una reserva se convierte en la ubicación en lugar de liberarse y reescribirse, está en la reserva se convierte en la ubicación. Por qué las unidades libres de un bastidor no son lo mismo que capacidad está en el espacio en rack no es capacidad.