This blog post is cross posted on arnaudpain.com and tech-addict.fr, as we (Arnaud Pain and Samuel Legrand) have worked together to present this topic to the Citrix User Group XL Florida in Orlando on January 2019.
We have decided to work on this presentation to help users understand how they can rely on Microsoft Azure and Citrix Cloud for their Disaster Recovery Plan.
Here after some more information on the implementation and our feedback.
Citrix Cloud is the very first piece of “cloudification” you can choose to make your Citrix environment DR easier.
In fact, with Citrix Cloud, Citrix manages all their components of the infrastructure with a 99.5% Service Level Agreement (SLA). You can find the conditions of the SLA here, but here you have the main information:
Citrix’s service commitment (“Service Commitment”) is to maintain at least 99.5% monthly uptime (“Monthly Uptime”) on Services. Monthly Uptime is calculated by subtracting from 100% the percentage of minutes during a full month of a Service in which the Service instance was in the state of “Unavailable.” Services and the measure of availability for each are set forth in the table below. Monthly Uptime percentage measurements exclude downtime resulting from:
- Regularly scheduled maintenance windows.
Customer’s failure to follow configuration requirements for the Service as documented on https://docs.citrix.com, or abusive behavior, or faulty input.
- Customer’s use of a Service after Citrix advised Customer to modify Customer’s use of the Service, if Customer did not modify use.
- Caused by any component not managed by Citrix including, but not limited to, Customer controlled physical and virtual machines, Customer installed and maintained operating systems, Customer installed and controlled software, networking equipment or other hardware; Customer defined and controlled security settings, group policies and other configuration policies; public cloud provider failures, Internet Service Provider failures; or other Customer support factors external to Citrix’ control.
- Customer’s employees, agents, contractors, or vendors, or anyone gaining access by means of Customer’s passwords or equipment, or otherwise resulting from Customer’s failure to follow appropriate security practices.
- Customer’s attempts to perform operations that exceed Service entitlements.
- Service disruption due to Force Majeure, including, but not limited to, natural disasters, war or acts of terrorism, or government actions.
Here are the components managed by Citrix in the Citrix Cloud Virtual Apps and Desktops offer:
- Studio
- Director
- License
- Delivery Controller
- SQL Database
- NetScaler (not mandatory)
- StoreFront (not mandatory)
- Cloud Connectors
The good thing is that you have to focused on the important part of the infrastructure: Files, Users and publication servers.
From the field experience: Citrix Cloud Connectors are just at the border between the customer and Citrix managed components, as the software is managed and updated by Citrix but the OS layer (Antivirus, patching…) is on the customer duties.
The Lab:
The Lab we used to make this presentation was pretty simple :
On-Premise:
- 1 Host with VMware ESXi 6.7 U1
- 1 Active Directory Domain Controller
- 2 Citrix Cloud Connectors
- 1 Windows 2016 VDA
- 1 ASR Configuration Server
In Azure:
- 1 Active Directory Domain Controller
- 2 Citrix Cloud Connector
How Microsoft Azure can help for on-premises customers?
As we already mentioned, all the infrastructure disaster recovery is covered by Citrix, so customers “just” need to deal with the “non-Citrix” elements (VDA, Active Directory, shared files…)
Microsoft Azure proposes a solution called Azure Site Recovery (ASR). This solution allows to replicate Azure VMs between different locations to cover a DataCenter outage. The great thing is that ASR is also designed to allow on-prem infrastructures to Azure. Relying on a local server deployment from a Virtual Machine template that need to be deployment on your vSphere environment.
ASR Server deployment
You will have to install an ASR Configuration Server (download and import an ova file) on-premise.
Here after a video explaining how simple it is!
Setup the Disaster Recovery
This is a 4 steps process:
- Enter the replication source and target.
- Set up the source replication environment, including on-premises Azure Site Recovery components, and the target replication environment.
- Create a replication policy.
- Enable replication for a VM.
Run a disaster recovery drill
- Set up an isolated network for the test Failover
- Prepare to connect to the Azure VM after Failover.
- Run a test Failover for a single machine.
Run a Failover and Failback
- Verify the VMware VM properties to check conform with Azure requirements.
- Run a Failover to Azure.
- Create a process server and master target server for Failback.
- Reprotect Azure VMs to the on-premises site.
- Fail over from Azure to on-premises.
- Reprotect on-premises VMs, to start replicating to Azure again.
Notes from the field
- If you use VMware virtual machine on-premise, make sure that those VMs are configured BIOS boot and not UEFI (Failback to on-premises VMware site isn’t supported with UEFI boot VMs)
- Microsoft provide some interesting tools Azure Site Recovery Deployment Planner for VMware to Azure.
Thanks
Thanks to Alain P. from Microsoft who has provided us an Azure Pass to work on our lab and this presentation.
