Scalați sesiunile VPN după rol, apoi verificați rezerva la defecțiune

Adăugați un al doilea gateway, consola arată doi membri sănătoși, iar plafonul sesiunilor abia se mișcă, pentru că nimic nu le-a spus clienților cum să ajungă la noua cutie. Scalarea unui serviciu VPN înseamnă două decizii în succesiune: ce mecanism distribuie clienții pentru acest tip de conexiune și câtă capacitate rămâne după cea mai gravă pierdere individuală. Dacă le luați în ordinea inversă, obțineți un proiect care pare redundant și eșuează exact când este nevoie. Începeți de la consolă, apoi faceți aritmetica.

Potriviți mecanismul cu tipul de sesiune

Utilizatorii la distanță, partenerii între locații și tunelurile de dispozitiv mereu active nu sunt sesiuni interschimbabile. O funcție de distribuție construită pentru unul dintre ele redirecționează de obicei un client în timpul negocierii, ceea ce nu înseamnă nimic pentru un partener care are deja o adresă fixă și o configurație statică.

Ghidul Cisco de disponibilitate ridicată pentru ASA ține trei capabilități separate: echilibrarea încărcării VPN pentru acces la distanță, failover-ul cu stare și clusterizarea între locații. Doar prima mută un client eligibil dintr-o intrare de grup pe un membru, iar conexiunile LAN-la-LAN rămân în afara acelei distribuții. Un balansator TCP generic nu poate înlocui pasul propriu de redirecționare al protocolului, deoarece handshake-ul tunelului nu este HTTP simplu pe care un proxy să îl poată rescrie. Rezultatul practic este un balansator care acceptă conexiunea și totuși lasă clientul fără posibilitatea de a crea tunelul.

Citiți lista de funcții în raport cu tipul de sesiune înainte de a comanda un al doilea echipament. Linia de licență și linia de mecanism sunt intrări separate, iar una nu o implică pe cealaltă.

Calculați exemplul în loc să ghiciți

Să presupunem că trei gateway-uri sunt validate fiecare la 800 de tuneluri simultane sub încărcarea aprobată, ceea ce înseamnă 2,400 în total. O țintă de 1,650 la ora de vârf pare confortabilă până când se pierde o unitate, iar apoi perechea supraviețuitoare trebuie să țină 1,650 împotriva unui 1,600 dur. Proiectul a eșuat deja, iar nicio reglare a failover-ului nu repară aritmetica.

Stabiliți ținta astfel încât setul supraviețuitor să o îndeplinească în continuare, ceea ce pentru un grup de trei membri înseamnă să rămână sub două treimi din total. Acea proporție este o proprietate a aritmeticii, nu a vreunui produs, așa că recalculat-o ori de câte ori se schimbă cifra validată a unui membru. Țineți numărul licențiat, maximul documentat și cifra dvs. măsurată în trei coloane, pentru că rareori coincid și cea mai mică decide. O a patra coloană pentru vârful observat la ora de vârf menține planul onest după prima lună.

Bugetați izbucnirea reconectării, nu doar starea stabilă

Sesiunile de pe un membru defect nu reapar în tăcere în altă parte. În funcție de mecanism, preiau cu stare, renegociază de la zero sau așteaptă ca aplicația să reîncerce conform propriului calendar.

Câteva mii de clienți care reîncearcă într-un minut sunt un eveniment diferit de 1,650 stabil, iar serverele de autentificare îl simt primele. Verificați și spațiul din pool, deoarece redirecționarea nu îl consultă: un membru care nu poate aloca o adresă acceptă totuși clientul și apoi îi aruncă traficul.

Verificați capacitatea cu pool-ul și ruta la îndemână

Verificarea este un exercițiu doar-citire care prinde majoritatea erorilor de proiectare înainte de deschiderea unei ferestre de mentenanță. Colectați pool-ul pe membru, numărul de sesiuni active și ruta înapoi către subrețeaua clientului, apoi comparați fiecare cu planul. Epuizarea pool-ului și o rută de întoarcere lipsă apar ambele ca un client care se autentifică și apoi pierde trafic.

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

Rulați acele citiri pe fiecare membru într-o oră de vârf normală, nu într-una liniștită. Un membru care raportează sesiuni dar nu are adrese libere este deja la limita sa practică, orice ar spune licența. Notați versiunea de firmware lângă fiecare ieșire, deoarece numele comenzilor se schimbă între versiuni.

Exersați pierderea o dată intenționat, în afara orelor de program, și înregistrați ce raportează membrii supraviețuitori în timpul ei. Un membru care acceptă redirecționarea dar nu are spațiu în pool apare ca alocare eșuată, ceea ce lățimea de bandă suplimentară nu repară niciodată. Stocați cifrele validate cu data lângă plan, astfel încât următoarea revizuire a capacității să pornească de la dovezi, nu de la o foaie de calcul de licențe. Adăugați rezultatul acelui exercițiu pe aceeași pagină, chiar și când cifrele corespund planului.