By: Chris Colotti

There have been some popular questions regarding “types of use cases” for VMware vCloud Hybrid Service when used for IaaS, DaaS, and Disaster Recovery as independent services.  However, it’s not all been pulled together into a single architecture example.  I have started setting out on a long venture to build and design a full-scale architecture with the help of a few other business units, most notably the End User Computing group, specifically Kris Boyd who works on “EUC Solutions”.  This will ultimately involve the following components all pulled together in a large single architecture.

• On Premises vSphere
  • AD/DNS
  • Exchange
  • SharePoint
  • Wiki
  • Horizon View Desktops
  • VMware vCloud Hybrid Service Extended Applications (IaaS)
    • AD/DNS
    • Exchange Web
    • SharePoint Web
    • Wiki Web interfaces
    • Horizon View Security Services
    • VMware Horizon DaaS on vCloud Hybrid Service
      • Cloud based desktops for Disaster Recovery
        • Access to failed over applications in the cloud
        • VMware vCloud Hybrid Service – Disaster Recovery
          • Protect on premises applications
          • Connect with DaaS desktops

In order to achieve a full scale setup the first thing that was needed was to get all the VPN networking and connection points between clouds and to the on premises data center.  The diagram below shows the 50,000 foot view of the combined clouds and data center connectivity so you can get an idea about the connectivity we have going on.  For each component we will show some examples of the firewall rules and VPN connections.  We will also drill down into each of the solution’s individual data centers so you can see the “double-click” aspect as we build out this series of blog posts.

Note:  We are making the assumption that the reader already understands the basic means to access their vCloud Hybrid Service resources.

Additionally many firewall rules were created and tested both on and off premises to ensure the first infrastructure of Active Directory was communicating and passing native replication.  This is no different than the previous document I wrote about building your Enterprise IT Hybrid Data Center and extending your datacenter to vCHS.  The purpose here was to make sure we have all the end points connected ahead of time.  Since the basic idea for this is covered in the other paper, we will not review the details of the connections and how to create them.  This is simply an expansion on that original concept for the larger scope.  For our purposes we used VPN but for a production setup Direct Connect would be ideal to minimize latency.

For the purposes of this setup we also have used DYN.com for many of our external DNS needs and some traffic management, as well as F5 Networks Global Traffic Managers for DNS load balancing.  We wanted to make sure our external DNS name space (VMTM.org) was managed through other services instead of being self-hosted.

Part 1 – Extending VMware Horizon View Secure Access

Now that we had the overall infrastructure in place, it was simply time to start building out the various components and applications.  The requirements for the Horizon View setup were as follows:

WDC (On Premises) Data Center

• View Desktops
• View Connection Server
• View Security Server in the DMZ
• Active Directory

Las Vegas (vCHS IaaS) Data Center

• View Security Server in the DMZ

Essentially, all the private view components are hosted on premises in WDC and are on separate network segments between the connection server, desktops, and the security server on the Internet.  When you double click into the data centers below are the diagrams of each.

On Premises Data Center:

Note:  The F5 Big IP pictured is only being used for DNS load balancing so the servers on the public network are still being accessed via the Edge Gateway’s Public IP addresses.

vCHS Las Vegas Data Center:

Since the two sites were already connected via VPN, we just needed to write the firewall rules for the Horizon View application itself.  We first configured the vCloud Hybrid Service firewall with the following rules so that the security server would connect properly to both the connection server and the desktops per the View documentation.  Also we needed to ensure that the public access to the security servers on the Internet was made available through various SNAT and DNAT rules.

Below are some of the examples of those rules from the vCloud Hybrid Service Side.

Also here are some examples of the rules we have on premises also using a vCloud Networking and Security Gateway.

If you have not already figured it out the firewall ruling and thought does take some knowledge so it may not be for the faint of heart and you may need to talk to some of your networking folks.  In our case we control all the access to this environment and all the public IP addresses.  In a previous life I was also a firewall admin so I have that added advantage to be able to write and understand all these rules.

