Deployment distribuito e high availability

Standalone vs distribuito

In un deployment standalone un singolo nodo ISE ospita tutte le personas contemporaneamente: è semplice ma non offre ridondanza né scalabilità, adatto solo a lab o piccolissimi ambienti. In un deployment distribuito le personas vengono suddivise su nodi dedicati, gestiti come un’unica entità logica dal Primary PAN, che è il punto di amministrazione e l’unica copia read-write del database di configurazione.

Le quattro personas da conoscere:

PAN: promozione primary/secondary

Tutte le modifiche di configurazione avvengono sul Primary PAN e vengono replicate verso il Secondary PAN e tutti gli altri nodi. Il Secondary PAN mantiene una copia read-only pronta a subentrare. Il punto cruciale d’esame: il failover del PAN è manuale per default. Se il Primary cade, l’amministratore deve promuovere manualmente il Secondary a Primary (o via CLI/GUI). Nel frattempo l’autenticazione continua a funzionare (i PSN autenticano comunque), ma non si possono applicare modifiche di configurazione finché non c’è un Primary attivo.

L’auto-failover esiste ma va configurato esplicitamente e richiede almeno un health check node (un nodo non-PAN, tipicamente un PSN) che faccia da arbitro per evitare lo split-brain: senza arbitro, due PAN potrebbero credersi entrambi Primary. Quando il vecchio Primary torna online, rientra come Secondary: non riprende automaticamente il ruolo primario.

MnT: entrambi attivi

A differenza del PAN, i due nodi MnT non sono attivo/standby per la raccolta: i NAD e i PSN inviano i log in syslog a entrambi i MnT simultaneamente. Così, se il Primary MnT cade, il Secondary ha già i dati e non si perde storico. La distinzione Primary/Secondary qui riguarda principalmente quale nodo alimenta dashboard e report in condizioni normali.

PSN e node group

I PSN sono il piano dati: elaborano le richieste RADIUS, la posture, il guest, il profiling. Si scalano aggiungendo nodi. Un node group raggruppa PSN che devono scambiarsi informazioni di sessione: se un utente è in un flusso con URL-redirect (posture o guest) e il PSN che ha originato la sessione cade, un altro membro del node group può recuperare lo stato ed evitare che la sessione muoia. I membri di un node group usano peer discovery per sincronizzarsi e, storicamente, si prevedono L2-adiacenti / bassa latenza per uno scambio efficiente.

Distribuzione dei PSN verso i NAD

Due approcci per bilanciare e rendere ridondanti i PSN:

• Lista di RADIUS server sul NAD: si configurano più PSN come server RADIUS con dead-server detection. Semplice, nessun hardware extra, ma il bilanciamento è grezzo (primario/backup o round-robin) e dipende dallo switch.
• Load balancer (es. F5): i NAD puntano a una VIP unica e l’LB distribuisce verso il pool di PSN. Serve persistence/sticky basata sul Calling-Station-ID affinché tutti i pacchetti di una sessione (auth, accounting, CoA) raggiungano lo stesso PSN, e attenzione al source NAT: la Change of Authorization (CoA) parte dal PSN verso il NAD e deve poter tornare correttamente.

Latenza di replica

In un deployment grande, la replica del config DB dal Primary PAN verso tutti i nodi non è istantanea: modifiche massicce, WAN ad alta latenza o link saturi generano ritardi e nodi in stato “Replication in progress” o out of sync. È un fattore progettuale reale, non un dettaglio: influisce su quanti PSN si possono avere e sulla topologia geografica.

Trappole tipiche d’esame

• Scenario: il Primary PAN è down e non si applicano più policy → risposta giusta: il failover del PAN è manuale; promuovi manualmente il Secondary a Primary. Le autenticazioni continuano sui PSN nel frattempo.
• Scenario: vuoi auto-failover del PAN in sicurezza → serve un health check node (nodo non-PAN) come arbitro per prevenire lo split-brain; senza, non abilitarlo.
• Scenario: dopo un ripristino il vecchio Primary è tornato → rientra come Secondary, non riprende da solo il ruolo primario; eventuale re-promozione è manuale.
• Scenario: sessioni guest/posture cadono quando un PSN muore → configura i PSN nello stesso node group così lo stato di sessione viene recuperato da un peer.
• Scenario: dietro load balancer, CoA e accounting finiscono su PSN diversi → manca la persistence (sticky su Calling-Station-ID); tutti i pacchetti della sessione devono andare allo stesso PSN.