Holder en Raspberry Pi til kontorets VPN? Definer arbeidet

En Raspberry Pi på fire gigabyte er en maskinbeskrivelse, ikke et kontorkrav. Den kan betjene en håndfull fjernbrukere godt, og den kan kollapse allerede den første ettermiddagen noen kopierer en stor fil gjennom tunnelen. Minnetallet kan ikke fortelle deg hvilket av de to som skjer. Å gjøre innkjøpet om til en aksepttest erstatter den usikkerheten med et resultat du kan forsvare.

Gjør spørsmålet om til en aksepttest

En aksepttest navngir arbeidet, betingelsene og beståelsesgrensen før noe maskinvare ankommer. For en VPN-gateway er arbeidet et sett samtidige aktiviteter, og betingelsene er banene og tjenestene som er involvert. Beståelsesgrensen er det en bruker ville kalle brukbart, ikke det en benchmark rapporterer. Uten alle tre har et tall ingen påstand bak seg.

Skriv testen slik at noen andre kan kjøre den. Den ene begrensningen fjerner de fleste av de vage kriteriene som gjør at disse beslutningene drar ut i uker. Den gjør også resultatet sammenlignbart når neste gjennomgang kommer.

Resultatet kan rettferdiggjøre Pi-en, et annet apparat eller en administrert tjeneste. Alle tre er legitime svar på samme spørsmål. Testen avgjør mellom dem, og databladet gjør det ikke.

Skriv ned arbeidet, ikke antall personer

Skill aktivitetene i stedet for å telle brukere. Å åpne en webapplikasjon, kopiere en stor fil og kjøre en interaktiv terminal legger svært ulike belastninger på samme gateway. Noter hvilke som overlapper i en normal time, fordi overlapp er det som gjør tre enkle oppgaver til én vanskelig.

Registrer også retningen. Fjernbrukere som laster ned fra en filserver på kontoret bruker kontorets oppstrømskanal, og en rask klientforbindelse kan ikke veie opp for en begrenset bane i den andre enden.

Hvis tunnelen også bærer vanlig surfing, ta den trafikken med i testen. Bare privat tilgang undervurderer hva gatewayen vil se når kontoret begynner å bruke den til alt.

Mål det sammensatte apparatet

Test den versjonen, protokollen og autentiseringen du planlegger å rulle ut. Noter hvilken pakkebehandlingsbane som er aktiv i stedet for å låne en benchmark fra et annet bygg. Kapasiteten avhenger av den banen, så en observasjon fra en annen beskriver et annet system. Poenget er å måle din konfigurasjon, ikke den beste som er tilgjengelig.

Ta med tjenestene som skal dele kortet. DNS-filtrering, overvåking eller lagring konkurrerer alle om den samme prosessoren og minnet, og en gateway målt alene er ikke den gatewayen du vil kjøre.

Følg med på prosessoraktivitet, minnepress, grensesnittfeil og fullføringstider under vedvarende arbeid. Hold kryptering og tilgangskontroller på hele tiden, fordi et tall uten dem beskriver en tjeneste ingen har godkjent.

Avgjør nedetidsbudsjettet før maskinvaren

Én billig gateway er et rimelig valg når nedetiden er til å leve med og gjenopprettingen er enkel. Skriv ned den aksepterte nedetiden og hvem som kan gjenopprette konfigurasjonen, bytte lagring og trekke tilbake en tapt klient. De handlingene avgjør hvor lenge en nedetid egentlig varer. Ingen av dem står på et datablad.

Hvis administratoren bare når gatewayen gjennom den samme tunnelen, planlegg en uavhengig gjenopprettingsrute. Et reservekort der konfigurasjonen og nøklene ikke kan gjenopprettes, og som ingen eier, er ikke en gjenopprettingsplan.

Navngi personen, ikke teamet. Gjenoppretting som avhenger av en gruppe, er gjenoppretting som venter på at gruppen skal være tilgjengelig. Navnet er også det som gjør planen testbar.

Velg det minste systemet som består

Velg det minste vedlikeholdte systemet som består de erklærte kravene med margin. Mer minne hjelper når minnet er begrensningen, og gjør ingenting for en bane som allerede er mettet. Marginen bør være en oppgitt andel, ikke et adjektiv. Da har neste oppgradering også et kriterium.

Noter arbeidsbelastningen, resultatet og datoen ved siden av utrullingen. Det neste kapasitetsspørsmålet starter da fra bevis, ikke fra et datablad. Den noteringen er forskjellen mellom en beslutning og en gjetning.