Home > Blogs > VMware Consulting Blog

Simple VDI Load Testing with View Planner

Jack McMichaelBy Jack McMichael, Solutions Consultant

In the last few years it seems the number of customers asking for assistance in re-evaluating their “VDI 1.0” infrastructure is increasing at a faster rate than ever. It makes sense when you consider that in the rush to achieve datacenter consolidation many administrators were under pressure to just “make it happen.” Many of those administrators and architects didn’t have time to design their virtual desktop infrastructure (VDI) solution to scale and accommodate things our customers and users have grown accustomed to using every day, such as YouTube HD, Skype, and other resource-intensive applications.

Last year, VMware released their very popular internal tool View Planner for use to the general public for free. While it’s flown under the radar for a lot of customers, it can be an invaluable tool for judging where your VDI solution stands, and identifying where the stress cracks in your VDI infrastructure may be forming—or are already wide open.

The View Planner appliance is simple to install and fairly straightforward to set up for local tests. It’s capable of local-only load testing, as well as passive/remote connections with the VMware Horizon® Client.

Deploying View Planner

After deploying an Open Virtual Appliance in VMware vSphere®, configure your View Planner integrations in the Config tab of the administrator page. The AD and View integrations are optional, but can be used if you wish View Planner to deploy desktops and/or create and delete users.

Note that for best results, I recommend using IP addresses instead of hostnames. Create a service account for your credentials, and give it administrator privileges in both AD and in VMware vCenter™.

In this screenshot, you can see all three connectors configured. You can use the Test buttons to ensure the configuration works, but click Save first.

JMcMichael 1

Environment Preparation

For my simple test, I created a linked clone pool with the name VPDesktop-{n:fixed=3} in VMware Horizon View™. On this master snapshot, I added the View Planner Desktop Agent that you can download from the View Planner portal on the Packages tab.

Make sure you reboot your desktop before creating your snapshot. Once you reboot, you will likely see the desktop auto-login. If so, run the View Planner Agent as seen in this screenshot.

JMcMichael 2

 

Configuring Run Profiles

There are three test modes available: Local, Passive and Remote. Typically, Local mode will be used for load testing since it doesn’t require actual Horizon Client connections, but has the disadvantage of not replicating PCoIP performance impact. Passive mode will add PCoIP connections that are shared amongst client servers that host more than one client connection at a time. Remote mode will create a 1:1 relationship between clients and desktops, thus creating the most overall resource impact.

To configure a Run Profile for a simple load test, I recommend using Local as it doesn’t require the use of the Horizon Client, and is also easy to set up. Simply add the Workload profile you want to run into the Run Profile by clicking Add Group, and click Save to save the Run Profile. You can add multiple workload profiles if you desire, but for a simple test only one is required.

The most important thing to remember is that desktop names (and client names if you choose Passive or Remote) are case-sensitive. In this example, VPDesktop- is valid for VPDesktop-001, but not vpdesktop-001 or VPDesktop001.

JMcMichael 3

Running a Test

Simply click the Run button to start a test. If you run into trouble, View Planner will show you right away; by clicking the link on the appropriate box, you’ll see the exact error or success message.

JMcMichael 4

 

Once completed, you can view the results in the Per Stats column; they will look something like the example below.

JMcMichael 5

Summary

Overall, I found the View Planner tool to be great for simple and quick tests of a VDI environment. It shows you where resource contention exists, or singles out how an app may be creating resource gaps in your VMware ESXi™ hosts. The free downloadable version includes several standard templates that cover a variety of normal user application workloads. If you require more flexibility in your tests, a paid VMware Professional Services engagement offers a more feature-rich version to create customizable workload profiles and other goodies. Contact VMware Professional Services or a VMware Partner for an on-site evaluation.

 


Jack McMichael is a Solutions Consultant for the VMware Professional Services Engineering Global Technical and Professional Services team. Follow him on Twitter @jackwmc4 !

So You Virtualized Your Desktop Environment. Now what?

mmarx.phpBy Mike Marx

Most of my customers start with a low-risk user group consisting of a large number of users with identical application requirements. This is the common scenario when starting out on the virtual desktop infrastructure (VDI) journey and 'testing the waters.' With proper design efforts, initial implementations are highly successful.

I spend the majority of my consulting effort working with customers helping them create their initial VDI design. Designs can be simple or complicated, but they all utilize a common technical approach for success: understanding user requirements, and calculating infrastructure sizing. But I'm not blogging about technical calculations or infrastructure sizing. Instead I would like to address a VDI design challenge customers face as they expand their VDI design: user application assignments.

While resource requirements are simple to assess, calculate and scale, application delivery becomes increasingly challenging as more users are added to the design. VDI administrators struggle to manage increasing numbers of desktop users – each having unique application requirements.

