vInfrastructure Blog

In the previous posts we have discuss about the architecture and the deployment of NexentaVSA for View. Has you have probably notice the configuration of NexentaStor VSA is really simple: just an OVF deploy, a test to verify that all is fine and a convert to template to be used during virtual desktop pool deployment. Now let’s talk about how use this product, that it’s well described in the User Guide and also in this video.

As written in the previous post, the management appliance could be controller with a simple browser (Mozilla Firefox v9 or later or Google Chrome v12x or later, but seems to work also on Microsoft Internet Explorer 9) using the URL http://ManagementVM:3000.

The GUI elements are:

• NexentaVSA for View bar: the NexentaVSA for View wizards starts when you press these icons.
• Objects List: this area lists all the objects that are associates with NexentaVSA for View. You can select objects from this list to view or perform actions.
• Recent Activity panel: displays current and recent activity status. When a wizard processes an action, the transition status messages are displayed in this area. Click Show all to view the Activity report.
• Working area: displays status, reference, selected actions links for the object selected in the related objects list.

The deploy of a new virtual desktop pool could start from the “Deploy VDI” button (remember that your VMware cluster must not contain any desktop pools, execpt the master golden image, prepared with the guest OS, VMware Tools, View Agent and the Client Agent). Note that you do not need to use anymore the View Manager interface, because the NV4V wizard will orchestrate the entire process.

Pools could be provisioned as Full Cloned or Linked-Clones (using VMware Composer). Also pools could be:

• Stateless virtual desktops (in View Manager are the Automated Floating desktops): do not include any personal settings or data. When users log in, they are assigned a desktop randomly. User can create and stores data on a network file share or on a VMware View desktop persistent disk. When you select the stateless desktop pool type, NexentaVSA for View automatically assigns the Linked-Clones provisioning type.
• Persistent virtual desktops (in View Manager are the Persistent and Assigned desktops): preserve user settings, customization, and data. When users log in, they retrieve their designated desktops. When you select the persistent desktop pool type, NexentaVSA for View automatically assigns the Full Clones provisioning type.

Then the wizard is quite similar to the one in View Manager (maybe a little simple, with less tab to explore), but with a big difference: the Configure Storage tab!

In this step you can choose to Create a new NexentaStor VSA(s) or using an existing external NFS storage (that could be an existing NexentaStor VSA or Hardware Appliance, or an existing NFS share address). The deployment of a new NexentaStor VSA could be completely automatic (if you have prepared the template for it).

The choice to use NFS, instead of iSCSI, is for a scalability reason and to use ZFS locking features, instead of VMFS. I suppose that probably there is also a reason related to the efficiently of the VSA.

Except the storage part the pool provisioning is quite similar to the one in View Manager. But is not similar how you can see and monitor the used resources: the NexentaVSA for View Management interface can summarize if few pages a lot of useful information about your virtual desktop pools.

And is unique the Benchmark part, where you can test and measure several parameters (included IOPS with different tools) and also you can simulate and test a boot storm! The benchmark aspects are completely uncovered by View Manager, and are not so easy to obtain (or analyze) from the vCenter Server.

Also the Calibration is another unique function of this product: using the incremental benchmarks, the Calibration wizard helps you to determine the maximum number of desktops, memory, CPU cores, or cache size that are supported with a selected I/O performance.

Of course NexentaVSA for View does not replace the View Manager and VMware licenses. And does not completely eliminate the need of some kind of shared storage (for the management cluster, if you want/need high availability, but also the user states, if you need them). But could add some really interesting features and also use you host local storage efficiently.

About the cost, it is licenced per virtual desktop and the official price is around 35$ per VM (with gold level support) with a minimum kit of 100 VM (that include also the license for NexentaStor VSA).

Previous posts:

• Introduction
• Architecture
• Deployment

In the previous post I’ve described the NexentaVSA for View architecture and the files included in the download packages. The deployment, installation and configuration is not a simple and immediate step, but is well described in the Installation Guide and also on this video.

There are several requirements for the vSphere datacenter (the NexentaVSA for View environment requires a separate datacenter for each ESXi cluster), the VMware cluster (the NexentaVSA for View environment requires at least one ESXi cluster that contains one or more ESXi hosts, but must also be an empty cluster or are least without any virtual desktop already deployed), virtual networking (basically you need a NFS network, better if dedicated), for the NexentaStor VSA and virtual desktop templates (for virtual desktop remember to install VMware Tools, View Agent and NexentaVSA for View Agent), and so on. All requirements are well described in the Installation Guide (that include also a pre-installation checklist) but some part are betted described in the video. What is really important is that you build a dedicated VMware cluster for virtual desktop hosts (cluster configuration is adjusted automatically by the management part). Also virtual networking configuration is mandatory (unless you have only a single ESXi host).

The installation of the NexentaVSA for View Management Appliance (based on an Linux Ubuntu distribution with credential root/nexenta) is quite simple (just an OVF deployment), but again there are several requirements.

The NexentaVSA for View Management Appliance should be located on the management ESXi host (or a management cluster). NexentaVSA for View Management Appliance requires full network access to all components and must have administrative privileges to vCenter and View Connection Server.

When the VM has been deployed (it will use 1 vCPU, 2 GB of vRAM and 20GB of storage) you can enter in the console to fix networking (by default is in DHCP) and timezone (if needed) and then run the Configuration Wizard.

To enter the Configuration Wizard you simple need a browser (also Chrome 12 and later is supported) to connect to the http://IP:3000 URL (as also prometed on the console).

The main tasks are the product registration, the configuration of the connection to View Connection Server and the configuration to vCenter Server.

Note that on the View Connection Server you must:

• Activate the View Power CLI (by open the View Power CLI as Administrator and type the command “Set-ExecutionPolicy RemoteSigned”).
• Install the NexentaVSA for View Server Agent.

Only in this way you will able to connect your View Connection Server (otherwise you will get a generic connection refused error).

In order to register the product you need a valid Product key, also for the trial version.

To receive the product key you must use the “Virtual Appliance Signature” (prompted in the registration page of the VA) to fill the “Machine Signature” field in the online registration.

The registration procedure maybe could be improved in future version to become more simplest, as also the overhall setup of the infrastructure. But again, the Installation Guide is quite detailed and well done and could really help in a good and successful deployment.

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