Škálujte VPN relácie podľa role a potom skontrolujte rezervu pri výpadku
Vyvažovanie vzdialeného prístupu, prepnutie pri poruche a clustering medzi lokalitami sú oddelené mechanizmy. Počítajte, čo prežije výpadok jednej brány, nie celkový počet, ktorý ste kúpili.
Pridáte druhú bránu, konzola ukazuje dvoch zdravých členov a strop relácií sa sotva pohne, pretože nič nepovedalo klientom, ako sa dostať k novému zariadeniu. Škálovanie VPN služby sú dve rozhodnutia v poradí: ktorý mechanizmus rozdeľuje klientov pre tento typ pripojenia a koľko kapacity zostane po najhoršej jednotlivej strate. Keď ich urobíte v opačnom poradí, vznikne návrh, ktorý vyzerá redundantne a zlyhá presne vtedy, keď je potrebný. Začnite pri konzole a potom spočítajte.
Zlaďte mechanizmus s typom relácie
Vzdialení používatelia, partneri medzi lokalitami a trvalo zapnuté tunely zariadení nie sú zameniteľné relácie. Distribučná funkcia postavená pre jeden z nich zvyčajne presmeruje klienta počas vyjednávania, čo pre partnera, ktorý už má pevnú adresu a statickú konfiguráciu, nič neznamená.
Cisco príručka vysokej dostupnosti ASA drží tri schopnosti oddelené: vyvažovanie záťaže VPN pre vzdialený prístup, stavový failover a clustering medzi lokalitami. Iba prvá presúva spôsobilého klienta zo záznamu skupiny na člena a pripojenia LAN-to-LAN zostávajú mimo tejto distribúcie. Všeobecný TCP vyvažovač nemôže nahradiť vlastný krok presmerovania protokolu, pretože handshake tunela nie je obyčajné HTTP, ktoré by proxy mohla prepísať. Praktickým výsledkom je vyvažovač, ktorý spojenie prijme a klient napriek tomu nemôže tunelovať.
Prečítajte si zoznam funkcií proti svojmu typu relácie, než objednáte druhé zariadenie. Licenčný riadok a riadok mechanizmu sú samostatné položky a jeden neznamená druhý.
Prepočítajte príklad namiesto hádania
Predpokladajme, že tri brány sú každá validovaná na 800 súbežných tunelov pri záťaži, ktorú ste schválili, čo je spolu 2,400. Cieľ 1,650 v špičke vyzerá pohodlne, kým sa nestratí jedna jednotka, a potom zostávajúca dvojica musí udržať 1,650 proti tvrdému 1,600. Návrh už zlyhal a žiadne ladenie failoveru aritmetiku nespraví.
Nastavte cieľ tak, aby ho zostávajúca množina stále spĺňala, čo pri trojčlennej skupine znamená zostať pod dvoma tretinami celku. Tento pomer je vlastnosťou aritmetiky, nie produktu, preto ho prepočítajte vždy, keď sa zmení validovaný údaj člena. Držte licencovaný počet, dokumentované maximum a vlastný nameraný údaj v troch stĺpcoch, pretože sa málokedy zhodujú a rozhoduje najmenší. Štvrtý stĺpec pre pozorovanú špičku udrží plán čestný po prvom mesiaci.
Naplánujte nápor opätovného pripojenia, nielen ustálený stav
Relácie na zlyhanom člene sa potichu neobjavia inde. Podľa mechanizmu prejdú so stavom, vyjednajú znova od nuly alebo čakajú, kým aplikácia skúsi znova podľa vlastného rozpisu.
Niekoľko tisíc klientov, ktorí skúšajú znova v priebehu minúty, je iná udalosť ako stabilných 1,650, a autentizačné servery to pocítia prvé. Skontrolujte aj priestor v poole, pretože presmerovanie sa ho nepýta: člen, ktorý nemôže prideliť adresu, klienta napriek tomu prijme a potom zahodí jeho prevádzku.
Overte kapacitu s poolom a trasou pri ruke
Overenie je cvičenie iba na čítanie, ktoré zachytí väčšinu chýb návrhu pred otvorením okna údržby. Zozbierajte pool jednotlivých členov, počet živých relácií a trasu späť do klientskej podsiete a každý údaj porovnajte s plánom. Vyčerpanie poolu aj chýbajúca spiatočná trasa sa prejavia ako klient, ktorý sa autentizuje a potom stratí prevádzku.
show vpn-sessiondb summary
show running-config ip local pool
show vpn load-balancing
show route 10.40.12.0 255.255.255.0
Spustite tieto odpočty na každom člene počas normálnej špičky, nie pokojnej hodiny. Člen, ktorý hlási relácie, ale nemá voľné adresy, je už na svojom praktickom limite, nech licencia hovorí čokoľvek. Poznamenajte verziu firmvéru vedľa každého výstupu, pretože názvy príkazov sa medzi verziami menia.
Vyskúšajte stratu raz zámerne, mimo pracovného času, a zaznamenajte, čo zostávajúci členovia hlásia, kým k nej dochádza. Člen, ktorý prijme presmerovanie, ale nemá miesto v poole, sa prejaví ako neúspešné pridelenie, čo ďalšia šírka pásma nikdy nespraví. Uložte validované údaje s dátumom vedľa plánu, aby ďalšia revízia kapacity začala od dôkazov, nie od licenčnej tabuľky. Pridajte výsledok tejto skúšky na rovnakú stránku, aj keď čísla zodpovedajú plánu.