Er ein Raspberry Pi nok for VPN-en til kontoret? Definer arbeidet

Ein Raspberry Pi på fire gigabyte er ei maskinbeskriving, ikkje eit kontorkrav. Han kan tene ei handfull fjernbrukarar godt, og han kan kollapse allereie den fyrste ettermiddagen nokon kopierer ei stor fil gjennom tunnelen. Minnetalet kan ikkje seie deg kven av dei to som skjer. Å gjere innkjøpet om til ein aksepttest byter ut den uvisse med eit resultat du kan forsvare.

Gjer spørsmålet om til ein aksepttest

Ein aksepttest namngir arbeidet, vilkåra og beståingsgrensa før noko maskinvare kjem. For ein VPN-gateway er arbeidet eit sett samtidige aktivitetar, og vilkåra er banane og tenestene som er involverte. Beståingsgrensa er det ein brukar ville kalle brukbart, ikkje det ein benchmark rapporterer. Utan alle tre har eit tal inga påstand bak seg.

Skriv testen slik at nokon andre kan køyre han. Den eine avgrensinga fjernar dei fleste av dei uklare kriteria som gjer at desse avgjerdene dreg ut i veker. Ho gjer òg resultatet samanliknbart når neste gjennomgang kjem.

Resultatet kan rettferdiggjere Pi-en, eit anna apparat eller ei styrt teneste. Alle tre er legitime svar på same spørsmål. Testen avgjer mellom dei, og databladet gjer det ikkje.

Skriv ned arbeidet, ikkje talet på personar

Skil aktivitetane i staden for å telje brukarar. Å opne ein webapplikasjon, kopiere ei stor fil og køyre ein interaktiv terminal legg svært ulike lastar på same gateway. Noter kven som overlappar i ein normal time, fordi overlapp er det som gjer tre enkle oppgåver til éi vanskeleg.

Registrer òg retninga. Fjernbrukarar som lastar ned frå ein filserver på kontoret brukar oppstraumslinja til kontoret, og ei snøgg klienttilkopling kan ikkje vega opp for ein avgrensa bane i den andre enden.

Viss tunnelen òg ber vanleg surfing, ta den trafikken med i testen. Berre privat tilgang undervurderer kva gatewayen vil sjå når kontoret byrjar å bruke han til alt.

Mål det sette saman apparatet

Test den versjonen, protokollen og autentiseringa du planlegg å rulle ut. Noter kva pakkebehandlingsbane som er aktiv i staden for å låne ein benchmark frå eit anna bygg. Kapasiteten er avhengig av den bana, så ein observasjon frå ei anna skildrar eit anna system. Poenget er å måle din konfigurasjon, ikkje den beste som er tilgjengeleg.

Ta med tenestene som skal dele kortet. DNS-filtrering, overvaking eller lagring kappast alle om den same prosessoren og minnet, og ein gateway målt åleine er ikkje den gatewayen du vil køyre.

Fylg med på prosessoraktivitet, minnetrykk, grensesnittfeil og fullføringstider under varig arbeid. Hald kryptering og tilgangskontrollar på heile tida, fordi eit tal utan dei skildrar ei teneste ingen har godkjent.

Avgjer nedetidsbudsjettet før maskinvara

Éin billeg gateway er eit rimeleg val når nedetida er til å leve med og attopprettinga er enkel. Skriv ned den aksepterte nedetida og kven som kan attopprette konfigurasjonen, byte lagring og trekkje attende ein tapt klient. Dei handlingane avgjer kor lenge ei nedetid eigentleg varer. Ingen av dei står på eit datablad.

Viss administratoren berre når gatewayen gjennom den same tunnelen, planlegg ei sjølvstendig attopprettingsrute. Eit reservekort der konfigurasjonen og nøklane ikkje kan attopprettast, og som ingen eig, er ikkje ein attopprettingsplan.

Namngje personen, ikkje teamet. Attoppretting som er avhengig av ei gruppe, er attoppretting som ventar på at gruppa skal vere tilgjengeleg. Namnet er òg det som gjer planen testbar.

Vel det minste systemet som står

Vel det minste vedlikehaldne systemet som står dei erklærte krava med margin. Meir minne hjelper når minnet er avgrensinga, og gjer ingenting for ein bane som alt er metta. Marginen bør vere ein oppgitt del, ikkje eit adjektiv. Då har neste oppgradering òg eit kriterium.

Noter arbeidslasta, resultatet og datoen ved sida av utrullinga. Det neste kapasitetsspørsmålet startar då frå prov, ikkje frå eit datablad. Den noteringa er skilnaden mellom ei avgjerd og eit gjet.