Reference architectures for virtual desktop infrastructure provide a relatively simple solution to the otherwise...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
complicated task of choosing hardware and software for VDI. An increasing number of vendors are publishing reference architectures as VDI has risen in popularity, and for a shop just starting out with virtual desktops, these guidelines can streamline deployment. However, since they're vendor-specific, a reference architecture might present guidelines that you're not interested in adhering to. In this podcast, Ray Lucchesi, president of Silverton Consulting and storage blogger, talks about which IT shops are best suited for the use of reference architectures for Citrix XenDesktop or VMware View environments, and how to go about choosing the right one. Listen to the podcast or read the transcript below.
For an IT shop using Citrix XenDesktop or VMware View, what would a reference architecture bring?
Lucchesi: Reference architectures provide a framework and a description for how to configure storage, servers and networking to support VMware View or Citrix XenDesktop. They provide it from a vendor-specific perspective, but nonetheless, it can provide an easy way to start up and start using those facilities if you're interested.
Are there any scenarios where an IT shop would not want or need a [VDI reference architecture]?
Lucchesi: I think most shops that have a lot of experience with VMware View or Citrix XenDesktop may not need a reference architecture because they already understand how to use it [as well as] some of the hardware (server, storage, networking) that is required to support it. But for those customers that are fairly new to those environments or solutions, reference architectures can provide a quick way to get started.
How would an IT shop go about choosing a reference architecture for VMware View or XenDesktop?
Lucchesi: I think some attributes of reference architectures are fairly critical from my perspective. It's important that they include everything required to support that solution. That would include storage, networking, server, software, those sorts of things, and the configurations for those particular infrastructure items as well. It would be nice if the reference architectures had specific model numbers and storage characteristics -- ports, counts, that sort of thing -- [that] were used to support the reference architecture. It would also be nice if there were some sort of indication of how many desktops were being supported by reference architecture. Was it 1,000 desktops? Was it 10,000? Was it 500? It would also be of interest if there [were] some sort of indication in the reference architecture as to how to scale. Let's say the reference architecture was for 500 desktops, for instance, and you were interested in going to 750 -- if the reference architecture had some sort of indication of what it would take to go to that level, it would be useful.
Do you think there are any drawbacks to using a [VDI] reference architecture, and if so, what are they?
Lucchesi: I think there are some drawbacks with using reference architectures. It's primarily a vendor's viewpoint. So you might see a reference architecture for VDI, for instance, with Cisco and NetApp gear -- Cisco servers and networking, and NetApp storage -- but you're not necessarily going to see an HP solution with EMC storage. So you're going to get a vendor's view. So EMC has reference architectures out there using their preferred suppliers; HP has the same sort of thing; Dell has the same sort of thing, Cisco, NetApp. IBM for sure -- they're going to show a reference architecture for Citrix XenDesktop with IBM servers, IBM networking and IBM storage. So the challenge there is that you're going to get one vendor's view or perhaps a set of vendors' views (one from servers, one from storage) that you may or may not be interested in adhering to.