Home > Blogs > VMware Consulting Blog > Monthly Archives: September 2014

Monthly Archives: September 2014

How-to: Create a vCOPS for View At-A-Glance High-Level VDI Dashboard

By Anand Vaneswaran

Anand VaneswaranVDI environments are complex because there are so many moving parts. As a result, there is a real need for architects, admins, managers, or operations professionals to see a high-level breakdown of the most important stats—stats that are especially important when we receive that escalated phone call about an issue that could potentially affect a large number of users.

In this first post of a three-part blog series, I’ll provide details about a high-level VDI custom dashboard in vCenter Operations Manager for View that was renamed vCenter Operations Manager for Horizon when Horizon 6.0 was released. (I’ll also assume you’re all well versed in VDI.)

To start, some of the stats or information I deeply care about in my test environment are as follows:

Download

Download the Step-by-Step

  1. Viewing the number of tunneled connections that are coming in through my security servers.
  2. Viewing the overall health of my connection servers.
  3. Keeping tabs on the resources (CPU, RAM, Disk) of my most critical VDI servers (Connection and security servers, vCenter server, View Composer, etc.).
  4. Monitoring resources (CPU and RAM) on my ESXi hosts running VDI workloads. (I will go one step further and break it down into hosts for my full clone pools, and linked clone pools.)
  5. Finally, looking at my LUNs and keep tabs on a number of metrics, but most importantly VM-to-LUN densities.

When compiled together, the information listed above comprises the end-state dashboard I want to achieve. The dashboard will have two generic scoreboard widgets on either side to depict the number of user connections through my security servers and the workload percentage of my connection servers. In addition, two Health-Workload scoreboard widgets on either side will depict the health of security and connection servers. The scoreboard is set up so that when you click a particular object in the Generic Scoreboard widget, the scoreboard is automatically populated with the health of that relevant object.

Finally, I want four Heat Map widgets: one to provide information about critical server resources, two to give me updates on ESXi host resources, and one to give me details about VM-to-LUN densities. I chose to populate my dashboard with an assortment of these built-in Generic Scoreboard, Health-Workload, and Heat Map widgets because I find that these types of widgets provide the most efficient means of graphically conveying the state of an environment, in essence, a point-in-time snapshot of your environment at any given time.

Now, if you’re ready to build, get detailed, step-by-step instructions for creating the dashboard.


Anand Vaneswaran is a senior technology consultant with the End User Computing group at VMware. He is an expert in VMware Horizon (with View), VMware ThinApp, VMware vCenter Operations Manager, VMware vCenter Operations Manager for Horizon, and VMware Horizon Workspace. Outside of technology, his hobbies include filmmaking, sports, and traveling.

How-to: Find Composer Certificate in VMware Horizon View Administrator

By Gourav Bhardwaj with Matt Larson

GouravMatt LarsonWhile performing a Health Check on a customer’s VMware View 5.2 environment, one item that came up was to verify that the SSL certificate was configured appropriately. VMware recommends the replacement of self-signed certificates with certificates that are signed by a Certificate Authority.

When entering a new environment, or performing a health check, the most well-known approach to determining the certificate used by View Composer is using the sviconfig command referenced here, which is also used to replace the certificate.  During the replacement process, the existing certificate will be listed.  That being said, running this command requires stopping the Composer service. If there are any Composer downtime constraints; the following alternate process can be used to determine the current certificate.

In VMware Horizon View Administrator, you can determine whether the certificate is signed by a well-known certificate authority.  In the case below, the certificate is self-signed.

Composer1Block

Looking at the Certificates Management Console, multiple certificates are listed, but how do you know which one is in use?

Screen shot

To find which certificate is in use, check the registry to see the thumbprint of the certificate bound to the port used by Composer.  Find this by navigating to \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\HTTP\Parameters\SslBindingInfo\0.0.0.0:18443 key in the registry, and noting the SslCertHash.

Screen Shot

Match the hash listed in the registry to the hash listed on one of the certificates listed in the Certificates Management Console.  The match is the certificate currently used by Composer.

Composer_4

As seen in the console, this certificate is the self-signed certificate that was created during the Composer installation process.  It is also expired.  To change the certificate, follow the article listed earlier in reference to sviconfig.

