Přidáte druhou bránu, konzole ukazuje dva zdravé členy a strop relací se sotva pohne, protože nic neřeklo klientům, jak se dostat k novému zařízení. Škálování VPN služby jsou dvě rozhodnutí v pořadí: který mechanismus rozděluje klienty pro tento typ připojení a kolik kapacity zůstane po nejhorší jednotlivé ztrátě. Když je uděláte v opačném pořadí, vznikne návrh, který vypadá redundantně a selže přesně tehdy, když je potřeba. Začněte u konzole a pak spočítejte.

Slaďte mechanismus s typem relace

Vzdálení uživatelé, partneři mezi lokalitami a trvale zapnuté tunely zařízení nejsou zaměnitelné relace. Distribuční funkce postavená pro jeden z nich obvykle přesměruje klienta během vyjednávání, což pro partnera, který už má pevnou adresu a statickou konfiguraci, nic neznamená.

Cisco průvodce vysokou dostupností ASA drží tři schopnosti oddělené: vyvažování zátěže VPN pro vzdálený přístup, stavový failover a clustering mezi lokalitami. Jen první přesouvá způsobilého klienta ze záznamu skupiny na člena a připojení LAN-to-LAN zůstávají mimo tuto distribuci. Obecný TCP vyvažovač nemůže nahradit vlastní krok přesměrování protokolu, protože handshake tunelu není obyčejné HTTP, které by proxy mohla přepsat. Praktickým výsledkem je vyvažovač, který spojení přijme, a klient přesto nemůže tunelovat.

Přečtěte si seznam funkcí proti svému typu relace, než objednáte druhé zařízení. Řádek licence a řádek mechanismu jsou samostatné položky a jeden neznamená druhý.

Počítejte s příkladem místo hádání

Předpokládejme, že tři brány jsou každá validována na 800 souběžných tunelů při zátěži, kterou jste schválili, což je celkem 2,400. Cíl 1,650 ve špičce vypadá pohodlně, dokud se jedna jednotka neztratí, a pak zbývající dvojice musí udržet 1,650 proti tvrdému 1,600. Návrh už selhal a žádné ladění failoveru aritmetiku nespraví.

Nastavte cíl tak, aby jej zbývající sada stále splňovala, což u tříčlenné skupiny znamená zůstat pod dvěma třetinami celku. Tento poměr je vlastností aritmetiky, nikoli produktu, takže jej přepočítejte, kdykoli se změní validovaný údaj člena. Držte licencovaný počet, dokumentované maximum a vlastní naměřený údaj ve třech sloupcích, protože se málokdy shodují a rozhoduje nejmenší. Čtvrtý sloupec pro pozorovanou špičku udrží plán čestný po prvním měsíci.

Naplánujte nápor opětovného připojení, ne jen ustálený stav

Relace na selhaném členu se tiše neobjeví jinde. Podle mechanismu přejdou se stavem, vyjednají znovu od nuly, nebo čekají, až aplikace zkusí znovu podle svého rozpisu.

Několik tisíc klientů, kteří zkoušejí znovu během minuty, je jiná událost než stabilních 1,650, a autentizační servery to pocítí první. Zkontrolujte také prostor v poolu, protože přesměrování se ho neptá: člen, který nemůže přidělit adresu, klienta přesto přijme a potom zahodí jeho provoz.

Ověřte kapacitu s poolem a trasou po ruce

Ověření je cvičení pouze pro čtení, které zachytí většinu chyb návrhu před otevřením okna údržby. Sesbírejte pool jednotlivých členů, počet živých relací a trasu zpět do klientské podsítě a každý údaj porovnejte s plánem. Vyčerpání poolu i chybějící zpětná trasa se projeví jako klient, který se autentizuje a potom ztratí provoz.

show vpn-sessiondb summary
show running-config ip local pool
show vpn load-balancing
show route 10.40.12.0 255.255.255.0

Spusťte tyto odečty na každém členu během normální špičky, ne klidné hodiny. Člen, který hlásí relace, ale nemá volné adresy, je už na svém praktickém limitu, ať licence říká cokoli. Poznamenejte verzi firmwaru vedle každého výstupu, protože názvy příkazů se mezi verzemi mění.

Vyzkoušejte ztrátu jednou záměrně, mimo pracovní dobu, a zaznamenejte, co zbývající členové hlásí, zatímco k ní dochází. Člen, který přijme přesměrování, ale nemá místo v poolu, se projeví jako neúspěšné přidělení, což další šířka pásma nikdy nespraví. Uložte validované údaje s datem vedle plánu, aby příští revize kapacity začala od důkazů, ne od licenční tabulky. Přidejte výsledek této zkoušky na stejnou stránku, i když čísla odpovídají plánu.

Související články