Shkallëzoni sesionet VPN sipas rolit, pastaj kontrolloni rezervën e dështimit

Shtoni një gateway të dytë, konsola shfaq dy anëtarë të shëndetshëm dhe tavani i sesioneve mezi lëviz, sepse asgjë nuk u tha klientëve se si të arrijnë kutinë e re. Shkallëzimi i një shërbimi VPN janë dy vendime me radhë: cili mekanizëm shpërndan klientët për këtë lloj lidhjeje dhe sa kapacitet mbetet pas humbjes më të keqe të vetme. Nëse i merrni në rendin e kundërt, merrni një dizajn që duket i tepërt dhe dështon pikërisht kur nevojitet. Filloni nga konsola dhe pastaj bëni aritmetikën.

Përputhni mekanizmin me llojin e sesionit

Përdoruesit në distancë, partnerët mes siteve dhe tunelet e pajisjeve gjithmonë aktive nuk janë sesione të këmbyeshme. Një funksion shpërndarjeje i ndërtuar për njërin prej tyre normalisht ridrejton një klient gjatë negociimit, gjë që nuk do të thotë asgjë për një partner që tashmë ka një adresë fikse dhe një konfigurim statik.

Udhëzuesi i disponueshmërisë së lartë të ASA të Cisco mban tre aftësi të ndara: balancimin e ngarkesës së VPN-së për akses në distancë, failover-in me gjendje dhe grupimin mes siteve. Vetëm i pari zhvendos një klient të përshtatshëm nga një hyrje grupi në një anëtar, dhe lidhjet LAN-në-LAN mbeten jashtë asaj shpërndarjeje. Një balancues TCP i përgjithshëm nuk mund të zëvendësojë hapin e vetë protokollit për ridrejtim, sepse handshake-u i tunelit nuk është HTTP i thjeshtë që një proxy mund ta rishkruajë. Rezultati praktik është një balancues që pranon lidhjen dhe prapë e lë klientin pa mundësi për të krijuar tunel.

Lexoni listën e veçorive kundrejt llojit tuaj të sesionit përpara se të porosisnit një pajisje të dytë. Rreshti i licencës dhe rreshti i mekanizmit janë hyrje të veçanta, dhe njëri nuk nënkupton tjetrin.

Punisojeni shembullin në vend që të hamendësoni

Supozoni se tre gateway-e janë validuar secili në 800 tunele njëkohësisht nën ngarkesën që keni miratuar, që bën 2,400 gjithsej. Një objektiv prej 1,650 në orën e pikut duket i rehatshëm derisa humbet një njësi, dhe atëherë çifti i mbijetuar duhet të mbajë 1,650 kundrejt një 1,600 të fortë. Dizajni tashmë ka dështuar, dhe asnjë rregullim i failover-it nuk e rregullon aritmetikën.

Vendosni objektivin në mënyrë që grupi i mbijetuar ta përmbushë ende, gjë që për një grup me tre anëtarë do të thotë të qëndroni nën dy të tretat e totalit. Ai raport është veti e aritmetikës dhe jo e ndonjë produkti, prandaj rillogariteni sa herë që ndryshon shifra e validuar e një anëtari. Mbani numrin e licencuar, maksimumin e dokumentuar dhe shifrën tuaj të matur në tre kolona, sepse rrallë përputhen dhe më e vogla vendos. Një kolonë e katërt për majën e vëzhguar të orës së pikut e mban planin të ndershëm pas muajit të parë.

Buxhetoni shpërthimin e rilidhjes, jo vetëm gjendjen e qëndrueshme

Sesionet në një anëtar të dështuar nuk rishfaqen në heshtje diku tjetër. Në varësi të mekanizmit, ata kalojnë me gjendje, rinegociojnë nga e para ose presin që aplikacioni të riprovojë sipas kalendarit të vet.

Disa mijë klientë që riprovojnë brenda një minute janë një ngjarje ndryshe nga 1,650 i qëndrueshëm, dhe serverat e vërtetimit e ndjejnë të parët. Kontrolloni edhe hapësirën e pool-it, pasi ridrejtimi nuk e konsulton atë: një anëtar që nuk mund të caktojë një adresë prapë e pranon klientin dhe pastaj e hedh trafikun e tij.

Verifikoni kapacitetin me pool-in dhe rrugën në dorë

Verifikimi është një ushtrim vetëm-leximi që kap shumicën e gabimeve të dizajnit përpara se të hapet një dritare mirëmbajtjeje. Mblidhni pool-in për anëtar, numrin e sesioneve aktive dhe rrugën e kthimit në nënrrjetin e klientit, pastaj krahasoni secilin me planin. Shterimi i pool-it dhe një rrugë kthimi që mungon shfaqen të dyja si një klient që vërtetohet dhe pastaj humbet trafikun.

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

Kryeni ato lexime në çdo anëtar gjatë një ore piku normale dhe jo një ore të qetë. Një anëtar që raporton sesione por nuk ka adresa të lira tashmë është në kufirin e tij praktik, çfarëdo që thotë licenca. Shënoni versionin e firmware-it pranë çdo daljeje, pasi emrat e komandave ndryshojnë mes versioneve.

Ushtrojeni humbjen një herë me qëllim, jashtë orarit të punës, dhe regjistroni çfarë raportojnë anëtarët e mbijetuar ndërsa ndodh. Një anëtar që pranon ridrejtimin por nuk ka hapësirë pool-i shfaqet si caktim i dështuar, të cilin gjerësia e bandës nuk e rregullon kurrë. Ruani shifrat e validuara me datën pranë planit, që rishikimi i ardhshëm i kapacitetit të nisë me prova dhe jo me një fletë licencash. Shtoni rezultatin e atij ushtrimi në të njëjtën faqe, edhe kur shifrat përputhen me planin.