Stay tuned for more posts about evaluating the health of the virtual desktop environment.


Gourav Bhardwaj is a VMware consulting architect who has created virtualized infrastructure designs across various verticals. He has assisted IT organizations of various Fortune 500 and Fortune 1000 companies, by creating designs and providing implementation oversight. His experience includes system architecture, analysis, solution design and implementation.

Matt Larson is an experienced, independent VMware consultant working in design, implementation and operation of VMware technologies. His interests lie in enterprise architecture related to datacenter and end user computing.

Running Microsoft SharePoint FAST Search on vSphere

By Girish Manmadkar

Girish-ManmadkarI recently worked with an enterprise customer to resolve end user reports of performance issues related to Microsoft SharePoint 2010 and FAST Search deployed on vSphere 5.1. The end users were reporting problems with initial page response and file upload and download. The customer requested architecture guidance, including a performance health check across the entire infrastructure stacks. The result of this engagement is the following architectural guidance, designed to help customers with similar deployments achieve maximum performance for Microsoft FAST Search on the VMware platform.

Specifics
The customer deployed the SharePoint FAST Search Farm with the following key components:

Software Resources

  • VMware vSphere 5.1 Update 2
  • Windows 2008 R2
  • SharePoint 2010
  • Microsoft SQL server 2008 protected with MSCS in 3 node cluster

Hardware (Virtual) Resources

Role

RAM

Local Disk

#CPU

NIC

Total VMs

Total #CPU

Total Mem (GB)

SQL
2012 Cluster Node A, B & C

32

C: 80
GB

4

2

3

 

 

E: 100
GB

12

96

WebFront End
Server

8

C: 80
GB

2

2

5

 

 

E: 50
GB

10

40

Application
Server

16

C: 80
GB

4

2

4

 

 

E: 50 GB

16

64

Services
Application Servers

16

C: 80
GB

4

2

2

 

 

E: 50
GB

8

32

Fast
Administration Server

16

C: 80
GB

4

2

1

 

 

E: 50
GB

4

16

Query
Indexer

16

C: 80
GB

4

2

5

 

 

E: 50
GB

20

80

Allocated Total Memory = 328 Gig
Allocated Total vCPU = 70

Sample FAST Servers Architecture

Discovery
During discussions and white board sessions with the customer, we encountered following issues with the deployment:

  • Storage
    • The virtual machines running query and index services were sharing the LUN and the data stores.
    • Thin provisioning was being deployed at the vSphere and EMC storage array layer.
    • The RDMs used for the SQL server MSCS environment were configured with incorrect (MRU/fixed) multi-pathing options.
  • Virtual machines had no lock pages for SQL and no memory reservations.
  • Various SQL server databases were being deployed as shared SQL instances for the entire FAST Search environment.
  • The networking configurations were set incorrectly for certain SCSI adapters.
  • Typical traffic within the guest operating systems, VMotion, and backup were not channeled properly.
  • There were no anti-affinity rules in place for the application servers within the vSphere farm.
  • The CPU subscriptions across the overall farm seemed unbalanced.

Approach/Recommendations
Throughout a series of discussions we learned more about the architecture and identified the following steps to improve performance:

  1. Reconfigure multi-pathing per EMC’s recommendations for vSphere5.1 to round robin. (This change showed immediate performance improvement.)
  2. Enable memory reservations with “Lock Pages in Memory” for SQL workloads.
  3. For a write-intensive application like FAST Search, use four (4) vSCSI controllers to separate volumes for operating systems, binaries, data, LOG and TEMPDB disks with window full format option to avoid additional write penalty.
  4. Absolutely avoid CPU over commitment in the production environment.
  5. Adopt best practices on vSphere to separate various networking traffic, including dedicated backup, which in this case was previously sharing VM traffic.

Conclusion
For any business-critical application to run with optimum performance, you must put performance ahead of consolidation and avoid over commitment of CPU and memory. Once you implement these principals for the production environment, any performance issues for business-critical applications on vSphere will be alleviated.


Girish Manmadkar is a veteran VMware SAP Virtualization Architect with extensive knowledge and hands-on experience with various SAP and VMware products, including various databases. He focuses on SAP migrations, architecture designs, and implementation, including disaster recovery.