I-scale ang mga session ng VPN ayon sa papel, pagkatapos suriin ang reserba sa pagkabigo

Magdadagdag ka ng pangalawang gateway, nagpapakita ang console ng dalawang malusog na miyembro, at halos hindi gumagalaw ang kisame ng session, dahil walang nagsabi sa mga kliyente kung paano marating ang bagong kahon. Ang pag-scale ng serbisyo ng VPN ay dalawang desisyon nang sunod-sunod: aling mekanismo ang namamahagi ng mga kliyente para sa ganitong uri ng koneksyon, at gaano karaming kakayahan ang natitira pagkatapos ng pinakamasamang nag-iisang pagkawala. Kung gagawin mo ito sa kabaligtarang ayos, makakakuha ka ng disenyo na mukhang sobra at nabigo mismo kapag kailangan ito. Magsimula sa console, pagkatapos gawin ang aritmetika.

Itugma ang mekanismo sa uri ng session

Ang mga malayong gumagamit, mga kapares sa pagitan ng mga site at mga tunnel ng device na laging naka-on ay hindi palit-palit na session. Ang isang tampok na pamamahagi na ginawa para sa isa sa kanila ay karaniwang nagre-redirect ng kliyente sa panahon ng negosasyon, na walang ibig sabihin sa isang kapares na mayroon nang nakapirming address at static na configuration.

Ang gabay sa mataas na pagiging maaasahan ng ASA ng Cisco ay naghihiwalay ng tatlong kakayahan: pagbabalanse ng kargada ng VPN para sa malayong pag-access, failover na may estado at clustering sa pagitan ng mga site. Ang una lamang ang naglilipat ng karapat-dapat na kliyente mula sa isang entry ng grupo patungo sa isang miyembro, at ang mga koneksyon na LAN-sa-LAN ay nananatili sa labas ng pamamahaging iyon. Ang pangkalahatang TCP load balancer ay hindi maaaring pumalit sa sariling hakbang ng redirection ng protocol, dahil ang handshake ng tunnel ay hindi simpleng HTTP na maaaring muling isulat ng isang proxy. Ang praktikal na resulta ay isang balancer na tumatanggap ng koneksyon at hinahayaang hindi pa rin makagawa ng tunnel ang kliyente.

Basahin ang listahan ng tampok laban sa iyong uri ng session bago mag-order ng pangalawang aparato. Ang linya ng lisensya at ang linya ng mekanismo ay magkahiwalay na entry, at ang isa ay hindi nagpapahiwatig ng isa pa.

Pag-aralan ang halimbawa sa halip na manghula

Ipagpalagay na tatlong gateway ang bawat isa ay napatunayan sa 800 magkakasabay na tunnel sa ilalim ng kargang inaprubahan mo, na 2,400 sa kabuuan. Ang target na 1,650 sa oras ng kasagsagan ay mukhang komportable hanggang mawala ang isang yunit, at pagkatapos ay dapat hawakan ng natitirang pares ang 1,650 laban sa matigas na 1,600. Nabigo na ang disenyo, at walang pagsasaayos ng failover ang nag-aayos ng aritmetika.

Itakda ang target upang ang natitirang set ay matugunan pa rin ito, na para sa isang grupo ng tatlong miyembro ay nangangahulugang manatili sa ilalim ng dalawang-katlo ng kabuuan. Ang proporsyon na iyon ay katangian ng aritmetika at hindi ng anumang produkto, kaya muling kalkulahin ito kapag nagbago ang napatunayang bilang ng isang miyembro. Itago ang lisensyadong bilang, ang dokumentadong maximum at ang iyong sariling sinusukat na bilang sa tatlong kolum, dahil bihirang magkasundo ang mga ito at ang pinakamaliit ang namamahala. Ang ikaapat na kolum para sa naobserbahang tugatog ng oras ng kasagsagan ay nagpapanatili ng katapatan ng plano pagkatapos ng unang buwan.

Buwisan ang pagsabog ng muling pagkonekta, hindi lamang ang matatag na kalagayan

Ang mga session sa isang bigong miyembro ay hindi tahimik na muling lumilitaw sa ibang lugar. Depende sa mekanismo, lumilipat sila nang may estado, muling nakikipag-usap mula sa simula, o naghihintay na muling subukan ng aplikasyon ayon sa sarili nitong iskedyul.

Ang ilang libong kliyente na muling sumusubok sa loob ng isang minuto ay ibang pangyayari kaysa sa matatag na 1,650, at ang mga authentication server ang unang nakakaramdam nito. Suriin din ang puwang ng pool, dahil hindi ito kinokonsulta ng redirection: ang isang miyembro na hindi makapaglaan ng address ay tumatanggap pa rin ng kliyente at pagkatapos ay itinatapon ang trapiko nito.

I-verify ang kakayahan taglay ang pool at ruta

Ang pagpapatunay ay isang pagsasanay na pagbabasa lamang na humuhuli sa karamihan ng mga pagkakamali sa disenyo bago magbukas ang isang window ng maintenance. Kolektahin ang pool ng bawat miyembro, ang bilang ng mga aktibong session at ang ruta pabalik sa subnet ng kliyente, pagkatapos ay ihambing ang bawat isa sa plano. Ang pagkaubos ng pool at nawawalang ruta ng pagbabalik ay parehong lumilitaw bilang isang kliyenteng nagpapatunay at pagkatapos ay nawawalan ng trapiko.

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

Patakbuhin ang mga pagbabasang iyon sa bawat miyembro sa normal na oras ng kasagsagan at hindi sa tahimik na oras. Ang isang miyembrong nag-uulat ng mga session ngunit walang libreng address ay nasa praktikal na hangganan na nito, anuman ang sabihin ng lisensya. Tandaan ang bersyon ng firmware sa tabi ng bawat output, dahil nagbabago ang mga pangalan ng utos sa pagitan ng mga release.

Sanayin ang pagkawala nang isang beses nang sinasadya, labas ng oras ng trabaho, at itala kung ano ang iniuulat ng mga natitirang miyembro habang nangyayari ito. Ang isang miyembrong tumatanggap ng redirection ngunit walang puwang sa pool ay lumilitaw bilang nabigong paglalaan, na hindi kailanman inaayos ng dagdag na bandwidth. Itago ang mga napatunayang bilang kasama ang petsa sa tabi ng plano, upang ang susunod na pagsusuri ng kakayahan ay magsimula sa ebidensya at hindi sa spreadsheet ng lisensya. Idagdag ang resulta ng pagsasanay na iyon sa parehong pahina, kahit na tumutugma ang mga bilang sa plano.