Nergens is een plek: verhuizen tussen datacenters

Een server van het ene rack naar het andere verplaatsen binnen hetzelfde gebouw is één fysieke handeling met één onzekerheid: staat hij er. Dat hebben wij een tijd geleden gemodelleerd, en het interessante bleek het moment waarop de bestemming niet gereserveerd en niet bezet is.

Een server naar een andere stad brengen is niet datzelfde probleem in een grotere jas. Het is een reeks handelingen op twee plekken, met een periode ertussen waarin de machine in geen enkel datacenter staat, plus een netwerkkant, een adreskant en een agentkant die aan de andere kant opnieuw waar moeten worden. De verleiding is de bestaande verhuizing te hergebruiken en de controle te laten vallen die herkomst en bestemming op dezelfde site houdt. Dat hebben wij niet gedaan, en dit is waarom.

Waarom het een tweede object is en geen vlag

De bestaande verhuizing heeft al een herkomst, een bestemming, een bevroren preflight, een reservering op de bestemming, een vergelijk-en-wissel-teller en een append-only spoor. Wat lijkt te ontbreken is één databasecontrole.

Een vlag toevoegen zou twee statemachines samensmelten tot één die bij geen van beide past. Een verhuizing binnen een site heeft negen standen; een verhuizing tussen sites heeft er vijftien. De eerste heeft twee uitgangen uit "wij weten het niet", de tweede drie, en die derde is dat de machine onderweg kwijt is, wat tussen twee racks in dezelfde zaal niet kán gebeuren. En de controle weghalen zou elke bestaande verhuizing, ook een die vorige week gepland is, stilzwijgend over de sitegrens laten gaan.

Gedeeld wordt alles wat werkelijk hetzelfde is: dezelfde bezettingsprimitieve met zijn partiële unieke index, hetzelfde append-only locatiespoor en dezelfde operationnaad van starten, doorzetten en afsluiten. De soorten spoorregels staan los, zodat een lezer over een jaar kan zien of een machine binnen een zaal opschoof of dat hij een middag in een bus lag. Eén gedeelde regel "verplaatst" zou dat verschil voorgoed wegpoetsen.

Vijftien standen, en een ervan is nergens

Drie administratieve standen voordat er iets fysieks gebeurt (concept, gepland, goedgekeurd), negen fasen echt werk, en drie eindstanden. De fasen zijn: afbouwen, uit het rack, onderweg, aangekomen op de doelsite, in het rack, opnieuw aansluiten, opnieuw meten, bevestigen, en de stand waarin niemand het weet.

De stand die het hele ontwerp draagt is in_transit. Het is de enige lopende stand waarin de site van de machine werkelijk leeg is, en de code schrijft die leegte in plaats van hem te beschrijven: de sitekolom gaat echt op leeg. Leeg op een site betekent normaal "niet vastgesteld", en hier betekent het iets sterkers en letterlijkers. Er is geen datacenter waar hij staat. Hij ligt op de weg.

Zijn buren zijn dat met opzet niet. unracked betekent uit het rack maar nog in het gebouw, op een kar, dus de site blijft de herkomst. destination_claimed betekent aan de overkant maar nog niet in een rack, en vanaf dat punt hoort hij administratief bij de doelsite. Twee grenzen, een uur uit elkaar, en ze samenvoegen zou het antwoord op "waar staat machine 41 nu" voor een van beide fout maken.

Vanaf het afbouwen is er geen weg terug

De overgangen staan als tabel over alle vijftien standen en niet als een switch, om dezelfde reden als overal in deze codebase: een switch met een default maakt van een nieuw toegevoegde stand een toegestane, en een stand die iemand toevoegt omdat er iets ongewoons speelt zou de eerste zijn die alles mag.

De rij die telt vertrekt bij approved. Tot en met die stand kan een verhuizing geannuleerd worden en is er niemand iets overkomen. Vanaf shutting_down is annuleren weg. Iemand is begonnen met het afbouwen van een draaiende dienst van een klant; een database-update maakt dat niet ongedaan, en doen alsof is een bewering over de fysieke wereld die niemand heeft nagekeken.

Wat er vanaf elke fysieke fase overblijft is de volgende fase, "wij weten het niet" en "het is misgegaan". Elke fysieke fase kan naar "wij weten het niet", en dat is anders dan bij een verhuizing binnen een site, waar dat pas vanaf één stand kan. De reden is de reikwijdte: binnen een site is er één moment waarop niemand het zeker weet, en bij een verhuizing tussen sites zijn er zes. Staat hij nog in het oude rack. Ligt hij op de kar. Zit hij in de bus. Staat hij op de nieuwe vloer. Hangt hij in het rack. Zit hij aan.

Vier dingen die zij opmerkt en nooit repareert

Een verhuizing schrijft precies twee dingen: de site en de locatie van de machine, en de rackclaim. Geen adres, geen agentlidmaatschap, geen VLAN, geen fabric, geen topologierand.

Die terughoudendheid is de eigenlijke eis, en juist daar ziet het verkeerde antwoord er vanzelfsprekend uit. De machine ging naar de andere site, dus zijn adresprefix moet zeker meeverhuizen. Dat moet hij niet. Een adres uit een prefix die op de bronsite gerouteerd wordt werkt op de doelsite niet, en welk adres daar wél moet komen weet het platform niet. Welke agent de nieuwe zaal bedient is een keuze van een mens. Alleen bevestigd bewijs mag topologie tot waarheid maken.

Elk van die dingen wordt daarom een open check: gemeten, genoteerd en getoond, nooit uitgevoerd.

