Uživatelé, nebo propustnost? Jak dimenzovat VPN server na skutečnou zátěž

Deset neaktivních účtů stojí méně než jedna noční záloha, která zaplní tunel, a počet uživatelů ten rozdíl neukáže. Dimenzování VPN serveru je srovnání dvou čísel: souběžnosti, kterou skutečně nesete, a prostředku, který dojde první. Většina chyb v kapacitě vzniká tím, že se zvolí první číslo a druhé se nikdy neměří. Udělejte obojí v tomto pořadí a rozhodnutí o hardwaru přestane být odhadem.

Porovnejte počet účtů se špičkovou hodinou

Počet účtů je licence a hranice podpory; špičková hodina je zátěž. Vypište práci, která se v té hodině překrývá: hovory, vzdálenou správu, velká stahování, zálohy a požadavky soukromých aplikací, kvůli nimž lidé čekají. Pak u každé položky označte, zda prochází branou a kterým směrem. Hovory jsou symetrické a citlivé na zpoždění, kdežto záloha je jednosměrná a snese pomalý začátek, takže zatěžují různé části cesty.

Směr rozhoduje, na které lince záleží. Domácí odchozí linka bývá málokdy symetrická a pobočka, která celý den stahuje, narazí na svůj vstupní limit dávno předtím, než se brána začne potit. U každé položky zapište směr a rozsah tunelu, protože brána nesoucí jen soukromé cíle a brána nesoucí veškerý internetový provoz jsou dva různé problémy dimenzování.

Přidejte zátěž na pozadí jako samostatný řádek: aktualizace klientů, telemetrii a vše, co hostitel dělá kromě předávání. Tyto bajty se snadno zapomínají a počítá je stejné rozhraní.

Najděte prostředek, který dojde dřív než linka

Linka je jen jeden kandidát. Kryptografická práce jednoho tunelu dokáže vytížit jedno jádro, zatímco rozhraní zůstává zpola prázdné, a přeplněná fronta může udělat hovory nepoužitelnými při propustnosti, která na grafu vypadá průměrně. Cíl vzdálený jednu pomalou trasu může také vypadat jako slabost brány z křesla klienta. Tyto případy oddělují tři pozorování a žádné z nich nepotřebuje nárazový test.

Měřte přenosem, který smíte spustit, a souběžnou práci přidávejte po krocích, ne najednou. Čtěte udrženou rychlost a interaktivní odezvu společně, protože test jen špičkové rychlosti skrývá relaci, která se stala nepoužitelnou. Brána, která projde svou maximální propustností, zatímco se hovory trhají, test neprošla.

Pak běh zopakujte se zastavenými volitelnými zátěžemi. Limit, který se pohne, když se zastaví záloha, nikdy nebyl limitem brány.

Převeďte srovnání na číslo, které obhájíte

Vyberte prostředek, který došel, a vyjádřete požadavek v jeho jednotkách: jádra při cílovém vytížení během špičkové hodiny, bity za sekundu v každém směru, nebo souběžné relace pod limitem zpoždění. Ponechte prostor pro aktualizace, diagnostiku a obnovu, protože server sedící na svém změřeném stropu nemá nic pro práci, která ho udržuje v chodu. Pak zapište čísla vedle konfigurace, která je dala, včetně počtu klientů a použitého testu.

Počet uživatelů na jádro je v tomto cvičení nejméně přenosné číslo, protože předpokládá směs protokolů a profil zařízení, které další lokalita nesdílí. Ponechte měření a zahoďte vzorec. Když někdo požádá o kapacitu pro dalších padesát uživatelů, poctivá odpověď je špičkový profil těchto padesáti, ne násobení.

Zaznamenejte dobu odezvy i propustnost. Kapacita, která zachová jen hromadný přenos, není kapacitou pro lidi na hovorech a příští revize se na rozdíl zeptá.

Vyberte mezi vertikálním navýšením a rozdělením role

Když je změřeným limitem jedno jádro, více jader stejné rychlosti nemusí pomoci; rychlejší jádro nebo jiný model pracovníků může. Když je limitem celkový procesor, větší instance je přímé řešení. Když je limitem přístupová linka, žádná změna serveru nepomůže a srovnání končí u poskytovatele. Rozdělení webové a VPN role na samostatné hostitele kupuje izolaci za cenu druhé správcovské plochy.

Tyto možnosti porovnávejte se zaznamenaným číslem, ne mezi sebou. Změna, která zdvojnásobí prostředek, jenž nebyl omezením, je náklad bez užitku, a právě záznam vám umožní to říct bez hádky. Po změně změřte znovu se stejnou zátěží, jinak jste jeden odhad nahradili druhým.