vInfrastructure Blog

In the previous post I’ve introduced the main characteristic of NexentaVSA for View. Now let’s give more detail on the architecture of this solution. The overhall architecture is well described on the NexentaVSA VMware View HW Reference Guide (that include also some interesting sizing scenarios).

In a local storage storage approach we will have the following components:

• NexentaVSA for View Management Appliance: provides the NexentaVSA for View management functions. The Management Appliance is installed from an included template and can be located on any ESXi host in the network.
• NexentaStor VSA: is a virtual storage appliance (VSA) that provides storage management for the NexentaVSA for View DVMs through a NexentaVSA for View vSphere plug-in, which communicates with VMware View and VMware vCenter to perform the actual virtual desktop provisioning and management. Administrators interact with NexentaStor VSA using wizards. NexentaStor VSA is installed from an included template on each dedicated NexentaVSA for View ESXi host.
• NexentaVSA for View Server Agent: that handles all communication between NexentaVSA for View and the VMware components. The Server Agent is installed on the View Connection Server and is mandatory (curios that the common API has not been used instead of this component).
• NexentaVSA for View Desktop Agent: that provides communication between NexentaVSA for View and the virtual desktops. The Desktop Agent is installed on the desktop template, which is installed on each NexentaVSA for View ESXi host. This is not a replacement of the View Agent and/or the VMware Tools. It is need to provide some function not available on both tools (like a deep performance monitoring).

Of course the View and vSphere part are also required in this architecture.

The NexentaVSA for View Management Appliance includes diffents components to “dialogate” with View, vCenter Server and the storage VSA, and also has a web interface with management wizards that allow administrators to simplify virtual desktop deployments and optimize VDI workloads.

For the storage part the NexentaStor VSA is used, in the local storage approach, to for several reasons. Some related to the interesting features of the ZFS filesystem, other of course to push also this part (both for technical but also marketing reasons).

In the shared storage a complete NexentaStor Server, on dedicated systems, is needed (usually in a cluster configuration to guarantee a good high availability).

For the storage, a Hybrid Storage Pool configuration is recommended, in order to optimize the storage performance. The key components are:

• Adaptive Replacement Cache (ARC): the main ZFS cache stored in RAM.
• Level Two Adaptive Replacement Cache (L2ARC): provides a larger, second-level cache to accelerate read operations. SSDs can be deployed here to cache read operations. Sizing RAM is important in calculating the size of the L2ARC (For example, it would make sense to store database pointers in RAM to enable quick access to records in the L2ARC, and to size RAM and theL2ARC accordingly).
• ZFS Intent Log (ZIL): a separate intent log allows synchronous writes to be written quickly and acknowledged in the transactional model that ZFS uses. For VDI workloads, adding SSDs as a ZIL to cache writes significantly enhances performance.

All the software parts are included in a single big file (in tar.gz format) that you can obtain from the download page.

It includes four folders:

• Agents: the server and desktop agents.
• Docs: the installation and user guides.
• NexentaStor_Template: the storage VSA in OVF format.
• NexentaVSAforView: the mamagement part in OVF format.

In the next post we will see how use those files.

NexentaVSA for View (NV4V) is a solution developed by Nexenta, with the collaboration also of VMware, that implement an integrated virtual storage solution for VMware View deployments and provides a interesting approach to VDI implementation.

It tried to solve most of the possible issues or disadvantages of a VDI approach:

• Performance: in common VDI environment the storage could become the bottleneck of the infrastructure, with this solution you can simple scale by adding new hosts (in the same way on how you can scale to add more computational power).
• Cost: it remove the need of a centralized storage (that usually must also have some high level functions to be useful in a VDI environment).
• Complexity: simplifies the complexities of storage and desktop deployment for VDI into one console, greatly streamlining the process.
• Monitoring: while allowing for in-depth analytics, performance testing, and VDI environment calibration.

Basically it integrates a management part (the NexentaVSA for View) with a storage part that could be:

• Local and one for each hosts: by using the NexentaStor VSA
• Shared (as a common shared storage): by using an solution based on NexentaStor Server

About the trade-off between a local or a shared storage approach, see this previous post. The local approach could be the prefered for this kind of product. Also with the power of the new server’s generations (were you can have in only 2U more than 16 cores, more than 1 TB of RAM, more that 20 slots for a 2.5″ HD) each single node could become a complete “building block” in a View design.

With a good VDI design, especially in pool design and user status management, you can move to a local storage approach that could become an interesting way to build a scale-out solution where the gap between VMs and storage is smaller (for more info about those concept see this post). Of course is also a multi-tiering solution to guarantee better performance.

But note that local and scale-out, does not imply that this solution build a single logical, transparent and redundant storage layer (for example as Nutanix does): each local storage is just “local” and if you loose a host you loose the VMs and the data. For this reason you must design well your View pools and also how the user profile is handles. Of course, some data, like the golden image, the user profiles, the View Connections Servers, must reside on a storage with high availability or with a good level of data protection. For user profiles could be not a big problem: a good fileserver is a common solution (and a low cost approach could be implement it with Microsoft DFS+FRS). For the View Connection Server a replica configuration could be an alternative way to provide high availability and also load balancing.

The other solution is use the shared storage approach, but (from my of view) you may loose most of the advantages of NexentaVSA for View.

Also note that the storage part is only one of feature of this product (probably the most important and the most relevant, but not the only one!). The management and monitor part are also interesting, considering that we are talking about a 1.0 version.

For more information see:

• NexentaVSA for View product page
• NexentaVSA for View Tech brief
• Jumpstart VDI Deployments

Next posts:

• Architecture
• Deployment
• Usage