Räcker en Raspberry Pi för kontorets VPN? Definiera arbetet

En Raspberry Pi på fyra gigabyte är en maskinbeskrivning, inte ett kontorskrav. Den kan betjäna en handfull fjärranvändare väl, och den kan kollapsa redan första eftermiddagen när någon kopierar en stor fil genom tunneln. Minnesiffran kan inte säga vilket av de två som inträffar. Att göra inköpet till ett acceptanstest ersätter den osäkerheten med ett resultat du kan försvara.

Gör frågan till ett acceptanstest

Ett acceptanstest namnger arbetet, förutsättningarna och godkännandegränsen innan någon hårdvara anländer. För en VPN-gateway är arbetet en uppsättning samtidiga aktiviteter, och förutsättningarna är de banor och tjänster som ingår. Godkännandegränsen är vad en användare skulle kalla användbart, inte vad ett riktmärke rapporterar. Utan alla tre har en siffra inget påstående.

Skriv testet så att någon annan kan köra det. Den enda begränsningen tar bort de flesta vaga kriterier som gör att dessa beslut drar ut i veckor. Den gör också resultatet jämförbart när nästa granskning kommer.

Resultatet kan motivera Pi:n, en annan apparat eller en hanterad tjänst. Alla tre är legitima svar på samma fråga. Testet avgör mellan dem, och databladet gör det inte.

Skriv ned arbetet, inte antalet personer

Separera aktiviteterna i stället för att räkna användare. Att öppna en webbapplikation, kopiera en stor fil och köra en interaktiv terminal lägger mycket olika belastning på samma gateway. Notera vilka som överlappar under en normal timme, eftersom överlappningen är det som gör tre lätta uppgifter till en svår.

Registrera också riktningen. Fjärranvändare som hämtar från en filserver på kontoret använder kontorets uppströmslänk, och en snabb klientanslutning kan inte kompensera en begränsad bana i andra änden.

Om tunneln också bär vanligt surfande, ta med den trafiken i testet. Enbart privat åtkomst underskattar vad gatewayen kommer att se när kontoret börjar använda den till allt.

Mät den sammansatta apparaten

Testa den version, det protokoll och den autentisering du tänker driftsätta. Notera vilken paketbehandlingsbana som är aktiv i stället för att låna ett riktmärke från ett annat bygge. Kapaciteten beror på den banan, så en observation från en annan beskriver ett annat system. Poängen är att mäta din konfiguration, inte den bästa som finns.

Ta med de tjänster som ska dela kortet. DNS-filtrering, övervakning eller lagring konkurrerar alla om samma processor och minne, och en gateway som mäts ensam är inte den gateway du kommer att driva.

Följ processoraktivitet, minnestryck, gränssnittsfel och slutförandetider under varaktigt arbete. Håll kryptering och åtkomstkontroller på hela tiden, eftersom en siffra utan dem beskriver en tjänst som ingen har godkänt.

Bestäm avbrottsbudgeten före hårdvaran

En enda billig gateway är ett rimligt val när avbrottet är tolererbart och återställningen enkel. Skriv ned den accepterade stilleståndstiden och vem som kan återställa konfigurationen, byta lagring och återkalla en förlorad klient. Det är de åtgärderna som avgör hur länge ett avbrott egentligen varar. Ingen av dem står på ett datablad.

Om administratören bara når gatewayen genom samma tunnel, planera en oberoende återställningsväg. Ett reservkort vars konfiguration och nycklar inte kan återställas och som ingen äger är ingen återställningsplan.

Namnge personen, inte teamet. Återställning som beror på en grupp är återställning som väntar på att gruppen ska vara tillgänglig. Namnet är också det som gör planen testbar.

Välj det minsta system som klarar sig

Välj det minsta underhållna system som klarar de deklarerade kraven med marginal. Mer minne hjälper när minnet är begränsningen, och gör ingenting för en bana som redan är mättad. Marginalen bör vara en angiven andel, inte ett adjektiv. Då har nästa uppgradering också ett kriterium.

Notera arbetsbelastningen, resultatet och datumet bredvid driftsättningen. Nästa kapacitetsfråga börjar då från bevis, inte från ett datablad. Den anteckningen är skillnaden mellan ett beslut och en gissning.