Once all the rules were in place we tested each individual security server via public DNS A-Record.  We first ensured the on premises one was working, we flipped the A-Record to the vCHS based server and tested again.  After we were satisfied both were working properly, we moved to the final stage of load balancing both servers together for redundancy.

Load Balancing the Servers

The real magic here is that you now need a global load balancing solution that will mange the two external IP addresses that correlate to each of the View Security Servers.  The easiest way to do this since they are not in the same data center is using a solution that has DNS based load balancing.  We utilized both F5 Global Traffic Managers and the DYN.com Traffic Manager hosted solution.

We simply created a CNAME in external DNS for view.vmtm.org and we are able to toggle it between the F5 GTM’s and the DYN traffic manager solutions.  The F5’s are setup with one on premise in WDC and the other in the Sterling Virginia Virtual Private Cloud.

The External DNS CNAME simply resolves to one service or the other with a 30 second TTL so we can move it back and forth. In the case of both solutions the setup and configuration of the actual traffic management is different but the concept is basically the same.  The main DNS record resolves to a subdomain which in turn is configured for one of the two view security servers.  So the user only ever needs to know about the main external DNS. Below you can see some of the IP records.

DYN.com Settings:

view.vmtm.org = Primary CNAME

This points to either view.dyn.vmtm.org OR view.wip.vmtm.org

view.dyn.vmtm.org = DYN.com Traffic Manager Pool

F5 GTM Settings

wip.vmtm.org = F5 GTM DNS Authoritative Managed Name space
view.wip.vmtm.org = F5 GTM Wide IP Management Pool

What we are not going into detail here specifically is how all the DNS is configured to make this work, that will be another post or whitepaper.  Needless to say you need to have a solid understanding of DNS records and management since some domains are authoritative in DYN.com and another is Authoritative in the F5.  This is all actually documented by F5 in this article about delegating sub domains.

Understanding the Traffic Flow

Once you have this all configured it is important to understand a little bit of the traffic flow.  The function of the Security Servers is to “Proxy” a user’s connection to the desktop through the security server.  This means if a user connects to the on premises security server via the load balancing, they are localized to the desktop.  If they are connected to the vCHS based security server their desktop connection will traverse the VPN or direct connect link.  This is where direct connect will minimize latency.  However, the availability aspect of having one security server on premises and the other off premises allows you to control the load balancing for maintenance or internet bandwidth purposes.

Now that this is up and running the next stage will be to incorporate VMware DaaS on vClolud Hybrid Service into the mix and see how we can combine the client experience for connecting to DaaS for the purposes of Disaster Recovery into the cloud.  The reason for all this is we needed to simulate client connections to real applications to really show and appreciate the experience.  It is my belief that for Disaster Recovery to really work well you have to make sure you contend for the user’s client connections.  Not every application is web based, which is why we will be standing up some local applications and using vCloud Hybrid Service Disaster Recovery to fail them over and ultimately the user will not even know once they connect using the view client and are connected to the DaaS setup which in turn can reach the failed over application.  You need to be able to see the forest through the trees a little bit here as we post the next set of aspects.

Chris is a Principal Technical Marketing Architect with the vCloud Hybrid Services team with over 10 years of experience working with IT hardware and software solutions. He holds a Bachelor of Science Degree in Information Systems from the Daniel Webster College. Prior to VMware he served a Fortune 1000 company in southern NH as a Systems Architect/Administrator, architecting VMware solutions to support new application deployments. At VMware, in the roles of Consulting Architect, Chris has guided partners as well as customers in establishing a VMware practice and consulted on multiple customer projects ranging from datacenter migrations to long-term residency architecture support. Currently, Chris is working on the newest VMware vCloud Hybrid Service solutions and architectures for vSphere customers wishing to migrate to the VMware Hybrid Cloud Service. Chris is also a VMware Certified Design Expert, (VCDX #37).