Escala as sesións VPN por rol e despois comproba a marxe de fallo

Engades unha segunda pasarela, a consola mostra dous membros sans e o teito de sesións apenas se move, porque nada lles dixo aos clientes como chegar á nova caixa. Escalar un servizo VPN son dúas decisións en secuencia: que mecanismo distribúe clientes para este tipo de conexión e canta capacidade queda tras a peor perda individual. Se as tomas na orde inversa, obtés un deseño que parece redundante e falla xusto cando fai falta. Comeza pola consola e despois fai a aritmética.

Axusta o mecanismo ao tipo de sesión

Os usuarios remotos, os pares entre sedes e os túneles de dispositivo sempre activos non son sesións intercambiables. Unha función de distribución creada para unha delas normalmente redirixe un cliente durante a negociación, o que non significa nada para un par que xa ten un enderezo fixo e unha configuración estática.

A guía de alta dispoñibilidade de ASA de Cisco mantén tres capacidades separadas: o equilibrio de carga de VPN de acceso remoto, o failover con estado e a agrupación entre sedes. Só a primeira move un cliente elixible dunha entrada de grupo a un membro, e as conexións LAN a LAN quedan fóra desa distribución. Un balanceador TCP xenérico non pode substituír o paso de redirección propio do protocolo, porque o handshake do túnel non é HTTP simple que un proxy poida reescribir. O resultado práctico é un balanceador que acepta a conexión e aínda deixa o cliente sen poder crear o túnel.

Le a lista de funcións fronte ao teu tipo de sesión antes de pedir un segundo dispositivo. A liña de licenza e a liña de mecanismo son entradas separadas, e unha non implica a outra.

Traballa o exemplo en vez de adiviñar

Supón que tres pasarelas están validadas cada unha a 800 túneles simultáneos coa carga que aprobaches, o que suma 2,400. Un obxectivo de hora punta de 1,650 parece cómodo ata que se perde unha unidade, e entón a parella supervivente debe soster 1,650 contra un 1,600 duro. O deseño xa fallou, e ningún axuste de failover repara a aritmética.

Fixa o obxectivo de xeito que o conxunto supervivente aínda o cumpra, o que para un grupo de tres membros significa quedar por baixo de dous terzos do total. Esa proporción é unha propiedade da aritmética e non de ningún produto, así que recalcúlaa cando cambie a cifra validada dun membro. Mantén o reconto licenciado, o máximo documentado e a túa propia cifra medida en tres columnas, porque raramente coinciden e a máis pequena manda. Unha cuarta columna para o pico de hora punta observado mantén o plan honesto despois do primeiro mes.

Orzamenta a ráfaga de reconexión, non só o estado estable

As sesións dun membro fallido non reaparecen en silencio noutro sitio. Segundo o mecanismo, conmutan con estado, renegocian desde cero ou esperan a que a aplicación volva tentar segundo o seu propio calendario.

Uns cantos milleiros de clientes tentando de novo nun minuto son un acontecemento distinto dun 1,650 estable, e os servidores de autenticación nótao primeiro. Comproba tamén o espazo do pool, xa que a redirección non o consulta: un membro que non pode asignar un enderezo aínda acepta o cliente e despois descarta o seu tráfico.

Verifica a capacidade co pool e a ruta á man

A verificación é un exercicio de só lectura que atrapa a maioría dos erros de deseño antes de que se abra unha xanela de mantemento. Recolle o pool por membro, o reconto de sesións activas e a ruta de volta á subrede do cliente, e despois compara cada un co plan. O esgotamento do pool e unha ruta de retorno ausente aparecen ambos como un cliente que se autentica e despois perde tráfico.

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 esas lecturas contra cada membro durante unha hora punta normal e non unha tranquila. Un membro que informa de sesións pero non ten enderezos libres xa está no seu límite práctico, diga o que diga a licenza. Anota a versión do firmware xunto a cada saída, xa que os nomes dos comandos cambian entre versións.

Ensaya a perda unha vez a propósito, fóra do horario laboral, e rexistra o que informan os membros superviventes mentres ocorre. Un membro que acepta a redirección pero non ten espazo no pool aparece como asignación fallida, algo que o ancho de banda extra nunca arranxa. Garda as cifras validadas coa data xunto ao plan, para que a seguinte revisión de capacidade comece con probas e non cunha folla de cálculo de licenzas. Engade o resultado dese ensaio á mesma páxina, mesmo cando as cifras coincidan co plan.