This content has been machine translated dynamically.
Dieser Inhalt ist eine maschinelle Übersetzung, die dynamisch erstellt wurde. (Haftungsausschluss)
Cet article a été traduit automatiquement de manière dynamique. (Clause de non responsabilité)
Este artículo lo ha traducido una máquina de forma dinámica. (Aviso legal)
此内容已经过机器动态翻译。 放弃
このコンテンツは動的に機械翻訳されています。免責事項
이 콘텐츠는 동적으로 기계 번역되었습니다. 책임 부인
Este texto foi traduzido automaticamente. (Aviso legal)
Questo contenuto è stato tradotto dinamicamente con traduzione automatica.(Esclusione di responsabilità))
This article has been machine translated.
Dieser Artikel wurde maschinell übersetzt. (Haftungsausschluss)
Ce article a été traduit automatiquement. (Clause de non responsabilité)
Este artículo ha sido traducido automáticamente. (Aviso legal)
この記事は機械翻訳されています.免責事項
이 기사는 기계 번역되었습니다.책임 부인
Este artigo foi traduzido automaticamente.(Aviso legal)
这篇文章已经过机器翻译.放弃
Questo articolo è stato tradotto automaticamente.(Esclusione di responsabilità))
Translation failed!
Disaster Recovery
You can architect and configure XenMobile deployments that include multiple sites for disaster recovery using an active-passive failover strategy.
The recommended disaster recovery strategy discusses in this article consists of:
- A single XenMobile active site in the data center of one geographical location serving all the enterprise users globally, known as the primary site.
- A second XenMobile site in the data center of a second geographical location known as the disaster recovery site. This disaster recovery site provides active-passive site failover in if a site-wide data center failure occurs in the primary site. The primary site includes XenMobile, SQL database, and Citrix ADC infrastructure to facilitate failover and provide users with access to XenMobile via the event of connectivity failure to the primary site.
The XenMobile Servers at the disaster recovery site remains offline during normal operations and is brought online during only disaster recovery scenarios, where complete site failover from the primary site to the disaster recovery site is required. The SQL Servers at the disaster recovery site must be active and ready to service connections before you start the XenMobile Servers at the disaster recovery site.
This disaster recovery strategy relies on manual failover of the Citrix ADC access tier by DNS changes for routing MDM and MAM connections to the disaster recovery site in the event of an outage.
Note:
To use this architecture, you must have a process in place for asynchronous backups of the databases and some way of ensuring high availability for the SQL infrastructure.
Disaster Recovery Failover Process
- If you are testing your disaster recovery failover process, shut down XenMobile Servers in the primary site to simulate site failure.
- Change public DNS records for the XenMobile Servers to point to the disaster recovery site’s external IP addresses.
- Change the internal DNS record for the SQL Server to point to the disaster recovery site’s SQL Server IP address.
- Bring XenMobile SQL databases online at the disaster recovery site. Ensure that the SQL Server and database is active and ready to service connections from the XenMobile Servers local to the site.
- Turn on the XenMobile Servers on the disaster recovery site.
XenMobile Server Update Process
Follow these steps anytime that you update XenMobile with patches and releases to keep the code of the primary and disaster recovery servers uniform.
- Make sure that the XenMobile Servers in the primary site have been patched or upgraded.
- Make sure that the DNS record for the SQL Server is resolving to the active SQL Server database in the primary site.
- Bring the disaster recovery site’s XenMobile Servers online. The servers connect to the primary site’s database across the WAN during the upgrade process only.
- Apply required patches and updates to all disaster recovery site’s XenMobile Servers.
- Restart the XenMobile Servers and confirm that the patch or upgrade is successful.
Disaster Recovery Reference Architecture Diagram
The following diagram shows the high-level architecture for a disaster recovery deployment of XenMobile.
GSLB for Disaster Recovery
A key element of this architecture is the use of Global Server Load Balancing (GSLB) to direct traffic to the correct data center.
By default, the Citrix ADC for XenMobile wizard configures the Citrix Gateway in a way that does not enable the use of GSLB for disaster recovery. Therefore, you must take extra steps.
How GSLB Works
GSLB is at its core a form of DNS. Participating Citrix ADC appliances act as authoritative DNS servers and resolve DNS records to the correct IP address (typically the VIP that is supposed to receive traffic). The Citrix ADC appliance checks the system health before responding to a DNS query directing traffic to that system.
When a record is resolved, GSLB’s role in resolving the traffic is complete. The client communicates directly with the target virtual IP (VIP) address. DNS client behavior plays an important part on controlling how and when a record expires. This is largely outside the boundaries of the Citrix ADC system. As such, GSLB is subject to the same limitations as DNS name resolution. Clients cache responses, thus, load balancing in this way isn’t as real-time as is traditional load balancing.
The GSLB configuration on the Citrix ADC, including sites, services, and monitors, exist to provide the correct DNS name resolution.
The actual configuration for publishing servers (in this scenario, the configuration that the Citrix ADC for XenMobile wizard creates) is not affected by the GSLB. GSLB is a separate service on the Citrix ADC.
Challenges with Domain Delegation When Using GSLB with XenMobile
The Citrix ADC for XenMobile wizard configures the Citrix Gateway for XenMobile. This wizard generates three load-balancing virtual servers and a Citrix Gateway virtual server.
Two of the load-balancing virtual servers handle MDM traffic, on ports 443 and 8443. Citrix Gateway receives MAM traffic and forwards it to the third server, the MAM load balancing virtual server, on port 8443. All traffic to the MAM load-balancing virtual server is passed through Citrix Gateway.
The MAM load balancing virtual server requires the same SSL certificate as the XenMobile Servers and uses the same FQDN as used to enroll devices. The MAM load-balancing server also uses the same port (8443) as one of the MDM load balancing servers. To enable traffic to be resolved, the Citrix ADC for XenMobile wizard creates a local DNS record on Citrix Gateway. The DNS record matches the FQDN used to enroll devices.
This configuration is effective when the XenMobile Server URL is not a GSLB domain URL. If a GSLB domain URL is used as the XenMobile Server URL, as is required for disaster recovery, the local DNS record prevents Citrix Gateway from resolving traffic to the MDM load balancing servers.
Using the CNAME Method for GSLB Disaster Recovery
To address the challenges presented by the default configuration created by the Citrix ADC for XenMobile wizard, you can create a CNAME record for the XenMobile Server FQDN in the parent domain (company.com) and point a record in the delegated subzone (gslb.company.com) for which the Citrix ADC is authoritative. Doing so allows for the creation of the static DNS A record for the MAM load-balancing VIP address required to resolve traffic.
-
On the external DNS, create a CNAME for the XenMobile Server FQDN that points to the GSLB domain FQDN on Citrix ADC GSLB. You need two GSLB domains: One for MDM traffic and another for MAM (Citrix Gateway) traffic.
Example:
CNAME = xms.company.com IN CNAME xms.gslb.comany.com -
On the Citrix Gateway instance of each site, create a GSLB virtual server with an FQDN that is what the CNAME record is pointing to.
Example:
bind gslb vserver xms-gslb -domainName xms.gslb.company.comWhen using the Citrix ADC for XenMobile wizard to deploy Citrix Gateway, use the XenMobile Server URL when configuring the MAM load balancing server. This creates a static DNS A record for the XenMobile Server URL.
-
Test with clients enrolling on Secure Hub using the XenMobile Server URL (
xms.company.com).This example uses the following FQDNs:
-
xms.company.comis the URL that is used by the MDM traffic and is used by devices enrolling, which is configured in this example by using the Citrix ADC for XenMobile wizard. -
xms.gslb.company.comis the GSLB domain FQDN for the XenMobile Server.
-
Share
Share
This Preview product documentation is Citrix Confidential.
You agree to hold this documentation confidential pursuant to the terms of your Citrix Beta/Tech Preview Agreement.
The development, release and timing of any features or functionality described in the Preview documentation remains at our sole discretion and are subject to change without notice or consultation.
The documentation is for informational purposes only and is not a commitment, promise or legal obligation to deliver any material, code or functionality and should not be relied upon in making Citrix product purchase decisions.
If you do not agree, select I DO NOT AGREE to exit.