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

Du legger til en andre gateway, konsollen viser to friske medlemmer, og økttaket flytter seg knapt, fordi ingenting fortalte klientene hvordan de skulle nå den nye boksen. Å skalere en VPN-tjeneste er to beslutninger i rekkefølge: hvilken mekanisme som fordeler klienter for denne tilkoblingstypen, og hvor mye kapasitet som står igjen etter det verste enkelttapet. Tar du dem i motsatt rekkefølge, får du et design som ser overflødig ut og svikter nettopp når det trengs. Start ved konsollen, og gjør deretter regnestykket.

Tilpass mekanismen til økttypen

Fjernbrukere, site-til-site-peers og alltid-på-enhetstunneler er ikke utbyttbare økter. En distribusjonsfunksjon bygget for én av dem omdirigerer normalt en klient under forhandlingen, noe som ikke betyr noe for en peer som allerede har en fast adresse og en statisk konfigurasjon.

Ciscos veiledning for høy tilgjengelighet for ASA holder tre egenskaper atskilt: lastbalansering for fjernaccess-VPN, tilstandsbasert failover og site-til-site-klynging. Bare den første flytter en egnet klient fra en gruppeoppføring til et medlem, og LAN-til-LAN-forbindelser holder seg utenfor den fordelingen. En generisk TCP-lastbalanser kan ikke erstatte protokollens eget omdirigeringstrinn, fordi tunnelhåndtrykket ikke er vanlig HTTP som en proxy kan skrive om. Det praktiske resultatet er en lastbalanser som godtar forbindelsen og likevel lar klienten ikke kunne tunnelere.

Les funksjonslisten mot økttypen din før du bestiller en ekstra enhet. Lisenslinjen og mekanismelinjen er separate oppføringer, og den ene forutsetter ikke den andre.

Regn gjennom eksempelet i stedet for å gjette

Anta at tre gatewayer hver er validert på 800 samtidige tunneler under arbeidslasten du godkjente, som til sammen er 2,400. Et mål på 1,650 i rushtiden ser komfortabelt ut til én enhet går tapt, og da må det overlevende paret holde 1,650 mot en hard 1,600. Designet har allerede sviktet, og ingen failover-justering reparerer aritmetikken.

Sett målet slik at det overlevende settet fortsatt innfrir det, noe som for en gruppe på tre medlemmer betyr å holde seg under to tredeler av totalen. Det forholdet er en egenskap ved aritmetikken og ikke ved noe produkt, så regn det ut på nytt når den validerte verdien til et medlem endres. Hold det lisensierte tallet, det dokumenterte maksimumet og din egen målte verdi i tre kolonner, fordi de sjelden er enige og den minste styrer. En fjerde kolonne for den observerte rushtoppen holder planen ærlig etter den første måneden.

Budsjetter gjenoppkoblingsbølgen, ikke bare den stabile tilstanden

Økter på et sviktet medlem dukker ikke stille opp et annet sted. Avhengig av mekanismen overtas de med tilstand, forhandler på nytt fra null, eller venter på at applikasjonen prøver igjen etter sin egen plan.

Noen tusen klienter som prøver igjen innen ett minutt er en annen hendelse enn en stabil 1,650, og autentiseringsserverne merker det først. Sjekk også plassen i poolen, siden omdirigeringen ikke spør den: et medlem som ikke kan tildele en adresse, godtar klienten likevel og slipper så trafikken dens.

Verifiser kapasiteten med poolen og ruten for hånden

Verifisering er en ren leseøvelse som fanger de fleste designfeilene før et vedlikeholdsvindu åpnes. Samle poolen per medlem, antallet levende økter og ruten tilbake til klientens subnett, og sammenlign hver med planen. Poolutmattelse og en manglende returrute viser seg begge som en klient som autentiserer seg og deretter mister 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

Kjør de lesingene mot hvert medlem i en normal rushtime i stedet for en rolig. Et medlem som rapporterer økter men ikke har ledige adresser, er allerede på sin praktiske grense, uansett hva lisensen sier. Noter firmwareversjonen ved siden av hver utskrift, siden kommandonavn flytter seg mellom utgivelser.

Øv tapet én gang med vilje, utenfor kontortid, og registrer hva de overlevende medlemmene rapporterer mens det skjer. Et medlem som godtar omdirigeringen men ikke har plass i poolen, viser seg som mislykket tildeling, noe ekstra båndbredde aldri retter. Lagre de validerte tallene med datoen ved siden av planen, slik at neste kapasitetsgjennomgang starter med bevis i stedet for et lisensregneark. Legg resultatet av den øvelsen til samme side, selv når tallene stemmer med planen.