EUC5733 – Deep Dive on Horizon 6 Cloud Architecture – Best Practices to deploy HA Virtual Desktop Solution

By | December 9, 2015
  • Cloud Pod Architecture (CPA) used to address challenges:
    • Active\Active Datacentres (for View)
    • Disaster Recovery
    • Deploying across multiple locations
    • Scale beyond 10k desktops
    • Multiple client URLs
    • No visibility on sessions across multiple pods
  • Pre-CPA
    • Single site HA of Horizon, required replicated images across desktop clusters (blocks)
    • Multiple DC HA of Horizon – included lots of replicating of entitlements, orchestration & scripting
      • Very complex, due to infrastructure syncing
      • AlwaysOn Desktop – Active\Active Design

Untitled picture1

  • Cloud Pod Architecture
    • Federated (Pods know each other)
      • Global LDAP Replication – Port 22389
        •  Global ADLDS instance on each CS
      • VIPA (inter-pod communication)
        • TCP 8472
        • TLS protected
        • Cross-site optimisation
    • Scale – Aggregated resources across pods (beyond 10k desktops)
    • Simplified – Global Entitlement & Global Visibility
      • Entitlements replicated
      • Assigns users a Global Entitlement using a policy
    • Single Global URL for both sites (with LB)
    • Balance load across multiple DCs – Active\Active
    • Provides desktop HA and DR for virtual desktops

Architectural Assumptions

Untitled picture2

  • Two sites, 4 pods and 20k users\desktop (maximum as tested). Support Statement from VMware if require more.
  • Global Entitlements are keys, must be in compliance with business rules
  • Doesn’t always require x2 infrastructure investment to support CPA – Depends on what % of users are mission critical
    • Mission critical apps or mission critical user population – 15%
    • Application rationalisation can help
  • Site – Typically a DC, LAN connected, high BW, low latency
  • GE – Aggregates desktop pools across the federation.  Assign entitlement for user at Global level
  • Global Data Layer – Connection brokers in pod federation use this to share key data – Topology, User entitlements, policies and other CPA configuration info
  • Scope – Control amount of cross-site traffic. Defined in a GE
    • Local – Desktop session in Current pod
    • Site – Session in same site
    • Any – Session anywhere in federation
    • Use Case requirement & user expectations
  • Local pod, Site pod then Global site – Try to provide user best experience and keep user local (unless DR or pools are full
  • Home Site – Limit desktop search and allocation a particular site
    • Default home site
    • Per-GE override home sites allow specific GEs to direct users elsewhere (DR use cases)
  • Policy conflicts – Local policy wins.
  • CPA supports dedicated and floating desktops – CPA remembers assigned desktop for each user (if desktop not available, brokering will fail)

Untitled picture3

CPA Initial Gotchas (above) – Removed in v6.2

Untitled picture4

  • Scale-Up – 10K users+
  • Roaming use cases, pods in multiple locations

Untitled picture6


  • One site DR for another
  • HA desktops – Active\Active for LB
  • Biggest Use Cases (so far)
  • User data won’t be solved by CPA, requires replication at array level or DFS

Untitled picture7


  • Create GEs to RDS apps with CPA
    • Type – Application Entitlement
    • Name
    • Policies\Scope (All Sites, Within Site or Within pod)
  • After GE created, add local pools
  • HTML Access aka Blast – Configure in GE and pools

Untitled picture

  • Scalability limits to be increased with next release.  Also working on above (implementation tips)
  • No support today for user to use a Dedicated desktop in two sites, and moving between them.  User is assigned to the first dedicated desktop and remains there.  Home preference for dedicated desktops, coming in feature coming Q1 2016
  • Conduct assessment first, then deployment
    • Validate use cases in accordance to business requirements – SLAs, User Experience
  • CPA gives you access to a desktop, doesn’t protect apps or data – Application rationalisation exercise to figure our mission critical workloads, business critical workloads, then user critical workloads

Leave a Reply