Er en Raspberry Pi nok til kontorets VPN? Definer arbejdet

En Raspberry Pi på fire gigabyte er en maskinbeskrivelse, ikke et kontorkrav. Den kan betjene en håndfuld fjernbrugere godt, og den kan bryde sammen allerede den første eftermiddag, nogen kopierer en stor fil gennem tunnelen. Tallet for hukommelse kan ikke fortælle dig, hvilket af de to der sker. At gøre indkøbet til en accepttest erstatter den usikkerhed med et resultat, du kan forsvare.

Gør spørgsmålet til en accepttest

En accepttest navngiver arbejdet, betingelserne og beståelsesgrænsen, før noget hardware ankommer. For en VPN-gateway er arbejdet et sæt samtidige aktiviteter, og betingelserne er de stier og tjenester, der indgår. Beståelsesgrænsen er det, en bruger ville kalde brugbart, ikke det en benchmark rapporterer. Uden alle tre har et tal intet krav bag sig.

Skriv testen, så en anden kan køre den. Den ene begrænsning fjerner de fleste af de vage kriterier, der får disse beslutninger til at trække ud i uger. Den gør også resultatet sammenligneligt, når næste gennemgang kommer.

Resultatet kan retfærdiggøre Pi'en, et andet apparat eller en administreret tjeneste. Alle tre er legitime svar på samme spørgsmål. Testen afgør det, og databladet gør det ikke.

Skriv arbejdet ned, ikke antallet af personer

Adskil aktiviteterne i stedet for at tælle brugere. At åbne en webapplikation, kopiere en stor fil og køre en interaktiv terminal lægger meget forskellige belastninger på samme gateway. Noter, hvilke der overlapper i en normal time, fordi overlap er det, der gør tre nemme opgaver til én svær.

Registrer også retningen. Fjernbrugere, der henter fra en filserver på kontoret, bruger kontorets uplink, og en hurtig klientforbindelse kan ikke opveje en begrænset sti i den anden ende.

Hvis tunnelen også bærer almindelig browsing, skal den trafik med i testen. Adgang alene undervurderer, hvad gatewayen vil se, når kontoret begynder at bruge den til alt.

Mål det samlede apparat

Test den version, protokol og godkendelse, du agter at udrulle. Noter, hvilken pakkebehandlingssti der er aktiv, i stedet for at låne en benchmark fra et andet build. Kapaciteten afhænger af den sti, så en observation fra en anden sti beskriver et andet system. Pointen er at måle din konfiguration, ikke den bedste tilgængelige.

Medtag de tjenester, der skal dele boardet. DNS-filtrering, overvågning eller lagring konkurrerer alle om den samme processor og hukommelse, og en gateway målt alene er ikke den gateway, du vil køre.

Hold øje med processoraktivitet, hukommelsestryk, interfacefejl og gennemførelsestider under vedvarende arbejde. Hold kryptering og adgangskontrol slået til hele tiden, fordi et tal uden dem beskriver en tjeneste, ingen har godkendt.

Beslut nedetidsbudgettet før hardwaren

Én billig gateway er et rimeligt valg, når dens nedetid er tålelig, og gendannelse er enkel. Skriv den accepterede nedetid ned, og hvem der kan gendanne konfigurationen, udskifte lageret og tilbagekalde en tabt klient. De handlinger afgør, hvor længe en nedetid reelt varer. Ingen af dem står på et datablad.

Hvis administratoren kun når gatewayen gennem samme tunnel, skal der planlægges en uafhængig gendannelsesrute. Et reserveboard, hvis konfiguration og nøgler ikke kan gendannes, og som ingen ejer, er ikke en gendannelsesplan.

Navngiv personen, ikke teamet. Gendannelse, der afhænger af en gruppe, er gendannelse, der venter på, at gruppen er tilgængelig. Navnet er også det, der gør planen testbar.

Vælg det mindste system, der består

Vælg det mindste vedligeholdte system, der består de erklærede krav med luft. Mere hukommelse hjælper, når hukommelsen er begrænsningen, og gør intet for en sti, der allerede er mættet. Luften bør være en angivet margen, ikke et tillægsord. Så har næste opgradering også et kriterium.

Noter arbejdsbelastningen, resultatet og datoen ved siden af udrulningen. Den næste kapacitetstanke begynder så ud fra evidens, ikke ud fra et datablad. Den registrering er forskellen mellem en beslutning og et gæt.