Skaler VPN-økter etter rolle, og kontroller deretter feilreserven

Du legg til ein andre gateway, konsollen viser to friske medlemmer, og økttaket flyttar seg knapt, fordi ingenting fortalde klientane korleis dei skulle nå den nye boksen. Å skalere ein VPN-teneste er to avgjerder i rekkjefølgje: kva mekanisme som fordeler klientar for denne tilkoplingstypen, og kor mykje kapasitet som står att etter det verste einskildtapet. Tek du dei i motsett rekkjefølgje, får du eit design som ser overflødig ut og sviktar nettopp når det trengst. Start ved konsollen, og gjer deretter reknestykket.

Tilpass mekanismen til økttypen

Fjernbrukarar, site-til-site-partnarar og alltid-på-einings tunnellar er ikkje utbyttelege økter. Ein distribusjonsfunksjon bygd for ein av dei omdirigerer normalt ein klient under forhandlinga, noko som ikkje tyder noko for ein partnar som allereie har ei fast adresse og ein statisk konfigurasjon.

Cisco sin rettleiar for høg tilgjengelegdom av ASA held tre eigenskapar fråskilde: lastfordeling for fjernåtkomst-VPN, tilstandsbasert failover og site-til-site-klynging. Berre den første flyttar ein eigna klient frå ein gruppeoppføring til eit medlem, og LAN-til-LAN-samband held seg utanfor den fordelinga. Ein generisk TCP-lastbalansar kan ikkje erstatte protokollen sin eigen omdirigeringssteg, fordi tunnelhandtrykket ikkje er vanleg HTTP som ein proxy kan skrive om. Det praktiske resultatet er ein lastbalansar som godtek sambandet og likevel lèt klienten utan å kunne tunnelere.

Les funksjonslista mot økttypen din før du bestiller ein ekstra eining. Lisenslinja og mekanismelinja er separate oppføringar, og den eine føreset ikkje den andre.

Rekn gjennom dømet i staden for å gisse

Føreset at tre gatewayar kvar er validerte på 800 samtidige tunnellar under arbeidslasta du godkjende, som til saman er 2,400. Eit mål på 1,650 i rushtida ser komfortabelt ut til éi eining blir borte, og då må det overlevande paret halde 1,650 mot ein hard 1,600. Designet har allereie svikta, og ingen failover-justering reparerer aritmetikken.

Set målet slik at det overlevande settet framleis innfrir det, noko som for ei gruppe på tre medlemmer tyder å halde seg under to tredelar av totalen. Det tilhøvet er ein eigenskap ved aritmetikken og ikkje ved noko produkt, så rekn det ut på nytt når den validerte verdien til eit medlem endrar seg. Hald det lisensierte talet, det dokumenterte maksimumet og din eigen målte verdi i tre kolonnar, fordi dei sjeldan er samde og den minste styrer. Ein fjerde kolonne for den observerte rushspissen held planen ærleg etter den første månaden.

Budsjetter attkoplingsbølgja, ikkje berre den stabile tilstanden

Økter på eit svikta medlem dukkar ikkje stille opp ein annan stad. Avhengig av mekanismen fell dei over med tilstand, forhandlar dei på nytt frå null, eller ventar dei på at programmet prøver igjen etter sin eigen plan.

Nokre tusen klientar som prøver igjen innan eitt minutt er ei anna hending enn ein stabil 1,650, og autentiseringsserverane kjenner det først. Sjekk også plassen i poolen, sidan omdirigeringa ikkje spør han: eit medlem som ikkje kan tildele ei adresse, godtek klienten likevel og slepp så trafikken hans.

Stadfest kapasiteten med poolen og ruta ved handa

Verifisering er ei rein leseøving som fangar dei fleste designfeila før eit vedlikehaldsvindauge opnar. Samle poolen per medlem, talet på levande økter og ruta tilbake til klientens subnett, og samanlikn kvar med planen. Poolutmating og ei manglande returrute viser seg begge som ein klient som autentiserer seg og deretter mistar trafikk.

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

Køyr dei lesingane mot kvart medlem i ein normal rushtime i staden for ein roleg. Eit medlem som rapporterer økter men ikkje har ledige adresser, er allereie på den praktiske grensa si, kva lisensen enn seier. Noter firmwareversjonen ved sida av kvar utskrift, sidan kommandonamn flyttar seg mellom utgivingar.

Øv tapet éin gong med vilje, utanfor kontortid, og registrer kva dei overlevande medlemmene rapporterer medan det skjer. Eit medlem som godtek omdirigeringa men ikkje har plass i poolen, viser seg som mislukka tildeling, noko ekstra bandbreidd aldri rettar. Lagre dei validerte tala med datoen ved sida av planen, slik at neste kapasitetsgjennomgang startar med prov i staden for eit lisensrekneskap. Legg resultatet av den øvinga til same sida, jamvel når tala stemmer med planen.