Deu comptes inactius costen menys que una còpia de seguretat nocturna que satura el túnel, i el nombre d’usuaris no pot mostrar aquesta diferència. Dimensionar un servidor VPN és una comparació entre dos nombres: la concurrència que realment suporteu i el recurs que s’esgota primer. La majoria d’errors de capacitat neixen d’escollir el primer nombre i no mesurar mai el segon. Feu les dues coses, en aquest ordre, i la decisió de maquinari deixa de ser una conjectura.

Compareu el nombre de comptes amb l’hora punta

El nombre de comptes és una llicència i un límit de suport; l’hora punta és una càrrega. Llisteu la feina que se solapa en aquella hora: trucades, administració remota, baixades grans, còpies de seguretat i les peticions d’aplicacions privades que fan esperar la gent. Després marqueu, per a cada element, si travessa la passarel·la i en quina direcció. Les trucades són simètriques i sensibles al retard, mentre que una còpia de seguretat va en una sola direcció i tolera un inici lent, així que pressionen parts diferents del camí.

La direcció decideix quina connexió importa. L’enllaç ascendent de casa poques vegades és simètric, i una sucursal que baixa coses tot el dia arriba al seu límit descendent molt abans que la passarel·la suï. Escriviu la direcció i l’abast del túnel al costat de cada element, perquè una passarel·la que només porta destinacions privades i una que porta tot el trànsit d’internet són dos problemes de dimensionament diferents.

Afegiu la càrrega de fons com una fila pròpia: actualitzacions de clients, telemetria i tot el que fa l’amfitrió a més d’encaminar. Aquests bytes són fàcils d’oblidar i la mateixa interfície els compta.

Trobeu el recurs que s’esgota abans que l’enllaç

L’enllaç només és un candidat. La feina criptogràfica d’un sol túnel pot ocupar un nucli mentre la interfície queda mig buida, i una cua saturada pot fer inutilitzables les trucades amb una amplada de banda que al gràfic sembla mediocre. Una destinació a una ruta lenta de distància també pot semblar debilitat de la passarel·la des del lloc del client. Tres observacions separen aquests casos, i cap no necessita una prova d’esclat.

ObservationWhat to inspect
one core busy, bytes steadyper-core CPU, implementation, offload status
calls degrade during transfersqueueing and the access link
one remote destination slowthat route and its service

Mesureu amb una transferència que tingueu permís per executar, i afegiu la feina concurrent per passos en lloc de tota alhora. Llegiu la taxa sostinguda i la resposta interactiva juntes, perquè una prova només de pic amaga una sessió que s’ha tornat inutilitzable. Una passarel·la que supera la seva amplada màxima mentre les trucades es trenquen no ha superat la prova.

Després repetiu l’execució amb les càrregues opcionals aturades. Un límit que es mou quan s’atura la còpia de seguretat mai no era el límit de la passarel·la.

Convertiu la comparació en un nombre que pugueu defensar

Trieu el recurs que s’ha esgotat i exposeu el requisit en les seves unitats: nuclis a una utilització objectiu durant l’hora punta, bits per segon en cada direcció, o sessions concurrents sota un límit de retard. Deixeu espai per a actualitzacions, diagnòstic i recuperació, perquè un servidor assegut al seu sostre mesurat no té res per a la feina que el manté en marxa. Després escriviu els nombres al costat de la configuració que els va produir, incloent-hi el nombre de clients i la prova utilitzada.

La xifra d’usuaris per nucli és el nombre menys portàtil d’aquest exercici, perquè pressuposa una barreja de protocols i un perfil de dispositius que el lloc següent no comparteix. Quedeu-vos amb el mesurament i descarteu la fórmula. Quan algú demana capacitat per a cinquanta usuaris més, la resposta honesta és el perfil d’hora punta d’aquests cinquanta, no una multiplicació.

Registreu el temps de resposta així com l’amplada de banda. Una capacitat que només preserva la transferència massiva no és capacitat per a les persones que fan trucades, i la propera revisió preguntarà per la diferència.

Trieu entre escalar verticalment i dividir el paper

Quan el límit mesurat és un nucli, més nuclis a la mateixa velocitat poden no ajudar; un nucli més ràpid o un model de treballadors diferent sí. Quan el límit és la CPU agregada, una instància més gran és la solució directa. Quan el límit és l’enllaç d’accés, cap canvi de servidor ajuda i la comparació acaba al proveïdor. Dividir els papers web i VPN en amfitrions separats compra aïllament a canvi d’una segona superfície de gestió.

Compareu aquestes opcions amb el nombre registrat i no entre elles. Un canvi que duplica un recurs que no era la restricció és cost sense benefici, i el registre és el que us permet dir-ho sense discussió. Torneu a mesurar després del canvi amb la mateixa càrrega, o haureu substituït una conjectura per una altra.

Articles relacionats