Du installerte operativsystemet, herdet tjenesten og holder nøklene, og det begynner å føles som om serveren er din. Den er din slik en leid leilighet er din: dørlåsen er under din kontroll og bygningen ikke. Hypervisoren, nettverket foran instansen og kontoen som kan bygge alt på nytt tilhører noen andre. Den forskjellen avgjør hva en gjenopprettingsplan må dekke, og det er den delen egenhosting endrer minst ved.

Kontoen er det egentlige kontrollplanet

En hostingkonto styrer den virtuelle maskinen, diskene, snapshots, offentlige adresser og nettverksregler. Alt dette kan endres uten å logge på gjesten i det hele tatt, noe som plasserer kontoen utenfor trusselmodellen de fleste VPN-guider beskriver. En perfekt tunnelkonfigurasjon overlever en kontohandling som bytter ut en disk.

Beskytt den kontoen som en egen ressurs: uavhengige legitimasjoner, maskinvarebaserte andre faktorer og et revisjonsspor som noen faktisk leser. Å dele den med samme passordbehandler-oppføring som VPN-tjenesten er feilen som gjør alle andre kontroller irrelevante.

Les leverandørens ansvarsfordeling for det konkrete produktet, ikke for sky generelt. Modellen for delt ansvar er et nyttig eksempel på hvordan lagene er delt, og andre leverandører beskriver egne grenser i stedet for å arve den. Det du ser etter, er hvilke feil du forventes å rette og hvilke du bare kan rapportere.

Infrastrukturhendelser du ikke kan administrere

Livemigrering, vertsvedlikehold, en maskinvarefeil på den fysiske noden og en kapasitetshendelse er alt noe leverandøren håndterer etter sin egen plan. Du kan se en omstart, et kort pakketap eller en adresseendring, og du vil ikke se årsaken. Et design som behandler instansen som et fast punkt, vil tolke hver av dem som en VPN-feil. Riktig tiltak er å gjøre tjenesten tolerant overfor en instans som forsvinner, i stedet for å undersøke en årsak du aldri får se.

Sikkerhetskopier hører til dette laget, ikke til tunnelen. Oppbevar serverkonfigurasjon, identiteter, adresseplan og tillatte ruter et sted som ikke avhenger av at instansen er tilgjengelig, og bekreft at kopien kan gjenopprettes uten den opprinnelige disken.

Adresseatferd fortjener sin egen kontroll. Om en offentlig adresse overlever en stopp, en utskifting eller en sletting, avhenger av hvordan den ble tildelt, og de tre operasjonene er ikke utskiftbare. Skriv ned hvilken du er avhengig av, før en hendelse gjør spørsmålet presserende.

Kontroller hva som overlever en gjenoppbygging

Bygg gjenopprettingsveien mens alt virker. Identifiser konsollen eller tilgangen utenfor båndet som leverandøren tilbyr, bekreft at du når den uten tunnelen, og lagre legitimasjonen et sted som en ødelagt bærbar PC eller en tapt telefon ikke tar med seg. Hvis en lokal brannmur-endring blokkerer tunnelen, er den konsollen den eneste veien tilbake.

curl -s http://169.254.169.254/latest/meta-data/instance-id
curl -s http://169.254.169.254/latest/meta-data/public-ipv4
cloud-init status --long

Metadatatjenesten svarer på spørsmål om instansen som gjesten ellers ikke kan se, og de nøyaktige stiene varierer mellom leverandører og plattformer, så verifiser dem mot dokumentasjonen for produktet du kjører. Kjør deretter én kontrollert gjenoppbygging av en testinstans og mål tiden. En gjenopprettingsprosedyre ingen har utført, er en hypotese.

Legg merke til hva gjenoppbyggingen gjorde med adressen, vertsnøklene, diskidentiteten og alt klientene fester. Klienter som har bufret en vertsnøkkel, vil klage etter en gjenoppbygging, og den klagen er riktig oppførsel og ikke en feil som skal dempes.

Bestem hva egenhosting faktisk endrer

Å kjøre din egen VPN flytter tillit fra en VPN-operatør til en hostingleverandør pluss deg selv. Det er en reell endring, og det er ikke det samme som å fjerne en tredjepart. Hvis poenget var å hindre en kommersiell VPN i å observere trafikk, kan leverandøren fortsatt observere instansens nettverk, disken og faktureringspostene.

Dine egne logger beskriver programvaren din, og de beskriver ikke hver infrastrukturpost leverandøren oppbevarer. Det omvendte er også sant: infrastruktursynlighet beviser ikke hva en leverandør beholder. Begge spørsmålene krever leverandørens policy og din egen konfigurasjon, og ingen av dem besvarer den andre.

Skriv svaret som en arbeidsdeling: hvilket lag sviktet, hvem kan reparere det og hvor lang tid reparasjonen tar. Egenhosting endrer hvem du stoler på, og den nyttige delen av øvelsen er å vite nøyaktig hvilket lag du stoler på dem for.

Relaterte artikler