Escala les sessions VPN per rol i després comprova el marge de fallada

Afegeixes una segona passarel·la, la consola mostra dos membres sans i el sostre de sessions gairebé no es mou, perquè res no ha dit als clients com arribar a la nova màquina. Escalar un servei VPN són dues decisions en seqüència: quin mecanisme distribueix els clients per a aquest tipus de connexió i quanta capacitat queda després de la pitjor pèrdua individual. Si les prens en l'ordre invers, obtens un disseny que sembla redundant i falla exactament quan cal. Comença per la consola i després fes l'aritmètica.

Encarta el mecanisme amb el tipus de sessió

Els usuaris remots, els iguals entre seus i els túnels de dispositiu sempre actius no són sessions intercanviables. Una funció de distribució creada per a un d'ells normalment redirigeix un client durant la negociació, cosa que no significa res per a un igual que ja té una adreça fixa i una configuració estàtica.

La guia d'alta disponibilitat d'ASA de Cisco separa tres capacitats: l'equilibri de càrrega de VPN d'accés remot, el failover amb estat i el clúster entre seus. Només la primera mou un client elegible d'una entrada de grup a un membre, i les connexions LAN a LAN queden fora d'aquesta distribució. Un equilibrador TCP genèric no pot substituir el pas de redirecció propi del protocol, perquè l'handshake del túnel no és HTTP pla que un proxy pugui reescriure. El resultat pràctic és un equilibrador que accepta la connexió i encara deixa el client sense poder fer el túnel.

Llegeix la llista de funcions segons el teu tipus de sessió abans de demanar un segon dispositiu. La línia de llicència i la línia de mecanisme són entrades separades, i una no implica l'altra.

Treballa l'exemple en lloc d'endevinar

Suposa que tres passarel·les estan validades cadascuna a 800 túnels concurrents amb la càrrega que has aprovat, cosa que suma 2,400. Un objectiu d'hora punta de 1,650 sembla còmode fins que es perd una unitat, i llavors la parella supervivent ha de sostenir 1,650 contra un 1,600 dur. El disseny ja ha fallat, i cap ajust de failover no repara l'aritmètica.

Fixa l'objectiu de manera que el conjunt supervivent encara el compleixi, cosa que per a un grup de tres membres significa quedar-se per sota de dos terços del total. Aquesta ràtio és una propietat de l'aritmètica i no de cap producte, així que recalcula-la sempre que canviï la xifra validada d'un membre. Mantén el recompte llicenciat, el màxim documentat i la teva pròpia xifra mesurada en tres columnes, perquè rarament coincideixen i la més petita mana. Una quarta columna per al pic d'hora punta observat manté el pla honest després del primer mes.

Pressuposta l'esclat de reconnexió, no només l'estat estable

Les sessions d'un membre fallit no reapareixen silenciosament en un altre lloc. Segons el mecanisme, fan failover amb estat, renegocien des de zero o esperen que l'aplicació torni a intentar-ho segons el seu propi calendari.

Uns quants milers de clients reintentant dins d'un minut és un esdeveniment diferent d'un 1,650 estable, i els servidors d'autenticació ho noten primer. Comprova també l'espai del pool, ja que la redirecció no el consulta: un membre que no pot assignar una adreça encara accepta el client i després en descarta el trànsit.

Verifica la capacitat amb el pool i la ruta a mà

La verificació és un exercici de només lectura que atrapa la majoria d'errors de disseny abans que s'obri una finestra de manteniment. Recull el pool per membre, el recompte de sessions actives i la ruta de tornada a la subxarxa dels clients, i després compara cadascun amb el pla. L'esgotament del pool i una ruta de retorn absent apareixen tots dos com un client que s'autentica i després perd el trànsit.

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

Executa aquestes lectures contra cada membre durant una hora punta normal i no una de tranquil·la. Un membre que informa de sessions però no té adreces lliures ja és al seu límit pràctic, digui el que digui la llicència. Anota la versió del firmware al costat de cada sortida, ja que els noms de les ordres canvien entre versions.

Assaja la pèrdua una vegada a propòsit, fora d'horari laboral, i registra què informen els membres supervivents mentre passa. Un membre que accepta la redirecció però no té espai al pool apareix com a assignació fallida, cosa que l'amplada de banda extra mai no arregla. Desa les xifres validades amb la data al costat del pla, perquè la propera revisió de capacitat comenci amb evidències i no amb un full de càlcul de llicències. Afegeix el resultat d'aquest assaig a la mateixa pàgina, fins i tot quan les xifres coincideixin amb el pla.