Mastering VMware vSphere 6. Marshall Nick

Чтение книги онлайн.

      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.

      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 СКАЧАТЬ