Applications are easy to add to a large static group of user desktops using linked-clones. But when unique user groups are introduced, and application requirements change, administrators are confronted with the challenge of maintaining a large number of small desktop pools – or impacting large groups of users in order to change an application assignment.

So how do we design an effective stateless desktop and maintain application diversity amongst unique user groups? VMware Horizon AppVolumes is the answer.

Using AppVolumes, VDI designs become simple to understand and implement. Once applications are effectively removed from the VDI desktop, VDI administrators are left with a simple stateless desktop. But users aren’t productive with an empty desktop operating system; they need applications – and lots of them.

Without going into deep technical detail (there are excellent blogs on this topic already) AppVolumes captures the application files, folders and registry components, and encapsulates them into a transportable virtual disk called an AppStack. As the user logs on to a stateless desktop, the assigned AppStack(s) will automatically attach and merge the user's applications with the desktop virtual machine.

Now users are presented with a stateless desktop that is uniquely assembled with all of their applications. AppVolumes’ attached applications interact with other applications— and the operating system—as if they were natively installed, so the user experience is seamless.

Now that applications are no longer an impediment to VDI designs, VDI administrators are able to support large groups of users and application requirements using the same stateless desktop pool. By following the KISS principle: "Keep It Simply Stateless," AppVolumes will open the door to new design possibilities and wider adoption by users and IT administrators.


Mike Marx is a Consulting Architect with the End User Computing group at VMware. He has been an active consultant using VMware technologies since 2005.  His certifications include : VCAP-DTD, VCP-DT, VCA-WM, VCA-DT, VCP2-5 as well as being an expert in VMware View, Thinapp, vSphere and SRM.

App Volumes: Storage Migration for AppStacks

Jeremy WheelerBy Jeremy Wheeler

Inside of App Volumes you can accomplish a storage migration between different SANs using the feature called 'Storage Groups,' provided you have shared storage between App Volume Managers. If you don't, I recommend creating a temporary LUN/Volume to accomplish this migration. If you are performing a migration on a large scale, such as 2X or more App Volume Manager instances, you will need to perform steps one through eight on each App Volume Manager instance.

Conceptual architecture:

JWheeler AppVolumes Manager Conceptual Architecture

 

To achieve a successful migration we will need to utilize a shared LUN/Volume between datastores. This can be an NFS or iSCSI datastore and will only be used temporarily to complete this process.

JWheeler AppVolumes Migration Setup

Stage 1: Migration Startup

  1. Select ‘Infrastructure’
  2. Select ‘Storage Groups’
  3. Give your storage group a name (my example: migration_temp)
  4. Check 'Automatically Replicate AppStacks' and leave 'Automatically Import AppStacks' unchecked. If you check the 'Import AppStacks' checkbox, you will need to do a lot of cleanup if you were using a temporary LUN to do this migration.
  5. Select 'spread' for your distribution strategy.
  6. Select your preferred template storage.
  7. Select 'direct' for storage selection.
  8. Select the checkbox of your local shared storage. This field will represent where you currently have the AppStacks you want migrated.
  9. Select the checkbox of your Temporary LUN. The temporary LUN is assumed empty or the AppStacks you want migrated over are not on the temporary LUN.
  10. Select 'Create’ 

Once your storage group is created replication will begin immediately; it might take awhile depending on how many AppStacks you need to distribute within the storage group.

Stage 2: Cleanup

  1. After all AppStacks have been evenly distributed in the storage group, you can simply delete the storage group. This will not delete any AppStacks – it simply disassociates the logical bucket of resources. Both the source LUN and temporary LUN will still have the AppStacks.

Load the VMware vSphere® client and move any AppStacks from the temporary LUN to the permanent shared storage LUN, and then to the View Block.

JWheeler AppVolumes View Block

I want to dig further into explaining this process about moving AppStacks from the temporary LUN. App Volumes create pointers to all AppStacks residing on storage. This means in our example (shown above) when we replicate an AppStack between two points the inventory object in App Volumes Manager will consider all these locations as the AppStack living space. This also means that if you decide to delete an AppStack from inventory, ALL pointer locations will also be deleted. So, if you need to clean up the App Volumes Manager inventory in your Source Environment, you will need to copy, move, or detach the temporary LUN you created prior to deletion. The process for doing that is explained here.

JWheeler AppVolumes

