How to configure Citrix NetScaler Global Server Load Balancing to Recover your Citrix XenDesktop or XenApp environment in Microsoft Azure
Building the Digital Workspace of the Future can be a interesting road to follow. To prepare your environment for a Public Cloud, such as Microsoft Azure, there are different approaches to follow. Microsoft provides a great method to replicate, failover and/or migrate your on-premises servers to Azure with the service named Azure Recovery Service, what actually 1:1 replicates all your on-premises servers to the Azure IaaS service – Virtual Machines. Unfortunately the service doesn’t support the replication of the NetScaler, but the GSLB feature can fulfill this limitation to be the switching player between both active and passive environments. This was actually an technical Azure limitation before, but since March this year it is possible to activate multiple IPs on the NetScaler VPX in Azure. This definitely opens a lot of doors to implement NetScaler on fully Cloud, but in this case, also hybrid-multi Cloud scenarios! (read the whole previous Citrix announcement article here).
GLSB stands for Global Load Server Balancing and is a DNS-based solution that load balances services between geographically distributed sites. It can be performed in an Active-Passive or Active-Active Mode configuration. For Disaster Recovery scenario’s the Active-Passive will fit best. Depending on the availability of your Citrix XenApp or XenDesktop environment, it also can be used in active-active mode. What makes it also possible to load balancing ICA sessions between different Azure Regions around the globe, with the NetScaler GSLB load balancing proximity DB as method. Just place an extra NetScaler VPX in that specific Azure region, open all the required ports on the NSG (Network Security Group), run the new GSLB wizard and you’re all set!
Is this article, I’ll show you how you can configure NetScaler v12 GSLB in Active-Passive mode, just to prepare you’re environment for the Azure Cloud and/or for Disaster Recovery reasons.
via Christiaan Brinkhoff at infrashare.net