Disaster recovery Citrix su Nutanix: una farm pronta invece di una replica

Contesto

Lo studio distribuisce desktop virtuali con Citrix Virtual Apps and Desktops, su un’infrastruttura in parte VMware e in parte Nutanix: desktop pooled creati con Citrix Provisioning e con MCS, profili utente su Nutanix Files. Il disaster recovery si basava sulla replica con Zerto delle VM principali verso un sito esterno: NetScaler, StoreFront, Delivery Controller, database, server di Provisioning e i relativi desktop.

Ho analizzato la configurazione esistente e proposto quella di destinazione, insieme alle esigenze tecniche per arrivarci.

La sfida

• I desktop MCS non si replicano. I cloni creati da MCS dipendono dalla hosting connection su cui nascono: non si possono copiare da uno storage all’altro come le altre VM.
• Un DR da ricostruire nel momento peggiore. Con una farm replicata, in caso di disastro bisogna riaccendere e rimettere in funzione l’intera infrastruttura Citrix.
• Immagini sempre allineate. A ogni aggiornamento delle immagini master anche i Machine Catalog del DR devono seguire.
• Profili coerenti. In DR ogni utente deve ritrovare il proprio profilo, che oggi vive su Nutanix Files in produzione.
• Permessi dell’utenza di servizio. La versione LTSR in uso si collega al cluster Nutanix e non a Prism Central: la hosting connection richiede un amministratore del cluster.

L’architettura proposta

Nel sito di DR c’è una farm Citrix completa e indipendente, non una replica della produzione: due NetScaler VPX, due StoreFront, due Delivery Controller, il suo database e una hosting connection verso il cluster Nutanix locale. Gli utenti usano lo stesso indirizzo: in condizioni normali arrivano in produzione, in caso di disastro al DR.

Tra i due siti si replica solo ciò che serve: le immagini master, con i Protection Domain di Nutanix, e i profili su Nutanix Files. Quando un’immagine viene aggiornata, i Machine Catalog MCS del DR si aggiornano dalla copia replicata sulla loro hosting connection, e il DR resta pronto senza dover ricreare i cataloghi.

Decisioni chiave

• Una farm pronta, non una copia. Il DR ha la sua infrastruttura Citrix sempre attiva e raggiungibile, così i cataloghi si tengono aggiornati in ogni momento.
• Replicare le immagini, non i cloni. I Protection Domain portano al DR le immagini master; MCS crea i cloni sul posto.
• Una piattaforma sola. Nel disegno di destinazione produzione e DR stanno su Nutanix, con MCS in entrambi i siti al posto di Citrix Provisioning e della replica delle VM.
• Profili replicati. I profili su Nutanix Files si allineano tra il cluster di produzione e quello di DR.
• Un limite dichiarato. Finché la versione on-premises non potrà collegarsi a Prism Central, possibilità annunciata da Citrix per DaaS, l’utenza della hosting connection deve essere amministratore del cluster: un rischio da conoscere e gestire.