Da nessuna parte è un luogo: traslochi fra sedi

Spostare un server da un armadio a un altro dentro lo stesso edificio è un solo atto fisico con una sola incertezza: c’è o non c’è. Lo abbiamo modellato tempo fa, e la parte interessante si è rivelata l’istante in cui la destinazione non è né prenotata né occupata.

Portare un server in un’altra città non è lo stesso problema con un cappotto più grande. È una successione di atti in due luoghi, con un intervallo durante il quale la macchina non sta in nessun centro dati, più un lato di rete, un lato di indirizzi e un lato di agenti che devono tornare veri all’altro capo. La tentazione è riusare lo spostamento esistente e lasciar cadere il vincolo che obbliga origine e destinazione alla stessa sede. Non lo abbiamo fatto, ed ecco perché.

Perché è un secondo oggetto e non un contrassegno

Lo spostamento esistente ha già un’origine, una destinazione, una verifica preliminare congelata, una prenotazione a destinazione, un contatore di confronto e una traccia in sola aggiunta. Ciò che sembra mancare è un unico vincolo di base di dati.

Aggiungere un contrassegno fonderebbe due macchine a stati in una che non va bene per nessuna delle due. Uno spostamento dentro una sede ha nove stati; un trasloco fra sedi ne ha quindici. Il primo ha due uscite dal «non lo sappiamo», il secondo ne ha tre, e la terza è che la macchina si è persa per strada, cosa che fra due armadi della stessa sala non può accadere. E togliere il vincolo lascerebbe che ogni spostamento esistente, compreso uno pianificato la settimana scorsa, varcasse in silenzio il confine di sede.

Si condivide tutto ciò che è davvero uguale: la stessa primitiva di occupazione con il suo indice univoco parziale, la stessa cronologia di posizione in sola aggiunta e la stessa cucitura di operazione fatta di avviare, avanzare e chiudere. I tipi di riga della traccia sono separati, così che fra un anno un lettore possa vedere se una macchina è scivolata dentro una sala o se ha passato un pomeriggio in un furgone. Una riga condivisa «spostata» cancellerebbe quella differenza per sempre.

Quindici stati, e uno di essi è da nessuna parte

Tre stati amministrativi prima che accada qualcosa di fisico (bozza, pianificato, approvato), nove fasi di lavoro vero e tre finali. Le fasi sono: spegnimento, smontaggio, trasporto, arrivo a destinazione, montaggio, ricablaggio, nuova misura, verifica e lo stato in cui nessuno sa.

Lo stato che regge l’intero disegno è in_transit. È l’unico stato in corso in cui la sede della macchina è davvero vuota, e il codice scrive quel vuoto invece di descriverlo: la colonna della sede diventa realmente vuota. Su una sede, vuoto di solito significa «non accertato», e qui significa qualcosa di più forte e di più letterale. Non esiste un centro dati in cui si trovi. È in strada.

I suoi vicini non lo sono, e di proposito. unracked significa fuori dall’armadio ma ancora nell’edificio, su un carrello, quindi la sede resta l’origine. destination_claimed significa giunta all’altro capo ma non ancora in un armadio, e da lì in poi appartiene amministrativamente alla sede di destinazione. Due confini a un’ora di distanza, e fonderli renderebbe sbagliata, per uno dei due, la risposta a «dove sta adesso la macchina 41».

Dallo spegnimento non si torna indietro

Le transizioni stanno come tabella su tutti e quindici gli stati e non come una deviazione, per lo stesso motivo valido ovunque in questo codice: una deviazione con ramo predefinito trasforma uno stato appena aggiunto in uno permesso, e uno stato che qualcuno aggiunge perché sta succedendo qualcosa di insolito sarebbe il primo cui è concesso tutto.

La riga che conta parte da approved. Fino a lì compreso un trasloco si può annullare e a nessuno è successo niente. Da shutting_down in poi l’annullamento sparisce. Qualcuno ha cominciato a smontare un servizio in funzione di un cliente; un aggiornamento in banca dati non lo disfa, e fingere il contrario è un’affermazione sul mondo fisico che nessuno ha verificato.

Ciò che resta da ogni fase fisica è la fase successiva, il «non lo sappiamo» e il «è andata male». Qualunque fase fisica può arrivare al non sapere, ed è diverso dallo spostamento dentro una sede, dove ci si arriva solo da uno stato. Il motivo è la portata: dentro una sede c’è un istante in cui nessuno è sicuro, in un trasloco fra sedi ce ne sono sei. È ancora nel vecchio armadio. È sul carrello. È nel furgone. È sul pavimento nuovo. È nell’armadio. È collegata.

Quattro cose che nota e non aggiusta mai

Un trasloco scrive esattamente due cose: la sede e la posizione della macchina, e la prenotazione di armadio. Nessun indirizzo, nessuna appartenenza di agente, nessuna VLAN, nessun tessuto, nessun arco di topologia.

Questa moderazione è il vero requisito, ed è proprio lì che la risposta sbagliata sembra ovvia. La macchina è andata all’altra sede, quindi di sicuro il suo prefisso di indirizzi dovrebbe seguirla. Non deve. Un indirizzo di un prefisso instradato nella sede di origine non funziona in quella di destinazione, e quale indirizzo dovrebbe esserci al suo posto la piattaforma non lo sa. Quale agente serva la nuova sala è la decisione di una persona. Solo una prova confermata può fare della topologia una verità.

Ciascuna di quelle cose diventa perciò una verifica aperta: misurata, annotata e mostrata, mai eseguita.

