PVS vs MCS – Part 6: Architecture


This is part of a series comparing Provisioning Services and Machine Creation Services

In the previous blogs comparing PVS with MCS, I focused on functionality within each technology, but this time I’m focusing on how easy is it to manipulate.

Consider the following:

  • A single XenApp/XenDesktop (including Machine Creation Services) architecture can span multiple geographical sites.
  • A single Provisioning Services architecture can span multiple geographical sites.

However, having a single XenApp/XenDesktop/Provisioning Services farm span across multiple geographical sites might not always be the correct architecture.

Imagine you have two major data centers, each hosting virtual desktops/apps.  You have XenApp and XenDesktop hosts in each data center.  Do you define zones for each data center and implement a single XenApp/XenDesktop environment or do you deploy two environments: one for each data center?

The correct answer is based on the unique characteristics of the organization and their risk tolerance. Risk sensitive organizations will want to reduce the size of their failure domain, resulting in two separate environments. If there is a catastrophic failure, it only impacts a portion of the environment.

If you follow this path, you need to devise a plan on how to replicate the master images between sites.

  • With Machine Creation Services, the admin must work in the hypervisor and export/import the master image  to the different sites and resource pools.
  • With Provisioning Services, the admin simply copies the image file to the other site. In fact, this is the same process many Provisioning Services admins already use to keep images synchronized across multiple servers. And to streamline this process, many admins create simple scripts to copy images when changes are detected.

Even though it is possible to keep images synchronized across multiple sites if you are using Machine Creation Services or Provisioning Services, I believe the simplicity of copying Provisioning Services image files gives it an edge for this criteria.

Sites

Daniel (Follow on Twitter @djfeller)
XenApp Advanced Concept Guide
XenApp Best Practices
XenApp Videos

Advertisements

2 thoughts on “PVS vs MCS – Part 6: Architecture”

  1. Have you looked into the feasibility of using Content Libraries (introduced in vCenter 6.0) to synchronize MCS images between different sites? I haven’t but after reading your post it sounded like something that could potentially help with this ‘gap’. It supports pub/sub sort of architecture for synchronizing templates, files, etc. across vCenters although it’s got some limitations since it’s really a 1.0 implementation.

    Like

    1. Not had a chance. I do wonder if MCS would be able to see and use the items within the content library or if it is something accessible from vCenter only.

      I would still wonder if simply copying PVS vDisk files is easier.

      Like

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