Continuità Citrix su due data center indipendenti

Contesto

La piattaforma Citrix Virtual Apps and Desktops del dipartimento girava in un solo data center: desktop Windows 10 in pool per oltre mille dipendenti e più di sessanta server applicativi multisessione per utenti interni e fornitori esterni, con accesso remoto ad autenticazione forte. Un guasto del data center avrebbe fermato il lavoro di tutti.

Con il team di Citrix Consulting ho scritto il detailed design per estendere l’infrastruttura a un secondo data center, partendo dalla configurazione di produzione e definendo cosa replicare, come e con quali rischi.

La sfida

• Continuità senza nuove abitudini. L’accesso doveva funzionare anche con il data center primario fuori servizio, senza cambiare indirizzo né autenticazione a più fattori.
• Storage diverso. Il secondo data center non aveva lo stesso NAS usato per profili e dati utente.
• Licenze. L’EULA non consente di duplicare lo stesso pacchetto di licenze Citrix su due license server attivi.
• Versioni diverse. Il sito primario era su 1912 LTSR, il secondo nasceva su 2203 LTSR.

L’architettura

Ho scelto due farm gemelle e indipendenti, una per data center, invece di un’unica farm estesa. Ogni sito ha i suoi Delivery Controller, Director, StoreFront, database SQL Server in Always On, license server e DHCP. Gli StoreFront di un sito non enumerano le risorse dell’altro, per scelta: un problema in un data center non può propagarsi.

L’accesso resta quello di sempre, con lo stesso URL per utenti interni ed esterni. I NetScaler VPX esterni in DMZ passano le connessioni in SSL bridge ai gateway interni, che gestiscono l’autenticazione forte con nFactor (smart card o token); gli utenti interni usano le credenziali di dominio. In caso di DR si aggiorna la risoluzione DNS, pubblica e interna, verso il secondo sito: un passaggio manuale e controllato.

Decisioni chiave

• Profili. FSLogix per i desktop, Citrix Profile Management per le applicazioni pubblicate, che gestisce le sessioni concorrenti su server diversi, e folder redirection per desktop, documenti e download.
• File server. Le share passano dal NAS a file server Windows virtuali replicati con VMware Site Recovery Manager. Il design ne indica i limiti: coerenza dei container dei profili, perdita dei dati scritti dopo l’ultima replica e test di DR da isolare dalla produzione.
• Licenze conformi. Due strade: dividere il pacchetto tra i due license server (ad esempio 80/20) e riassegnarlo in DR, oppure replicare la VM del license server e cambiare il DNS. Anche licenze RDS e KMS hanno un server per sito, assegnato da GPO.
• Active Directory. Un ramo di OU parallelo per il secondo sito e copie dedicate delle GPO, così una modifica per il DR non tocca la produzione. Gli scope DHCP sono replicati su subnet diverse con la stessa capienza.
• Versioni allineate. Il license server si aggiorna per primo a 2203 LTSR, dopo aver verificato che la data di Subscription Advantage nel file di licenza sia successiva al rilascio; poi la farm primaria raggiunge il secondo sito.
• Capacità. Il secondo data center va dimensionato almeno come il primo; se non lo è, le risorse delle VM utente si riducono prima di attivarlo.