a)      Move AppStacks from cloudvolumes/apps/* to a temporary folder /cloudvolumes/apps/tmp/* using the vSphere C# client, GUI, or vSphere command-line.
b)      Delete AppStacks from Source inventory.
c)      Move AppStacks from cloudvolumes/apps/tmp/* to a permanent shared storage in the target environment folder /cloudvolumes/apps/* using the vSphere C# client, GUI, or vSphere command-line.
d)      Select ‘Import AppStacks’ in App Volume Manager under Volumes > AppStacks.
e)      Select the LUN you moved all the AppStacks into (step c).
f)       Set the root path of where the AppStacks will live and select 'Import.'

You can also use 'vmkfstools' if you have shell access to a host that can see the shared storage. This process is a lot more manual compared to using App Volumes Storage Groups, but you can still accomplish the migration using this method.

Execute the following syntax:

vmkfstools -i </source/location> </dest/location> 

This will copy the VMDK file in its current format from source to target.
(AppStacks VMDKs are Thin Provisioned by default).

Once you have copied the AppStacks you will need to 'Import AppStacks' from the App Volume Manager
(Volumes –> AppStacks –> Import AppStacks).

Reference this Knowledge Base for additional information when using the vmkfstools command:

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1028042

For more information, be sure to check out the following Education Course:


Jeremy Wheeler is an experienced senior consultant and architect for VMware’s Professional Services Organization, End-user Computing specializing in VMware Horizon Suite product-line and vRealize products such as vROps, and Log Insight Manager. Jeremy has over 18 years of experience in the IT industry. In addition to his past experience, Jeremy has a passion for technology and thrives on educating customers. Jeremy has 7 years of hands-¬‐on virtualization experience deploying full-life cycle solutions using VMware, CITRIX, and Hyper-V. Jeremy also has 16 years of experience in computer programming in various languages ranging from basic scripting to C, C++, PERL, .NET, SQL, and PowerShell.

Jeremy Wheeler has received acclaim from several clients for his in-¬‐depth and varied technical experience and exceptional hands-on customer satisfaction skills. In February 2013, Jeremy also received VMware’s Spotlight award for his outstanding persistence and dedication to customers and was nominated again in October of 2013

Virtual SAN: An Ideal Choice for Management Storage

MHoskenBy Martin Hosken

The practice of separating management components onto a dedicated vSphere cluster has become common practice in recent years. However, such a cluster should aim to have no dependencies on the production systems with one of the key requirements being that any type of incident or outage affecting the production system does not affect the management cluster, and likewise any management cluster outage cannot affect the production workload systems.

In the past, providing dedicated out-of-band storage for management-only clusters could be cost-prohibitive. It was necessary to purchase additional independent storage hardware for management clusters that could provide the performance and availability required for I/O-intensive and highly available virtual machines, as well as to provide expensive isolated storage fabric to provide connectivity to the management-only array. VMware Virtual SAN provides a highly performant shared storage platform across the vSphere cluster making it possible to significantly reduce costs whilst maintaining enterprise levels of availability and performance.

Martin Hosken Whitepaper

This makes Virtual SAN the ideal choice to provide true out-of-band management storage to a dedicated management cluster, making this type of truly independent management environment a viable and affordable option for most medium and large organizations.

This white paper provides a detailed rational and design for utilizing Virtual SAN in a dedicated management environment.


 

Martin Hosken is a Global Cloud Architect, VCDX and vExpert 2015 in the Global Cloud Practice – vCloud Air Network

VMware User Environment Manager Deployed in 60 Minutes or Less

Dale-Carter-150x150By Dale Carter

With the VMware acquisition of Immidio, announced in February 2015, VMware has now released VMware User Environment Manager (UEM). In the last several weeks I have been doing some internal testing with UEM and looking at the different things the software can do, and how this will help administrators manage users and improve the user experience.

After the acquisition was complete I kept hearing internal conversations about just how easy UEM is to deploy and get up-and-running, as there is no extra infrastructure needed to configure UEM. All that is required to configure UEM is:

  • A couple of file shares
  • Configuration of group policy objects (GPOs) on the User organizational unit (OU)
  • Installation of UEM agent and manager software

Unlike a lot of other management software, VMware UEM only requires that the software is installed on one or more administrator desktops. There is no management server component other than network file shares and configuration of a few GPOs.

Given the simplicity of the installation, I decided to document how easy it is to get an enterprise-ready solution deployed in less than 60 minutes. Now, this is a basic deployment for 50 linked clone virtual machines, but you’ll see just how easy it is to deploy and configure them. For an enterprise with many sites, decisions need to be made about configuring network shares and where to place them on the network. But most of the work, as you will see, can easily be accomplished in 60 minutes or less. Read the VMware User Environment Manager Guide below:

DCarter UEM 5

 


Dale Carter is a CTO Ambassador and VMware Senior Solutions Architect specializing in the EUC space, has worked in IT for more than 20 years. He is also a VCP4-DT, VCP5-DT, VCAP-DTD, and VCAP-DTA.

Perform Proactive Load Testing to Build a Successful Environment

Hans BaderBy Hans Bader

So, your company has bought a new set of hardware, referenced the latest white papers and reference architectures, and now will get the virtual machine (VM) densities promised, right? Well, maybe not. White papers and reference architectures are great starting points for designing and building your environment, but unless you are running the same workloads, your mileage may vary. The key to knowing what your infrastructure will support is to proactively perform load testing – before going into production.

Successful load testing is a considerable amount of work; it involves creating synthetic workloads, and understanding the metrics and the impact on the end-user experience. Holistic load testing will bring in different teams: storage, networking, compute, application development, software distribution and virtual infrastructure. Each of these teams has a stake in ensuring a good end-user experience.

Manage, Understand, and Set Expectations

Understand that the performance of a virtual desktop is all about the performance the end user (your customer) is seeing and perceiving. Gathering all the metrics from VMware vCenterTM, PCOIP logs and storage IOPS are all important, but ultimately it is the end-user’s perception and experience that is most important. It is easy for an administrator to say, “The VM has 2 GB out of 4 GB of memory free,” but if the user is experiencing poor performance due to network contention, the end user is still unhappy.

You must set the proper expectations and understand what you can test. Generating CPU and memory load inside the guest is relatively easy with tools such as Iometer. Iometer does a great job of generating compute load, but does not provide any user experience metrics. With remote desktops the challenge becomes testing PCOIP and client-desktop communication.

Have Your Plan in Place

Have your testing methodology, objectives and metrics documented in advance. It is important to develop your test design before starting the actual load testing process. Think it through completely; map the information flow for the entire load test process, entry points and process dependencies. If you are going to create a view pool of 1,000 desktops, will the LAN segment where you will be creating the desktop have enough IP addresses available? Do you know that anti-virus updates are a known pain point? Include these in your testing scenarios. Also include software updates if applicable.

Understand what is going to be tested and how the testing will impact end users. The end-user experience with virtual machines is more than just performance graphs of the VM in your vCenter inventory. Are you testing a local install of Microsoft Word, or a larger client-server based application? Many of the applications running in a virtual desktop are dependent on systems (databases, web services, etc.) that exist outside the desktop. Do you have an information flow diagram that shows all the systems an application may interact with? Do you know where the choke points are? Adequate desktop resources are not sufficient if you are load testing 1,000 desktops running a CRM application – but the environment can only scale to 750 users.

Your End Users Can Help You

During testing do not rely solely upon metrics: your testing must include “eyes on the glass.” Have actual users run through the test scenarios to understand how—as the load increases—the user experience may be impacted. An end user can establish what a good baseline is, what acceptable performance is, and when the end-user experience starts to degrade. These subjective user perceptions can be roughly mapped to network metrics, storage latency or memory usage.

Documented Test Plans

Leverage existing test plans where possible. Many times there are existing test plans for applications that have been developed in-house. These are company- specific and require domain subject matter experts to create and execute on. Utilizing these people can decrease the time and effort required to create and document your current test plans.

Test What is Real

This very important concept is often overlooked. Don't simply consider CPU and memory consumption of a virtual machine. Running CPU Busy and generating 100 percent CPU usage inside a VM is not realistic. To generate accurate user experience loads you must use appropriate tools, such as:

Proper load testing of your new environment means testing both your architectural and physical designs. It is important to understand how the user load may impact your initial physical design. The number of hosts per cluster, desktops deployed per data store, and network connectivity all come into play. You may find you have been overly conservative in your resource assumptions; but you can change your cluster sizing and therefore obtain greater desktop densities.

During your load testing, use this time to understand the impact on typical administrative tasks while running the hosts. For example, how long does it take to spin up a new pool of 500 desktops when you are running a load test with 1,000 desktops? Or how long does it take to put a host in maintenance mode when it has 80 desktops running? The outcomes of these ancillary tests may change the way you administer your environment.

Expose the Weak Links

What if, during your load testing, you break something? Perhaps you’ll run out of DHCP addresses, the KMS server and your hosts start swapping, LUNS run out of space, and VMs crash. These events should not be considered failures, but rather successful tests. These events show you where to focus attention prior to the next load test so real users do not experience these problems during live operations. Yes, load testing can be a lot of work, and take a considerable amount of effort to do effectively, but the end results are worth it: end users and administrators are happy.

Plan for Remediation

Exposing a weak link during load testing is not a failure, but a positive result. You should ensure your testing plan has time built in to address any weaknesses that are uncovered or that you may have time to test again. The amount of time that has to be added depends on the amount of load that broke the system. If load testing early on with fewer users exposed a lack of DHCP addresses this is a relatively easy fix to a DHCP scope. On the other hand, if testing at full predicted load uncovered a storage performance bottleneck, the time to procure additional storage, install and configure could be much longer.

Testing Scenarios

Your first fully automated test should be a single system test—a single test to ensure your test plan runs through to completion. With no resource contention and no over-commitment on the hosts, this is your baseline. This should also be correlated with an actual user single system test, ensuring the user experience is what is expected.

For the second test, ramp up to 50 percent of what the calculated capacity is. This gives enough wiggle room so you can determine if your design assumptions are accurate. Do you have enough IP addresses? Is storage able to keep up? How are the memory stats?

Run a third test at 100 percent calculated capacity. This is where getting real users into the system is critical. How long does it take to login? Are the test scenarios within the acceptable parameters? Is the user experience acceptable? Have you met all your design criteria and business requirements?

Finally, a fourth test at more than 100 percent expected capacity should be run. Add more desktops, start a full anti-virus scan, perform a software update. No matter how well we design, we always have to plan for the worst-case scenarios. The unexpected removal of a host from a cluster dramatically impacts capacity. Put a host in maintenance mode or reboot it without putting it in maintenance mode. How does your environment perform under these extreme conditions?

“We must contemplate some extremely unpleasant possibilities, just because we want to avoid them.”

– Albert Wohlstetter, American nuclear strategist, 1960

For more information, be sure to check out the following VMware Education Courses:


Hans Bader Consulting Architect, VMware EUC. Hans has over 20 years of IT experience and joined VMware in 2009. With a focus on helping organizations being operationally ready, he works with customers to avoid common mistakes. He is a strong advocate for proactive load testing of environment before allowing users access. Hans has won numerous consulting awards within VMware.

Managing VMware NSX Edge and Manager Certificates

Spas_KaloferovBy Spas Kaloferov

di·ver·si·ty

“Diversity” was the first word that came to my mind when I joined VMware. I noticed the wide variety of different methods and processes utilized to replace certificates on the different VMware appliance products. For example, with VMware vRealizeTM OrchestratorTM, users must undergo a manual process to replace the certificate, but with VMware vRealizeTM AutomationTM administrators have a graphical user interface (GUI) option, and with VMware NSX ManagerTM there is another completely different GUI option to request and change for the certificate of the product.

 

Figure 1. SSL Certificates tab on the VMware NSX ManagerTM 

SSL Certificates tab on the VMware NSX Manager

This variety of certificate replacement methods and techniques is understandable as all of these VMware products are a result of different acquisitions. Although these products are great in their own unique ways, the lack of a common, smooth and user-friendly certificate replacement methodology has always filled the administrators and consultants with anxiety.

This anxiety often leads to certificate configuration issues among the majority of VMware family members, partners and end users. As a member of this family—and also of the majority—I recently felt this anxiety when I had to replace my VMware NSX Manager and NSX EdgeTM certificates.

pas·sion

I must say that up to the point where I had to replace these certificates, I had pretty awesome experiences installing and configuring VMware NSX Manager, and even developed advanced services like network load balancing. But I hit a minor roadblock with the certificates, and my passion to kick down any road block until it turns to dust wasn’t going to leave me alone.

ex·e·cu·tion

I got in touch with some of my awesome colleagues and NSX experts to get me back on the good experience track of NSX. As expected, they did (not that I have ever doubted them). Now, I was exploring the advanced VMware NSX Manager capabilities with full power – like SSL VPN-Plus where I had to again configure a certificate for my perimeter gateway edge device.

Figure 2. Server Settings tab of the SSL VPN-Plus setting on the VMware NSX EdgeTM

Server Settings tab of the SSL VPN-Plus setting on the VMware NSX Edge

This time I wasn’t anxious because I now had the certificate replacement process under control.

cus·to·mer

As our customers are core to our mission, we want to empower them by freeing them from certificate replacement challenges so they can spend their time and energy on more pressing technological issues. To help empower other passionate enthusiasts, and help keep them on the good experience track of NSX, I’ve decided to describe the certificate replacement processes I’ve been using and share them in a blog post to make them available to everyone.

com·mu·ni·ty

We are all connected. We approach each other with open minds and humble hearts. We serve by dedicating our time, talent, and energy – creating a thriving community together. Please visit Managing NSX Edge and Manager Certificates to learn more about the certificate replacement process.


Spas Kaloferov is an acting Solutions Architect member of Professional Services Engineering (PSE) for the Software-Defined Datacenter (SDDC) – a part of the Global Technical & Professional Solutions (GTPS) team. Prior to VMware, Kaloferov focused on cloud computing solutions.

Using Super Metrics to Populate Widgets in VMware vRealize Operations Manager

Jeremy WheelerBy Jeremy Wheeler

When setting up dashboards in VMware vRealizeTM Operations ManagerTM, I’ve found a lot of customers are trying to locate specific metrics, such as how much memory is available to a cluster after honoring N+1 and 80 percent max memory utilization per host. These types of metrics can be located through a “super metric,” but in many cases you need to edit the XML file(s) correlated to the widget before you can present the super metric to the GUI widget.

In VMware’s previous version of VMware vCenterTM Operations ManagerTM, XML files were used heavily when a specific widget interaction was needed. With VMware vRealize Operations Manager, the process of injecting super metrics into an XML file has changed. This blog specifically talks about the steps needed to populate a widget with your super metric. View the document here: vRealize Operations Management Supermetrics and XML Editing.

For more information, be sure to check out the following VMware Education courses:

 

vRealize with Operations Management Supermetrics_Jeremy Wheeler


Jeremy Wheeler is an experienced senior consultant and architect for VMware’s Professional Services Organization, End-user Computing specializing in VMware Horizon Suite product-line and vRealize products such as vROps, and Log Insight Manager. Jeremy has over 18 years of experience in the IT industry. In addition to his past experience, Jeremy has a passion for technology and thrives on educating customers. Jeremy has 7 years of hands-¬‐on virtualization experience deploying full-life cycle solutions using VMware, CITRIX, and Hyper-V. Jeremy also has 16 years of experience in computer programming in various languages ranging from basic scripting to C, C++, PERL, .NET, SQL, and PowerShell.

Jeremy Wheeler has received acclaim from several clients for his in-¬‐depth and varied technical experience and exceptional hands-on customer satisfaction skills. In February 2013, Jeremy also received VMware’s Spotlight award for his outstanding persistence and dedication to customers and was nominated again in October of 2013

vSphere Datacenter Design – vCenter Architecture Changes in vSphere 6.0 – Part 2

jonathanm-profileBy Jonathan McDonald

In Part 1 the different deployment modes for vCenter and Enhanced Linked Mode were discussed. In part 2 we finish this discussion by addressing different platforms, high availability and recommended deployment configurations for vCenter.

Mixed Platforms

Prior to vSphere 6.0, there was no interoperability between vCenter for Windows and the vCenter Server Linux Appliance. After a platform was chosen, a full reinstall would be required to change to the other platform. The vCenter Appliance was also limited in features and functionality.

With vSphere 6.0, they are functionally the same, and all features are available in either deployment mode. With Enhanced Linked Mode both versions of vCenter are interchangeable. This allows you to mix vCenter for Windows and vCenter Server Appliance configurations.

The following is an example of a mixed platform environment:

JMcDonald pt 2 (1)

This mixed platform environment provides flexibility that has never been possible with the vCenter Platform.

As with any environment, the way it is configured is based on the size of the environment (including expected growth) and the need for high availability. These factors will generally dictate the best configuration for the Platform Services Controller (PSC).

High Availability

Providing high availability protection to the Platform Services Controller adds an additional level of overhead to the configuration. When using an embedded Platform Services Controller, protection is provided in the same way that vCenter is protected, as it is all a part of the same system.

Availability of vCenter is critical due to the number of solutions requiring continuous connectivity, as well as to ensure the environment can be managed at all times. Whether it is a standalone vCenter Server, or embedded with the Platform Services Controller, it should run in a highly available configuration to avoid extended periods of downtime.

Several methods can be used to provide higher availability for the vCenter Server system. The decision depends on whether maximum downtime can be tolerated, failover automation is required, and if budget is available for software components.

The following table lists methods available for protecting the vCenter Server system and the vCenter Server Appliance when running in embedded mode.

Redundancy Method Protects
vCenter Server system?
Protects
vCenter Server Appliance?
Automated protection using vSphere HA Yes Yes
Manual configuration and manual failover, for example, using a cold standby. Yes Yes
Automated protection using Microsoft Clustering Services (MSCS) Yes No

If high availability is required for an external Platform Services Controller, protection is provided by adding a secondary backup Platform Services Controller, and placing them both behind a load balancer.

The load balancer must support Multiple TCP Port Balancing, HTTPS Load Balancing, and Sticky Sessions.  VMware has currently tested several load balancers including F5 and Netscaler, however does not directly support these products. See the vendor documentation regarding configuration details for any load balancer used.

Here is an example of this configuration using a primary and a backup node.

JMcDonald pt 2 (2)

With vCenter 6.0, connectivity to the Platform Services Controller is stateful, and the load balancer is only used for its failover ability. So active-active connectivity is not recommended for both nodes at the same time, or you risk corruption of the data between nodes.

Note: Although it is possible to have more than one backup node, it is normally a waste of resources and adds a level of complexity to the configuration for little gain. Unless there is an expectation that more than a single node could fail at the same time, there is very little benefit to configuring a tertiary backup node.

Scalability Limitations

Prior to deciding the configuration for vCenter, the following are the scalability limitations for the different configurations. These can have an impact on the end design.

Scalability Maximum
Number of Platform Services Controllers per domain

8

Maximum PSCs per vSphere Site, behind a single load balancer

4

Maximum objects within a vSphere domain (Users, groups, solution users)

1,000,000

Maximum number of VMware solutions connected to a single PSC

4

Maximum number of VMware products/solutions per vSphere domain

10

Deployment Recommendations

Now that you understand the basic configuration details for vCenter and the Platform Services Controller, you can put it all together in an architecture design. The choice of a deployment architecture can be a complex task depending on the size of the environment.

The following are some recommendations for deployment. But please note that VMware recommends virtualizing all the vCenter components because you gain the benefits of vSphere features such as VMware HA. These recommendations are provided for virtualized systems; physical systems need to be protected appropriately.

  • For sites that will not use Enhanced Linked Mode, use an embedded Platform Services Controller.
    • This provides simplicity in the environment, including a single pane-of-glass view of all servers while at the same time reducing the administrative overhead of configuring the environment for availability.
    • High availability is provided by VMware HA. The failure domain is limited to a single vCenter Server, as there is no dependency on external component connectivity to the Platform Services Controller.
  • For sites that will use Enhanced Linked Mode use external Platform Service Controllers.
    • This configuration uses external Platform Services controllers and load balancers (recommended for high availability). The number of controllers depends on the size of the environment:
      • If there are two to four VMware solutions – You will only need a single Platform Services Controller if the configuration is not designed for high availability; two Platform Services Controllers will be required for high availability behind a single load balancer.
      • If there are four to eight VMware solutions – Two Platform Services Controllers must be linked together if the configuration is not designed for high availability; four will be required for a high-availability configuration behind two load balancers (two behind each load balancer).
      • If there are eight to ten VMware solutions – Three Platform Services Controllers should be linked together for a high-availability configuration; and six will be required for high availability configured behind three load balancers (two behind each load balancer).
    • High availability is provided by having multiple Platform Services Controllers and a load balancer to provide failure protection. In addition to this, all components are still protected by VMware HA. This will limit the failure implications of having a single Platform Services Controller, assuming they are running on different ESXi hosts.

With these deployment recommendations hopefully the process of choosing a design for vCenter and the Platform Services Controller will be dramatically simplified.

This concludes this blog series. I hope this information has been useful and that it demystifies the new vCenter architecture.

 


Jonathan McDonald is a Technical Solutions Architect for the Professional Services Engineering team. He currently specializes in developing architecture designs for core Virtualization, and Software-Defined Storage, as well as providing best practices for upgrading and health checks for vSphere environments.

vSphere Datacenter Design – vCenter Architecture Changes in vSphere 6.0 – Part 1

jonathanm-profileBy Jonathan McDonald

As a member of VMware Global Technology and Professional Services at VMware I get the privilege of being able to work with products prior to its release. This not only gets me familiar with new changes, but also allows me to question—and figure out—how the new product will change the architecture in a datacenter.

Recently, I have been working on exactly that with vCenter 6.0 because of all the upcoming changes in the new release. One of my favorite things about vSphere 6.0 is the simplification of vCenter and associated services. Previously, each individual major service (vCenter, Single Sign-On, Inventory Service, the vSphere Web Client, Auto Deploy, etc.) was installed individually. This added complexity and uncertainty in determining the best way to architect the environment.

With the release of vSphere 6.0, vCenter Server installation and configuration has been dramatically simplified. The installation of vCenter now consists of only two components that provide all services for the virtual datacenter:

  • Platform Services Controller – This provides infrastructure services for the datacenter. The Platform Services Controller contains these services:
    • vCenter Single Sign-On
    • License Service
    • Lookup Service
    • VMware Directory Service
    • VMware Certificate Authority
  • vCenter Services – The vCenter Server group of services provides the remainder of the vCenter Server functionality, which includes:
    • vCenter Server
    • vSphere Web Client
    • vCenter Inventory Service
    • vSphere Auto Deploy
    • vSphere ESXi Dump Collector
    • vSphere Syslog Collector (Microsoft Windows)/VMware Syslog Service (Appliance)

So, when deploying vSphere 6.0 you need to understand the implications of these changes to properly architect the environment, whether it is a fresh installation, or an upgrade. This is a dramatic change from previous releases, and one that is going to be a source of many discussions.

To help prevent confusion, my colleagues in VMware Global Support, VMware Engineering, and I have developed guidance on supported architectures and deployment modes. This two-part blog series will discuss how to properly architect and deploy vCenter 6.0.

vCenter Deployment Modes

There are two basic architectures that can be used when deploying vSphere 6.0:

  • vCenter Server with an Embedded Platform Services Controller – This mode installs all services on the same virtual machine or physical server as vCenter Server. The configuration looks like this:

JMcDonald 1

This is ideal for small environments, or if simplicity and reduced resource utilization are key factors for the environment.

  • vCenter Server with an External Platform Services Controller – This mode installs the platform services on a system that is separate from where vCenter services are installed. Installing the platform services is a prerequisite for installing vCenter. The configuration looks as follows:

JMcDonald 2

 

This is ideal for larger environments, where there are multiple vCenter servers, but you want a single pane-of-glass for the site.

Choosing your architecture is critical, because once the model is chosen, it is difficult to change, and configuration limits could inhibit the scalability of the environment.

Enhanced Linked Mode

As a result of these architectural changes, Platform Services Controllers can be linked together. This enables a single pane-of-glass view of any vCenter server that has been configured to use the Platform Services Controller domain. This feature is called Enhanced Linked Mode and is a replacement for Linked Mode, which was a construct that could only be used with vCenter for Windows. The recommended configuration when using Enhanced Linked Mode is to use an external platform services controller.

Note: Although using embedded Platform Services Controllers and enabling Enhanced Linked Mode can technically be done, it is not a recommended configuration. See List of Recommended topologies for vSphere 6.0 (2108548) for further details.

The following are some recommend options on how—and how not to—configure Enhanced Linked Mode.

  • Enhanced Linked Mode with an External Platform Services Controller with No High Availability (Recommended)

In this case the Platform Services Controller is configured on a separate virtual machine, and then the vCenter servers are joined to that domain, providing the Enhanced Linked Mode functionality. The configuration would look this way:

JMcDonald 3

 

There are benefits and drawbacks to this approach. The benefits include:

  • Fewer resources consumed by the combined services
  • More vCenter instances are allowed
  • Single pane-of-glass management of the environment

The drawbacks include:

  • Network connectivity loss between vCenter and the Platform Service Controller can cause outages of services
  • More Windows licenses are required (if on a Windows Server)
  • More virtual machines to manage
  • Outage on the Platform Services Controller will cause an outage for all vCenter servers connected to it. High availability is not included in this design.
  • Enhanced Linked Mode with an External Platform Services Controller with High Availability (Recommended)

In this case the Platform Services Controllers are configured on separate virtual machines and configured behind a load balancer; this provides high availability to the configuration. The vCenter servers are then joined to that domain using the shared Load Balancer IP address, which provides the Enhanced Linked Mode functionality, but is resilient to failures. This configuration looks like the following:

JMcDonald 4

There are benefits and drawbacks to this approach. The benefits include:

  • Fewer resources are consumed by the combined services
  • More vCenter instances are allowed
  • The Platform Services Controller configuration is highly available

The drawbacks include:

  • More Windows licenses are required (if on a Windows Server)
  • More virtual machines to manage
  • Enhanced Linked Mode with Embedded Platform Services Controllers (Not Recommended)

In this case vCenter is installed as an embedded configuration on the first server. Subsequent installations are configured in embedded mode, but joined to an existing Single Sign-On domain.

Linking embedded Platform Services Controllers is possible, but is not a recommended configuration. It is preferred to have an external configuration for the Platform Services Controller.

The configuration looks like this:

JMcDonald 5

 

  • Combination Deployments (Not Recommended)

In this case there is a combination of embedded and external Platform Services Controller architectures.

Linking an embedded Platform Services Controller and an external Platform Services Controller is possible, but again, this is not a recommended configuration. It is preferred to have an external configuration for the Platform Services Controller.

Here is as an example of one such scenario:

JMcDonald 6

  • Enhanced Linked Mode Using Only an Embedded Platform Services Controller (Not Recommended)

In this case there is an embedded Platform Services Controller with vCenter Server linked to an external standalone vCenter Server.

Linking a second vCenter Server to an existing embedded vCenter Server and Platform Services Controller is possible, but this is not a recommended configuration. It is preferred to have an external configuration for the Platform Services Controller.

Here is an example of this scenario:

JMcDonald 7

 

Stay tuned for Part 2 of this blog post where we will discuss the different platforms for vCenter, high availability and different deployment recommendations.


Jonathan McDonald is a Technical Solutions Architect for the Professional Services Engineering team. He currently specializes in developing architecture designs for core Virtualization, and Software-Defined Storage, as well as providing best practices for upgrading and health checks for vSphere environments.