One of the big questions regarding virtual desktops is storage. In fact, I’ve discussed this numerous times (here and here and here). This has mostly been with a focus on IOPS. This time I want to focus on the high-availability aspect you get with shared storage, but with the focus of being on the SMB/SME space (small to medium business/enterprise). If you want to do live migration, you must have shared storage. So, let me get straight to the point… You don’t need it. You don’t need XenMotion, vMotion or live migration in a SMB hosted VM-based desktop model. Look at the XenDesktop architecture and let’s focus at the component-level.

  1. Virtual desktops: Desktops are not servers. They aren’t as critical and shouldn’t reflect a higher cost. If the physical server fails, users simply make a new desktop connection.
  2. XenDesktop controller: Always, always, always implement redundant controllers. XenDesktop is smart enough to use a second controller if the primary fails. Is also worthwhile to put intelligent load balancing in front to catch other types of issues that don’t result in complete failure.
  3. Web Interface: Again, use redundant servers, but you need to provide intelligent load balancing so if one fails or goes off into La La Land, you won’t be directed to a bad server.
  4. NetScaler VPX: This is providing our intelligent load balancing mentioned for XenDesktop controllers and Web Interface. Again, implement redundant VPX’s. If you configure these in HA mode, a failure in one means the other one takes over automatically.
  5. Data Store: You can function without the data store, but you can’t make changes. Why not simply create snapshots and revert if needed. Or backup the database and restore if needed. You can even automate this if you want.
  6. License Server: You can function without a license server for 30 days (grace period). If the server is blown up, just rebuild the server and download your licenses (I’d also suggest you figure out why your server is blowing up).
  7. Provisioning Services: If one server fails, the other one takes over the streams automatically. The target desktops might experience a delay during the failover, but they won’t lose anything.

So I ask you, why spend money on SAN storage for virtual desktops in the SMB world if it is just going to cost you more money? Keep it simple

1 thought on “SAN, VDI and SMB”

  1. The problem is in excess of IOPS that creates a virtual desktop platform, from my point of view, this is the biggest problem facing a virtualization solution, so much so that even the server containing the virtual environments are affected, this must be added to the antivirus solution generates a non-negligible consumption of IOPS.
    For me, the solution, with a farm of 2000 users has been the migration to solid state drives for servers and data for each user that uses a virtual machine is stored in an external nas.


Leave a Reply

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

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

Google photo

You are commenting using your Google 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 )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.