Le ultime due sono oneste sulla loro apertura permanente invece di restare zitte su «a posto». Dire che qualcosa è a posto è un’affermazione, e nessuno l’ha fatta.

Questa moderazione è sorvegliata dalla forma e non dalla disciplina. Un test percorre l’albero sintattico dei sei file di questo flusso e fallisce davanti a qualunque inserimento o aggiornamento in una tabella di indirizzi, agenti, rete, tessuto, servizio o server. È stato prima dimostrato rosso con una scrittura piantata. Un secondo test, più vecchio, pone un’altra domanda, cioè se un valore di sede provenga da un calcolo, e approverebbe volentieri un trasloco che passa correttamente una sede di destinazione. Due domande, due test, e solo insieme coprono la regola.

Tre uscite dal non sapere

Quando l’esito fisico è incerto, qualcuno deve andare a guardare. Tutte e tre le risposte sono registrate come osservazione e non come ritorno indietro.

Vista a destinazione. Il trasloco si chiude, e la traccia porta «osservata a destinazione» invece di «completata», così resta leggibile che c’era un dubbio.

Vista all’origine. La prenotazione all’altro capo viene liberata e il trasloco finisce come fallito e non come annullato, perché qualcuno ha fatto lavoro fisico e lo spostamento non è avvenuto. La vecchia posizione non viene riaperta, ed è voluto. Se la macchina era già fuori dall’armadio, quelle unità sono state liberate e nel frattempo potrebbe esserci appeso altro; rivendicarle potrebbe mettere due macchine su una sola unità, esattamente l’errore per cui esiste l’indice univoco parziale. La macchina appartiene alla sede di origine e non sta in nessun armadio, e questa è la verità: sta su un carrello. Rimetterla è una posizione nuova e quindi un atto a sé.

Non trovata da nessuna parte. La prenotazione a destinazione viene liberata, perché tenere spazio in armadio per hardware che non arriverà blocca qualcun altro per niente. La macchina resta in trasporto senza sede, e l’operazione finisce fallita con un blocco proprio. Non viene affatto dismessa né messa in quarantena. Quelle sono decisioni sulla macchina, e «persa» è un’osservazione. Un apparato che salti fuori la settimana prossima non dovrebbe nel frattempo essere sparito da ogni elenco.

L’ordine della verifica preliminare, e una cosa sulle sedi

La pianificazione rifiuta in un ordine fisso: l’apparato esiste, non c’è né uno spostamento né un secondo trasloco in corso (due tabelle con due indici parziali che non sanno nulla l’uno dell’altro), è davvero collocato da qualche parte, le due sedi sono diverse, la sede di destinazione è attiva, nessun servizio è d’intralcio, e lo spazio ci sta.

Solo la destinazione deve essere attiva. Un’origine in dismissione non è un ostacolo, è proprio la ragione per cui si trasloca hardware. Rovesciarlo bloccherebbe esattamente la migrazione per cui la funzione esiste.

La verifica di servizio rifiuta anche su reserved e provisioning, e non solo su attivo, cosa che prima ci ha sorpreso e poi non più. Una macchina su cui pesa una prenotazione è impegnata; lì va annullato l’ordine e non il viaggio della macchina.

Cosa metteremmo per iscritto

1. 01Una forma diversa merita un oggetto diverso. Se il caso nuovo ha sei stati in più, un’uscita in più e un periodo di non stare da nessuna parte, un contrassegno su quello vecchio produce una macchina che non descrive nessuno dei due casi.
2. 02Scrivete «da nessuna parte» alla lettera. Un valore vuoto che significa «in un furgone» è più utile di uno stato che finge che la macchina sia ancora da qualche parte.
3. 03Dopo lavoro fisico riferito, non tornate mai indietro. Aggiungete uno stato che significhi «ignoto» e dategli uscite documentate, tutte osservazioni.
4. 04Non riaprite un posto liberato. Lo spazio che avete lasciato può essere occupato. Tornare è una posizione nuova, con lo stesso controllo di collisione di qualsiasi altra.
5. 05Notare senza aggiustare. Una verifica aperta che risolve una persona batte una supposizione automatica su indirizzi, VLAN e cablaggio.
6. 06Sorvegliate la moderazione con un test sulla forma. «Questo flusso non scrive mai in quelle tabelle» è verificabile; «ci ricorderemo di non farlo» no.
7. 07Controllate il verso della vostra regola sulle sedi. Pretendere che l’origine sia sana vieterebbe proprio il trasloco di cui tutti hanno bisogno.

Per chiarezza su cosa sia tutto questo: il lavoro di logistica del centro dati sta dietro un interruttore di rilascio spento per impostazione predefinita, con una regolazione per organizzazione sopra di esso, quindi oggi nulla di ciò è acquistabile. Quattro cose non sono dimostrate. La migrazione è stata applicata a mano sulla banca dati di sviluppo e poi ritirata, mai tramite il migratore. La scheda di riconciliazione e il pulsante di annullamento non sono stati guidati in un browser. Non è stata misurata una richiesta grezza verso le azioni con l’interruttore chiuso. E una prenotazione di destinazione non è mai stata osservata scadere davvero.

Dal lavoro di piattaforma di Provibr. La versione all’interno di una sola sede, e perché una prenotazione diventa la posizione invece di essere liberata e riscritta, è spiegata in la prenotazione diventa la posizione. Perché le unità libere in un armadio non sono capacità è spiegato in lo spazio in rack non è capacità.