Mastering VMware vSphere 6. Marshall Nick

You can create and run VMs without it. However, to use the advanced features of the vSphere product suite – features such as vSphere Update Manager, vMotion, vSphere DRS, vSphere HA, vSphere Distributed Switches, host profiles, and vSphere FT – vCenter Server must be licensed, installed, and configured accordingly.

      But what happens when the environment grows? What happens when there are ten ESXi hosts and five administrators? Now the administrative effort of maintaining all these local accounts on the ESXi hosts becomes a significant burden. If a new account is needed to manage the ESXi hosts, you must create the account on ten different hosts. If an account password needs to change, you must change it on ten different hosts. Then add into this equation other VMware components such as vRealize Automation or vRealize Orchestrator, with their own possible accounts and passwords.

      vCenter – well, more accurately the VMware Single Sign-On (SSO) service – addresses this problem. It is a prerequisite for installing vCenter Server – that is, vCenter Server cannot be installed without SSO being available first. I’ll explain briefly how SSO works and what other software it interacts with (both VMware and non-VMware).

      Prior to vSphere 5.1, when you logged onto vCenter your authentication request was forwarded to either the local security authority on vCenter Server’s OS or Active Directory. In vSphere 5.1, 5.5, and 6, with SSO the request can still end up going to Active Directory, but it can also go to a list of locally defined users within SSO itself or to another Security Assertion Markup Language (SAML) 2.0–based authority. Generally speaking, SSO is a more secure way of authenticating to VMware products. Notice I said products and not vSphere? That’s because SSO has hooks into other VMware products, not just vCenter. vRealize Orchestrator, vRealize Automation, and vCloud Networking and Security are just a few. Why is this important? It means that SSO can take a single user and provide them with access to everything they need through the virtual infrastructure with a single username and password, and it can do so securely.

The following list outlines the steps taken when a user logs on using the vSphere Web Client or any other VMware product that is integrated with SSO (see Figure 3.2):

      1. The vSphere Web Client presents a secure web page to log into.

      2. The username and password is issued to the SSO server (in the form of a SAML 2.0 token).

      3. The SSO server sends a request to the relevant authentication mechanism (local, AD, or another SAML 2.0–based authority)

      4. Once authentication succeeds, SSO passes a token to the vSphere Web Client.

      5. This token can now be used to authenticate directly with vCenter, or any other SSO integrated VMware products.

Figure 3.2 The steps taken to issue an authenticated session with the SSO component

      As you can see, the authentication procedure can sound more complicated than other traditional methods; however, the process is seamless to the end administrators who get access as they always have.

      Before I talk about some of the more visible components of vCenter, let’s discuss some of the unseen aspects inside the Platform Services Controller of vCenter.

      Authentication with the vSphere Desktop Client

      Generally speaking, logging onto an ESXi host using the vSphere Desktop Client requires an account created and stored locally on that host. Using the same vSphere Desktop Client to connect to vCenter Server requires an SSO user account. Keep in mind that SSO and ESXi hosts do not make any attempt to reconcile the user accounts in their respective account databases.

      Using the vSphere Desktop Client to connect directly to an ESXi host that is currently managed by vCenter Server can cause negative effects in vCenter Server. A successful logon to a managed host results in a pop-up box that warns you of this potential problem.

      Understanding the Platform Services Controller vSphere 6.0 introduces a new component called the Platform Services Controller (PSC). It is used to run common components for VMware products in a central or in distributed location(s). The PSC offers multiple services; let’s step through them so you can understand why the PSC is vital to your vSphere environment:

      • Single Sign-On

      • Licensing

      • Certificate Authority

      • Certificate Store

      • Service Registry

      As you read over the last paragraph and this list, you may notice that I mentioned “…for VMware products.” The PSC is not solely for vCenter, or vSphere for that matter. These services are located external to the vCenter Server as a common service across your entire VMware environment. As I mentioned in the previous section, Single Sign-On is a service that is offered via the PSC and can be shared to multiple vCenter instances or other VMware products.

      The Licensing Service holds all licensing information for the vSphere environment and potentially other products, too, when they ship with PSC support. It removes the dependency where vCenter must be available for licensing operations to occur. This is especially important when you’re installing multiple vCenter Servers in a geographically wide environment – older vCenter versions didn’t replicate licensing information between them unless they were in a linked mode group.

      The Certificate Authority and Store is the SSL certificate mint and wallet for your vSphere Environment. These services will allow you to create your own or store and assign third-party certificates for both vCenter and ESXi hosts. You’ll find more details on how this service is used in Chapter 8.

      The Service Registry works as the name suggests: it is a registration index of all VMware services available in this environment. This index will be particularly powerful when all VMware products also register their existence with the PSC, or more specifically the Service Registry. No longer will you need to provide the details of each component to every other component; the Service Registry will do this automatically on your behalf.

During the installation of the PSC, which I’ll detail later in this chapter, you are given options for the installation type. Depending on the availability requirements of your vCenter Server installation, you may wish to make the PSC available from multiple sites or highly available in a single cluster. When installing a PSC for the first time, the first instance will always be a single node. Installing additional PSCs then allows you to join nodes to suit your environment. They can be external to the vCenter Server or embedded, as you can see in Figure 3.3.

Figure 3.3 The Platform Services Controller can be installed as an embedded or external component of vCenter, just like a database.

      Using the vSphere Web Client for Administration

      With the release of vSphere 5.1, VMware started shipping two different clients to use with vCenter Server. The older, more traditional client is a .NET Windows-only application, whereas the newer is a server-side installation for administering vSphere from a web browser. The following browsers are certified and supported with the vSphere Web Client:

      • Microsoft Internet – Explorer 10 and 11 (Windows only)

      • Mozilla Firefox – the latest version, and the previous version

      • Google Chrome – the latest version, and the previous version

      Additionally, to use the vSphere Web Client, you must have Adobe Flash Player version 11.1 or later installed.

      Which Client Should You Use?

      Now that there are two possible client choices to manage your vCenter Server, you need to decide which client to use day to day. Any new features that are part of the vSphere 5.5 or 6.0 releases are not available from the vSphere Desktop Client, so that would indicate that the vSphere Web Client is the one to use. But what happens if your storage vendor has a vSphere Desktop Client plug-in that has not been updated to work