Die laatste twee zijn eerlijk over hun permanente openheid in plaats van stil op "in orde" te staan. "In orde" is een uitspraak, en niemand heeft hem gedaan.

Die terughoudendheid wordt bewaakt door vorm en niet door discipline. Een test loopt de syntaxboom van de zes bestanden van deze flow af en faalt op elke insert of update naar een adres-, agent-, netwerk-, fabric-, dienst- of servertabel. Hij is eerst rood bewezen met een geplante schrijfactie. Een tweede, oudere test stelt een andere vraag, namelijk of een sitewaarde uit een berekening komt, en die zou een verhuizing die netjes een doelsite doorgeeft gewoon goedkeuren. Twee vragen, twee tests, en alleen samen dekken ze de regel.

Drie uitgangen uit het niet-weten

Wanneer de fysieke uitkomst onzeker is moet iemand gaan kijken. Alle drie de antwoorden worden vastgelegd als waarneming en niet als terugdraaiing.

Gezien op de doelsite. De verhuizing wordt afgemaakt, en het spoor draagt "waargenomen op de bestemming" in plaats van "voltooid", zodat leesbaar blijft dát er twijfel was.

Gezien op de herkomst. De reservering aan de overkant gaat vrij en de verhuizing eindigt als mislukt en niet als geannuleerd, want iemand heeft fysiek werk gedaan en de verhuizing is er niet van gekomen. De oude plaatsing wordt met opzet niet heropend. Was de machine al uit het rack, dan zijn die units vrijgegeven en kan er intussen iets anders hangen; ze opnieuw claimen zou twee machines op één unit kunnen zetten, precies de fout waarvoor de partiële unieke index bestaat. De machine hoort bij de bronsite en staat in geen enkel rack, en dat is de waarheid: hij staat op een kar. Hem terugzetten is een nieuwe plaatsing en dus een eigen handeling.

Nergens gevonden. De reservering op de doelsite gaat vrij, want rackruimte vasthouden voor hardware die niet komt houdt iemand anders voor niets tegen. De machine blijft onderweg zonder site, en de verhuizing eindigt als mislukt met een eigen blokkade. Hij wordt nadrukkelijk niet afgeschreven of in quarantaine gezet. Dat zijn besluiten over de machine, en "kwijt" is een waarneming. Hardware die volgende week alsnog opduikt hoort niet intussen uit elke lijst verdwenen te zijn.

De volgorde van de preflight, en één ding over sites

De planning weigert in een vaste volgorde: het asset bestaat, er loopt geen verplaatsing en geen tweede verhuizing (twee tabellen met twee partiële indexen die niets van elkaar weten), hij staat werkelijk ergens, de twee sites verschillen, de doelsite is actief, er zit geen dienst in de weg, en de ruimte past.

Alleen de doelsite hoeft actief te zijn. Een bronsite die aan het afbouwen is is geen obstakel maar juist de reden dat mensen hardware verhuizen. Dat omdraaien zou precies de migratie blokkeren waarvoor de functie bestaat.

De dienstcontrole weigert óók op reserved en provisioning en niet alleen op actief, wat ons eerst verbaasde en daarna niet meer. Een machine waar een reservering op ligt is vergeven; wat je daar annuleert is de bestelling en niet de reis van de machine.

Wat wij zouden opschrijven

1. 01Een andere vorm verdient een ander object. Heeft je nieuwe geval zes standen meer, één uitgang meer en een periode van nergens zijn, dan levert een vlag op het oude een machine op die geen van beide gevallen beschrijft.
2. 02Schrijf "nergens" letterlijk op. Een lege waarde die "in een bus" betekent is bruikbaarder dan een stand die doet alsof de machine nog ergens staat.
3. 03Draai na gerapporteerd fysiek werk nooit terug. Voeg een stand toe die "onbekend" betekent en geef hem gedocumenteerde uitgangen, allemaal waarnemingen.
4. 04Heropen een vrijgegeven plek niet. Ruimte die je losliet kan bezet zijn. Teruggaan is een nieuwe plaatsing, met dezelfde botsingscontrole als elke andere.
5. 05Opmerken zonder repareren. Een open check die een mens afhandelt is beter dan een automatische gok over adressen, VLAN's en bekabeling.
6. 06Bewaak terughoudendheid met een test op vorm. "Deze flow schrijft nooit naar die tabellen" is toetsbaar; "wij zullen eraan denken" niet.
7. 07Controleer de richting van je siteregel. Eisen dat de herkomst gezond is verbiedt precies de verhuizing die iedereen nodig heeft.

Voor de duidelijkheid over wat dit is: het datacenterlogistiekwerk zit achter een rolloutschakelaar die standaard uitstaat, met een instelling per organisatie erbovenop, dus hiervan is vandaag niets te koop. Vier dingen zijn onbewezen. De migratie is met de hand op de ontwikkeldatabase toegepast en teruggedraaid, nooit via de migrator. Het reconcile-scherm en de annuleerknop zijn niet in een browser gedreven. Een rauw verzoek aan de actions met de poort dicht is niet gemeten. En een reservering op de doelsite is nooit werkelijk zien verlopen.

Uit het platformwerk van Provibr. De versie binnen één site, en waarom een reservering de plaatsing wórdt in plaats van vrijgegeven en opnieuw geschreven te worden, staat in de verhuisreservering wordt de plaatsing. Waarom vrije units in een rack niet hetzelfde zijn als capaciteit staat in rackruimte is geen capaciteit.