Читать книгу Mastering VMware vSphere 6 - Marshall Nick - Страница 23

As the size of a virtual infrastructure grows, managing the infrastructure from a central location becomes significantly more important. vCenter Server is an application that serves as a centralized management tool for ESXi hosts and their respective VMs. vCenter Server acts as a proxy that performs tasks on the individual ESXi hosts that have been added as members of a vCenter Server installation. As discussed in Chapter 1, “Introducing VMware vSphere 6,” VMware includes vCenter Server licensing in every kit and every edition of vSphere, underscoring the importance of vCenter Server. Although VMware does offer a few different editions of vCenter Server (vCenter Server Essentials, vCenter Server Foundation, and vCenter Server Standard), I’ll focus only on vCenter Server Standard in this book.

VMware has a number of other products, but vCenter is generally the central integration point tying them all together. Software such as vRealize Automation, Site Recovery Manager, and vRealize Operations Manager all depend on an instance of vCenter Server to integrate into the VMware environment. Not only this, but as you will see, much of the advanced functionality that vSphere offers comes only when vCenter Server is present. Specifically, vCenter Server offers core services in the following areas:

• Resource management for ESXi hosts and VMs

• Template management

• VM deployment

• VM management

• Scheduled tasks

• Statistics and logging

• Alarms and event management

• ESXi host management

Figure 3.1 outlines the core services available through vCenter Server.

Figure 3.1 vCenter Server provides a full spectrum of virtualization management functions.

vCenter Server can be installed in two ways. The traditional approach is an application installed on a Windows server; the other format is as a Linux-based virtual appliance. You’ll learn more about virtual appliances in Chapter 10, “Using Templates and vApps,” but for now, suffice it to say that the vCenter Server virtual appliance (which you may see referred to as VCVA or VCSA) offers an option to quickly and easily deploy a full installation of vCenter Server and Platform Services on SUSE Linux.

Because of the breadth of features included in vCenter Server, most of these core services are discussed in later chapters. For example, Chapter 9, “Creating and Managing Virtual Machines,” discusses VM deployment, VM management, and template management. Chapter 11, “Managing Resource Allocation,” and Chapter 12, “Balancing Resource Utilization,” deal with resource management for ESXi hosts and VMs. Chapter 13, “Monitoring VMware vSphere Performance,” discusses alarms. In this chapter, I’ll focus primarily on ESXi host management, but we’ll also discuss scheduled tasks, statistics and logging, and event management.

There are other key items about vCenter Server that you can’t really consider core services. Instead, these underlying features support core services. To help you more fully understand the value of vCenter Server in a vSphere deployment, let’s take a closer look at the following:

• Centralized user authentication

• Web Client server

• Extensible framework

Centralizing User Authentication Using vCenter Single Sign-On

Centralized user authentication is not listed as a core service of vCenter Server, but it is essential to how vCenter and many other VMware products operate. In Chapter 2, “Planning and Installing VMware ESXi,” we discussed a user’s authentication to an ESXi host under the context of a user account created and stored locally on that host. Generally speaking, without vCenter Server you would need a separate user account on each ESXi host for each administrator who needed access to the server. As the number of ESXi hosts and required administrators grows, the number of accounts to manage grows exponentially. There are workarounds for this overhead; one such workaround is integrating your ESXi hosts into Active Directory, a topic we’ll discuss in more detail in Chapter 8, “Securing VMware vSphere.” In this chapter, we’ll assume the use of local accounts, but be aware that using Active Directory integration with your ESXi hosts does change the picture somewhat. In general, though, the centralized user authentication vCenter Server offers is easier to manage than other available methods.

In a virtualized infrastructure with only one or two ESXi hosts, administrative effort is not a major concern. Administering one or two servers would not incur incredible effort on the part of the administrator, and creating user accounts for administrators would not be too much of a burden.

In situations like this, you may not miss vCenter Server from a management perspective, but you may certainly miss its feature set. In addition to its management capabilities, vCenter Server can perform vMotion, configure vSphere Distributed Resource Scheduler (DRS), establish vSphere High Availability (HA), and use vSphere Fault Tolerance (FT). These features are not accessible using ESXi hosts without vCenter Server. You also lose key functionality such as vSphere Distributed Switches, host profiles, policy-driven storage, and vSphere Update Manager. vCenter Server is a requirement for any enterprise-level virtualization project.

vcenter Server Requirement

Strictly speaking, vCenter Server is not a requirement for a vSphere hypervisor deployment. 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 with the vSphere Web Client? Well, in some cases you may not have a choice other than to use the older client, but over time the crossover period will fade away and only the vSphere Web Client will be used. Prior to vSphere 5.5, I would have stated that the vSphere Desktop Client was still the one to use, but now that vendors have had time to update and features are presented only through the vSphere Web Client, it’s my opinion that we’re on the other side of the curve.

As stated in Chapter 2, previously the vSphere Web Client was not as feature-rich as the traditional vSphere Desktop Client, but since the release of vSphere 5.5, this has changed. When vSphere 5.1 was released, VMware stated it would no longer add features to the vSphere Desktop Client. Since this time VMware have responded to customers wanting to still use the older client. The older Desktop Client for vSphere 5.5 Update 2 and vSphere 6 will allow basic manipulation of VM Hardware Versions 10 and 11, respectively.

As you read through the rest of this book, you can assume that unless I specify the vSphere Desktop Client, the vSphere Web Client is the default choice and the one you should be using.

Providing an Extensible Framework

Just as centralized authentication is not a core vCenter Server service, we don’t include vCenter Server’s extensible framework as a core service. Rather, this extensible framework provides the foundation for vCenter Server’s core services and enables third-party developers to create applications built around vCenter Server. Figure 3.4 shows some of the components that revolve around the core services of vCenter Server.

Figure 3.4 Other applications can extend vCenter Server’s core services to provide additional management functionality.

A key aspect for successful virtualization is the ability to allow third-party companies to provide products that add value, ease, and functionality to existing products. By building vCenter Server in an extensible fashion and providing an application programming interface (API) to it, VMware has shown its interest in allowing third-party software developers to play an integral part in virtualization. The vCenter Server API allows companies to develop custom applications that can take advantage of the virtual infrastructure created in vCenter Server. For example, numerous companies have created backup utilities that work off the exact inventory created inside vCenter Server to allow for advanced backup options of VMs. Storage vendors use the vCenter API to create plug-ins that expose storage details, and other third-party applications use the vCenter Server APIs to provide management, monitoring, life-cycle management, or automation functionality.

You can find more information on vCenter Server functionality in Chapter 10, which provides a detailed look at templates along with VM deployment and management, and in Chapter 8, which goes deeper into vCenter Server’s access controls. Chapter 11 discusses resource management, and Chapter 13 offers an in-depth look at ESXi host and VM monitoring as well as alarms.

You’re almost ready to take a closer look at installing, configuring, and managing vCenter Server. First, however, we’ll discuss how to choose which version of vCenter Server you should deploy in your environment.