Home > Home Lab, Horizon Suite, vSphere > HOWTO: VMware Horizon View 6 – Overview

HOWTO: VMware Horizon View 6 – Overview

I’m going to be doing a series of documents on how to build a general VMware Horizon View 6 Proof of Concept. This is largely for my own benefit and lab, to better understand the environment and concepts, as well as having a sample environment to test in.

We’ll need to review some basic design plans for this environment. The following questions will need answers:

· Will you be using a unified Single Sign On environment?

· Will your View vCenter be Linked-More or completely segregated?

· Will your installation utilize a service account? If so, your installations should all be run logged in AS that account

· What AD group(s) will be added to vCenter for administration? Small environments might utilize “Domain Admins” or “Enterprise Admins”. You may wish to consider creating a group like “VMware vCenter Admin – View”.

o Consider your naming, and how it interacts with your existing Server/Infrastructure environment. For example if that group is “VMware vCenter Admins” will it now become “VMware vCenter Admins – Infrastructure”?

· You are going to require a number of supporting Horizon Suite infrastructure servers. You’ll need to consider where these are going to live. Your options are:

o In the View cluster/vCenter. If you do this, consider that you’ll basically be configuring this environment as a “greenfield”. You’ll need to have a working host(s), with connectivity to storage, etc. If you’re planning on utilizing vDS, you can’t simply configure the hosts prior to the vCenter. You’ll need to configure the vCenter somewhere first – perhaps on local storage, perhaps on NAS/SAN utilizing vSS, etc. You can then import and migrate the vSS to vDS configuration. But you really shouldn’t do this if you’re on a single host, if your vCenter server is running there. So you’ll want to have at least 2 hosts. You can then upgrade the second host to a vDS, get everything working, migrate the vCenter VM to that host and configuration, and then upgrade the first and other hosts.

o In an existing vCenter. Doing this allows you to spin up the vCenter server in parallel with your hosts, and makes your host/cluster configuration much simpler. Also from a licencing standpoint, this makes the most sense. Most sites will be utilizing Windows Server Data Center with unlimited Windows Server VOSI (Virtual Operating System Instances). If you place the supporting Horizon servers in the Horizon cluster, those host will require either a number of Windows Server Standard licences or additional Windows Server Datacenter licences. In the event that choose to place these servers in your standard cluster, you almost certainly have existing Datacenter licences. Equally, if you are going to utilize VMware vSphere for Desktops, which allows you to run a named amount of VM’s on any number of hosts – you are not licenced to run any server based workloads on those hosts.

· Where will you be storing your VDI VM’s?

o I can’t say that I’ve ever heard of anyone who’s been all that successful deploying on an existing SAN used for other workloads. Your mileage may vary. My lab certainly has no other options.

o Ensure your storage supports VAAI and where possible VCSI. In the case of NetApp, if you happen to be utilizing NFS, remember that VAAI for NFS is an add-in host extension that has to be configured. Also, ensure that the NetApp Virtual Storage Console (VSC) is configured and has optimized your hosts, adapters, MPIO, and connection settings.

o Remember that VDI is “response” oriented, vs “transaction” oriented. Because people are sitting and watching their clicks, and animations and videos, they see and feel every moment of what’s going on. A mail/web/DB server that takes a half second longer doesn’t seem slow. A client window that maximizes with “stutter” gives users an ‘impression’ that you can’t take away.

· Where and how will you be keeping your required DB’s for this?

o Almost certainly you shouldn’t use the SQL Express instances, unless it is a very small environment.

o If your VDI is critical to you, your DB’s should be as well. This means some manner of clustering – and hopefully not something based on LUN’s. Go for SQL Always On or similar.

o You may need to look into specific requirements and limitations. For example, vCenter Server DOES support SQL AlwaysOn using shared disks, but does NOT yet support AlwaysOn Availability Groups – http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1024051. They are clear, they will support it as a “best effort”. So likely you won’t have any issues, but it may be worth calling out.

· What are you doing about your desktop management strategy? If your current deployment process takes days and is largely manual with PFY’s doing a large number of hands on touches to deploy desktops, one by one – VDI is very likely not going to improve anything for you. To have a successful VDI implementation you need to have answers to things like:

o Profile management – where and how are you dealing with users and their personal data? Are you redirecting folders now? Locking out saving to C: drives? Making their experience uniform across desktops? Or do you give them a H:/P:/U: (Home/Personal/User, typically) drive mapped and “tell” them to save files there, and “hope” that they do. Does their mobility experience consist of having that drive mapped on a bare desktop?

o Application management – do you still do application installations manually? Are they one-offs? Are they packaged and done via a tool like SCCM or KACE or anything else? If you’re doing it by hand, VDI is leaps and bounds beyond where you are currently.

o Will you be using Dynamic Floating Pools or Static Fixed Pools? Most companies really want to get into Dynamic pools, and they work great for a call center or something where everyone truly is identical. As you start getting into more complex environments, then you start looking at being forced to play with Static fixed desktops. Once you’ve done that, a lot of the power that comes from VDI (eg: rapid deployment, common platform, DR, etc) all start going away.

· What is your long term goal?

o Are you doing this to “save money”? Is your goal that broadly defined? You’ll quite likely find you’re not saving money on the upfront costs. Infrastructure, licencing, installation design – this is all likely to cost you near or more what you’re paying now for traditional desktops. However, you’re likely to save back end management and operational costs.

o Are you doing this for better management? Remember, if all you’re going to do is create 1:1 fixed VM versions of your desktop, housed centrally, manually administered, with users with local admin rights – you’re not going to find this to be true.

o Are you doing this to improve performance? You certainly could be if you’re putting the user closer to the data. Having the user experience in the datacenter, vs over a WAN or ROBO file server, and at 10GbE vs 1GbE, can drastically improve the user experience. However, if you put 500 desktops on traditional storage with no acceleration, when these users are all used to $500 home computers coming with SSD’s and instant response time… you’re going to have a hard time winning over the hearts of those users.

· What are your DR plans?

o One of the great things about a VDI environment is that you can bring it up in a secondary site quickly and allow users to access it from any old BYOD. As long as you CAN in fact, bring it up easily and quickly somewhere else. Remember, now that you’ve centralized this infrastructure, you’ve centralized your possibility for failure. This doesn’t have to be a bad thing, however, as you can now tackle it in one place vs many. But you do need to consider how you’re going to deal with this. It shouldn’t be a bolt on, after the fact.

If you’re go through all of the above, please, above all else, do an actual Proof of Concept. I’ve seen a few deployments go through where clearly the software was purchased and someone “liked” vendor X, and a product was bought. Then afterwards, the attempt was made to make it fit the needs, after finding out it may not fit the requirements. Also, test your failure points. If you’re going to do a PoC and your live deployment will have load balancers – your PoC should. You’re going to want to ACTUALLY see what happens when you “fail” a host. How long does it take to come back? Does everything you expect come back? Does it behave the way you expect? It’s very easy for things to look good when they’re going good. You also need to know how they fail, so you can ensure it works well even when the going gets rough…  There’s nothing worse than finding out the product’s “core” features are great, but it’s ability to be managed, backed up, recovered, and deal with failures are all nightmares.  You’re better off with something that is an 80% across the board, than 100% in one area, and handful of 40%, in my mind.

As I go forward, I’ll be updating this post with links to the individual posts with the details. Otherwise, I fear I’ll keep all these as drafts, and never post anything anywhere.

 

Horizon View 6 Lab Guide – Table of Contents:

Placeholder 1

Placeholder 2

Placeholder 3

Advertisements
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: