Méretezze a VPN-munkameneteket szerep szerint, majd ellenőrizze a hibatartalékot

Hozzáad egy második átjárót, a konzol két egészséges tagot mutat, és a munkamenet-plafon alig mozdul, mert semmi nem mondta meg az ügyfeleknek, hogyan érhetik el az új dobozt. Egy VPN-szolgáltatás méretezése két egymást követő döntés: melyik mechanizmus osztja el az ügyfeleket ehhez a kapcsolattípushoz, és mennyi kapacitás marad a legrosszabb egyedi veszteség után. Fordított sorrendben olyan tervet kap, amely redundánsnak látszik, és pontosan akkor hibázik, amikor szükség van rá. Kezdje a konzolnál, majd végezze el a számítást.

Párosítsa a mechanizmust a munkamenet típusához

A távoli felhasználók, a telephelyek közötti partnerek és a mindig bekapcsolt eszköz-alagutak nem csereszabatos munkamenetek. Az egyikükre épített elosztási funkció általában átirányítja az ügyfelet a tárgyalás során, ami semmit nem jelent egy olyan partnernek, amelynek már fix címe és statikus konfigurációja van.

A Cisco ASA magas rendelkezésre állási útmutatója három képességet tart külön: a távoli hozzáférésű VPN terheléselosztását, az állapottartó feladatátvételt és a telephelyek közötti klaszterezést. Csak az első mozgat egy jogosult ügyfelet egy csoportbejegyzésből egy tagra, a LAN-LAN kapcsolatok pedig kimaradnak ebből az elosztásból. Egy általános TCP-terheléselosztó nem helyettesítheti a protokoll saját átirányítási lépését, mert az alagút kézfogása nem egyszerű HTTP, amelyet egy proxy átírhatna. A gyakorlati eredmény egy olyan terheléselosztó, amely elfogadja a kapcsolatot, és az ügyfél mégsem tud alagutat létrehozni.

Olvassa össze a funkciólistát a munkamenet-típusával, mielőtt második eszközt rendel. A licencsor és a mechanizmusor külön bejegyzés, és az egyik nem jelenti a másikat.

Számolja ki a példát találgatás helyett

Tegyük fel, hogy három átjáró egyenként 800 egyidejű alagútra van validálva az Ön által jóváhagyott terhelés mellett, ami összesen 2,400. Az 1,650-es csúcsórai cél kényelmesnek tűnik, amíg el nem veszik egy egység, és akkor a túlélő párnak 1,650-et kell tartania egy kemény 1,600 ellenében. A terv már megbukott, és semmilyen feladatátvételi hangolás nem javítja ki az aritmetikát.

Úgy állítsa be a célt, hogy a túlélő készlet még teljesítse, ami egy háromtagú csoportnál azt jelenti, hogy az összmennyiség kétharmada alatt marad. Ez az arány az aritmetika tulajdonsága, nem pedig egy terméké, ezért számolja újra, amikor egy tag validált száma változik. Tartsa a licencelt számot, a dokumentált maximumot és a saját mért értékét három oszlopban, mert ritkán egyeznek, és a legkisebb az irányadó. Egy negyedik oszlop a megfigyelt csúcsórai csúcsnak segít, hogy a terv az első hónap után is őszinte maradjon.

Az újracsatlakozási rohamra is tervezzen, ne csak az állandósult állapotra

A meghibásodott tag munkamenetei nem bukkannak fel csendben máshol. A mechanizmustól függően állapottal kerülnek át, elölről tárgyalnak, vagy megvárják, hogy az alkalmazás a saját ütemterve szerint újra próbálkozzon.

Néhány ezer ügyfél, amely egy percen belül újra próbálkozik, más esemény, mint egy stabil 1,650, és ezt a hitelesítési kiszolgálók érzik meg először. Ellenőrizze a pool helyét is, mert az átirányítás nem kérdezi meg: egy tag, amely nem tud címet kiosztani, még elfogadja az ügyfelet, majd eldobja annak forgalmát.

Ellenőrizze a kapacitást a poollal és az útvonallal a kezében

Az ellenőrzés csak olvasásból álló gyakorlat, amely a legtöbb tervezési hibát elkapja, mielőtt egy karbantartási ablak kinyílik. Gyűjtse össze a tagonkénti poolt, az aktív munkamenetek számát és az ügyfél alhálózatához visszavezető útvonalat, majd hasonlítsa össze mindegyiket a tervvel. A pool kimerülése és a hiányzó visszatérő útvonal is úgy jelenik meg, mint egy ügyfél, amely hitelesít, majd elveszíti a forgalmát.

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

Futtassa ezeket az olvasásokat minden tagon egy normál csúcsórában, nem egy csendesben. Egy tag, amely munkameneteket jelent, de nincs szabad címe, már a gyakorlati határán van, bármit is mond a licenc. Jegyezze fel a firmware verzióját minden kimenet mellé, mert a parancsnevek kiadások között változnak.

Próbálja ki a veszteséget egyszer szándékosan, munkaidőn kívül, és jegyezze fel, mit jelentenek a túlélő tagok, miközben megtörténik. Egy tag, amely elfogadja az átirányítást, de nincs pool-helye, sikertelen kiosztásként jelenik meg, amit a plusz sávszélesség soha nem javít ki. Tárolja a validált számokat a dátummal a terv mellett, hogy a következő kapacitásfelülvizsgálat bizonyítékokból induljon, ne egy licenctáblázatból. Adja hozzá a gyakorlat eredményét ugyanahhoz az oldalhoz, akkor is, ha a számok megegyeznek a tervvel.