Journey To A Full Scale Hybrid Architecture with vCloud Hybrid Service – Part 3
In the first postI talked about the basic architecture of a large scale hybrid cloud build out, as well as integrating an on premises view environment into the vCHS hybrid cloud. We extended that Horizon View environment into the vCloud Hybrid Service by adding security servers and global load balancing on the top layer. You may be asking yourself “why” did we do that? Well, the ultimate goal of building this out was to mesh together vCloud Hybrid Service – Disaster Recovery and desktops to access those applications. With the next stage we set out to replicate an internal only application to vCHS-DR and use DaaS on vCHS to give the users access to it once it was failed over.
The Use Case Background
Before we go into the architecture solution we need to understand the problem we are trying to solve. Many times in the past I have shown how you can fail over public facing applications. However, not every application is web-based, public facing, or of a “Next Generation” architecture. In a lot of cases many applications are still internal only and although may be web based, need a desktop on the corporate side to access it. This is also the case for legacy fat client applications. So the goal in this architecture was to show how a user can connect to an application on premises and also connect to that same application once vCHS-DR is invoked to fail it over. The solution will comprise a few components for illustration, refer to the original overview diagram to understand all the connection points.
- On premises Horizon View Desktops previously configured
- On premises “Wiki” based application with a local DNS Entry
- On premises AD/DNS Servers
- vCloud Hybrid Service – Disaster Recovery running on the Wiki server ONLY
- VMware Horizon DaaS on vCHS
- IaaS based AD/DNS with VPN connection to the DR Cloud
- Cloud to Cloud VPN from Horizon DaaS Cloud to vCHS-DR Cloud
- Access to External DNS system
- A Horizon View Desktop Client
For the purposes of continuing we will assume that the VPN’s and networks are already configured and replication is running on the Wiki Server. We will also assume from the previous article that the desktop image used for Horizon View on premises is available and ready to synchronize with the new Horizon DaaS cloud. In order to make this all work we need to first ensure the same desktop image is available in DaaS on vCHS for the customer. We will double click into a few of the virtual data centers above later on.
Synchronizing View and DaaS Images with vCloud Connector
For ease of deployment we created our Horizon View on premises desktop image in vCenter. We set it up the way we wanted and then used vCloud Connector Content Sync to push a copy of that up to our DaaS on vCHS cloud. This way we are able to subscribe the DaaS catalog to the vCenter version of the image. vCloud Connector catalog sync then ensures that the DaaS cloud has the same copy available to use. This is not required and there is other DaaS related things you need to do to utilize the image, but we won’t go into that. The concept is just to build one image and sync to the cloud(s). If you want to learn more about Content Sync with vCloud Connector you can watch this video. Honestly it’s easy to setup and takes care of ensuring the image is always in sync. Once you have the image in cloud you can use the admin tools of Horizon DaaS on vCHS to create and deploy a desktop pool with the exact same image.
The Fail Over Process (Run Book)
In normal running conditions, the user would connect to view.companyname.com with their Horizon View Client, access their corporate desktop and get to the Wiki Application using http://Wiki01/ from a desktop browser. In order to ensure the client can get to the same application during failure we need to invoke a process such as this:
- Failover the Wiki Application to the vCHS-DR cloud
- Re-IP the application in the new cloud and power on
- Update the local DNS Servers in the IaaS cloud for the Wiki Entry
- Re-Direct External DNS for view.companyname.com to point to the DaaS Cloud instead on on Premises View
- Clients can then log in and access the same application, 100% cloud based on desktop and IaaS.
For illustration purposes the logical diagrams below show the on premises environment along with the disaster recovery, and IaaS environments. Remember that the assumption here is all these have the proper cloud to cloud VPN’s and firewall rules setup for network connectivity per the first image.
Below is the On Premises logical architecture. Notice the desktops are are available behind Horizon View and can connect to “WIKI01″
Below is the Dedicated Las Vegas IaaS cloud that is where the AD/DNS is running for access to directory and name services once fail over occurs. Recall that VPN connections here are in place between the DaaS cloud and the vCHS-DR cloud for access to these services.
Below is the Dedicated Las Vegas DaaS tenant logical architecture. You can see the dtRAM gateways in place on the internet passing connection to the DaaS based desktops in vCloud Hybrid Service. Remember this cloud is connected via VPN to the vCHS-DR cloud so it can access the application below upon fail over.
In the Texas Disaster Recovery Cloud shown below, we can do a full fail over or a test fail over. In each case the WIKI01 server will be connected to one of the two networks. Once it is given a new IP address and DNS is updated the DaaS desktops will be able to connect.
Using External DNS To Manage Connectivity
In order to quickly re-direct a user’s View Client from on premises Horizon View to the DaaS desktop and making it transparent to them you need to get creative. In my case I created the following External DNS records to support this use case.
view.dyn.companyname.org = Public IP of View Secure Gateway (A-Record)
daas.dyn.companyname.org = Public IP of Horizon DaaS dtRAM Gateway(A-Record)
view.companyname.org =view.dyn.companyname.org (CNAME 30 Second TTL)
If you are an avid user of DNS for cases like this you should be able to see why I did this. During normal operations the users always connect to view.companyname.com in their client. However, in a disaster event you FLIP the CNAME to use the daas entry on the back end and when the client connects it’s completely transparent to them they are now on a DaaS cloud based desktop. Pretty simply a clean and easy way to manage this step in the run book.
The Role of SSL Certificates For Clients
Something you want to make sure of in this setup so that all clients, both desktop and tablet based work, is that you need to use proper certificates. You have really two options here to maintain the transparency to the user
- Install the SSL certificate for view.comnpanyname.com on all View Security Servers AND all the DaaS gateway servers.
- Use a wildcard certificate on all the servers
In either case the client is always connecting to “view.companyname.com” so when you flip between Horizon View Servers and DaaS gateway servers, you need the client to be able to authenticate the cert with the same name. The goal here is to make it easy for the end user by not requiring them to change URL’s for their client.
Example Fail Over Video
COMING SOON!
Summary and Conclusions
My entire goal in life with this very extensive lab setup is simply to prove that you can use vCloud Hybrid Service not only for IaaS, DaaS, and DR…..but most importantly you can pull all the parts together into one enterprise level architecture. Instead of using vCHS-DR on the desktops themselves save yourself time and effort. Focus on the applications for DR along with the infrastructure and just leverage vCHS based desktops in Horizon DaaS to connect to those applications you have failed over.
via VMware Blogs http://bit.ly/1qM4qay