Читать книгу VMware vSphere PowerCLI Reference - Graf Brian - Страница 9

In this chapter, you will learn to:

• Prepare the vCenter Installation

• Create an Automated Installation

• Set Up Your vCenter Server Folder Structure

• Creating a Folder Structure from Scratch

• Exporting a Folder Structure

• Importing a Folder Structure

• Define Users and Their Privileges

• Granting Privileges

• Creating New Roles

• Bringing In Users

• Exporting Permissions

• Importing Permissions

• Configure Datacenters and Clusters

• Creating Datacenters

• Creating Clusters

• Configuring High Availability

• Configuring Distributed Resource Scheduler

• Configuring Enhanced vMotion Compatibility

• Configuring Distributed Power Management

• Licensing

• Viewing License Information

• Licensing a Host

One of the focal points and key use cases of PowerCLI is the automation of tasks that are needed either as part of a disaster recovery (DR) solution or as part of an automated deployment solution that can be used repeatedly – you’ll be safe in the knowledge that scripts will produce consistent and easy-to-use solutions.

This chapter will take you through some common areas automated within vSphere, starting at the beginning of the virtual infrastructure. Not only will we show you how to automate the build, but we’ll also provide examples of export scripts that will help you export information into a centralized area. The exported data will then be ready for use in reports or for the import process of another setup.

Prepare the vCenter Installation

As part of the overall virtual infrastructure, one of the first products you will need to install is the vCenter Server, or Virtual Infrastructure Server. Although this cannot be done directly using PowerCLI cmdlets, you can use the automated nature of PowerCLI and PowerShell to automate the vCenter Server installation.

The key thing to remember while reading this chapter – and indeed the entire book – is that PowerShell reaches past the virtual infrastructure. It can be used to manage most areas of the Windows-based operating system and application set. PowerCLI is purely an addition to PowerShell that allows you to manage the virtual infrastructure.

To automate the installation of vCenter Server and its respective components, including the vSphere Client, Update Manager, Converter, and the corresponding databases, you will need the install media as well as various other items, such as the correct version of the .NET Framework and Windows installed on the server. The components you choose to install will depend on your infrastructure and the type of database you are going to use with your vCenter Server install.

Before you attempt to create an automated installation, be sure that:

• The server meets at least the minimum hardware requirements as specified in the VMware ESX and vCenter Server installation documents provided by VMware.

• The server is configured with a static IP address.

• The computer name consists of fewer than 15 characters. (To conform to best practice, ensure that the computer name matches the hostname in the fully qualified domain name [FQDN] of the system.)

• The system is joined to a domain, and not a workgroup. Although this is not a strict requirement, domain membership ensures that when you’re using advanced features like the vCenter Guided Consolidation Service, the vCenter Server will be able to find all domains and systems on the network for the purpose of converting physical systems to virtual machines (VMs).

• The service user account that will be used for installation is added to the Log On As A Service policy.

• A supported database is already available unless you plan on using the internal vPostgres database.

• A valid system data source name (DSN) exists that allows vCenter Server to connect to the created database.

• The vCenter Server is able to directly access the hosts it will manage without any network address translation between the server and the hosts.

No Magic Wands

Notice that all these requirements and recommendations are the same as those you’d check if you were manually installing vCenter Server on a single machine. People often think that scripting introduces some kind of magic or new ways to do things behind the scene. Not so! We use exactly the same methods VMware does for a manual install; it’s just automated. If things go wrong, troubleshoot them the same way you would for a standard vCenter Server install that went wrong.

Create an Automated Installation

When installing vCenter Server manually, you first download the media, and then run through a series of wizards, ensuring that each step within the wizard is correctly configured before completing the installation and waiting for the wizard to install vCenter Server. This process can become cumbersome if the installation needs to be repeated multiple times, and mistakes can be made that could cause key configured items to be incorrect.

Once you know what properties are required to perform an automated (also known as silent) install, you will be able to begin writing a script that can be reused as many times as desired. One key to creating a successful installation script that can be reused is to use variables for property values. This allows the user to use CSV files, additional scripts, and other methods to specify different values for each property in subsequent deployments without having to manually edit the installation script.

Generally, scripts have a few key items: property variables for repeatability, the location of the installation media, installer switches that specify how the installer will act, and a line that creates the installation string to be run.

The automated vCenter installation scripts vary slightly depending on the version of vCenter used (requirements and features can change between versions). The properties defined in Listing 1-1 are configured for use with vCenter Server 6. If you are using a previous version of vCenter Server for your install, the properties may be different. However, the method of invoking the vCenter installation remains the same.

In this example, we are installing vCenter Server 6 using a remote SQL Server 2014 database. vCenter Server 6 can also install using an internal vPostgres database. To ensure a successful installation, we specify values for all of the properties required for the type of installation we are performing.

NOTE A manual install offers multiple installation paths and options. When performing an automated install, use only the inputs necessary for the type of deploy you want to perform. There is no need to specify every single available property within the installer GUI.

As you can see in Listing 1-1, once values have been given to each of the variables for the required properties, it is only a matter of creating the argument string that will be passed to the installer. Using a script like this ensures each installation is configured correctly and no mistakes are made.

Before running the sample script in Listing 1-1, we ensured that all prerequisites and installation requirements were completed. Listing 1-1 shows how you might automate an installation of vCenter Server.

Listing 1-1: Sample script for an automated installation of vCenter Server

Not all vCenter Servers are installed on Windows machines. VMware has released a virtual appliance known as the vCenter Server Appliance (vCSA) that can be used in place of a Windows vCenter. This option is compelling to many users because it does not require a Microsoft Windows license, and with each new release it is continuing to increase the size of environment it can handle.

Previous versions of the vCSA could be deployed using the Deploy OVF Template button within the C# client. However, with vCSA 6 this option is no longer possible. Luckily, we still have a few other options for deploying it. Along with the installer files, vCSA 6 has a command-line tool packaged in the installation media. The command-line tool leverages the use of a JavaScript Object Notation (JSON) configuration file and the OVF Tool to deploy the virtual appliance. Listing 1-2 shows an example of how we can use PowerCLI to configure the JSON configuration file and deploy the vCenter Server appliance.

Leveraging features found in PowerShell version 3 and later, we are able to convert the vCSA configuration template JSON file and convert it into a PowerShell object that we can then manipulate for our deployment purposes. Once the JSON file is converted into a PowerShell object, we can easily go through each property of the object and set its value. Once we have finished setting all the properties necessary for deployment, we can convert the PowerShell object back into a JSON file and use it to deploy the vCenter Server appliance. Figure 1-1 shows what is returned during the import process.

Listing 1-2: Sample script for an automated installation of the vCenter Server appliance

Figure 1-1: Sample vCSA import progress

Additional components, such as the vCenter Client or Update Manager, can also be installed in an automated fashion. We can deploy Update Manager the same way we deployed the Windows vCenter Server (see Listing 1-3).

Listing 1-3: Sample script for a silent install of the vSphere Client

vSphere Update Manager (VUM) deployments can also be automated in a similar fashion as vCenter Server. Update Manager can leverage a local database, but to maintain consistency with how we deployed vCenter Server, we will be deploying to a remote SQL database. Listing 1-4 shows how you can automate the deployment of vSphere Update Manager 6.

Listing 1-4: Sample script for an automated installation of vSphere Update Manager

VMware supports more automated installation options and parameters, such as installing a linked mode vCenter Server, and maintains an online installation document here:

https://www.vmware.com/support/pubs/vsphere-esxi-vcenter-server-pubs.html

Set Up Your vCenter Server Folder Structure

Two types of folders are supported in vSphere. From within the Hosts and Clusters view, you are able to create folders at any point under the datacenter level. These are commonly known as yellow folders and can be used throughout the infrastructure to organize the clusters, hosts, and VMs in a logical view.

Blue folders can be seen in the VMs and Templates view. Use these folders to more accurately reflect the layout of your VMs from a logical point of view. For example, you can create folders based on departments (such as Finance, Legal, and Customer Services) or by function (Internet, Active Directory, File Servers, Print Servers, Databases), or any other view that makes sense to your organization. Blue folders could also be used to reflect a security function and used to group the VMs into folders that only certain people can access. Once you create the folder, you can use it to grant access to various vCenter Server permissions.

Creating a Folder Structure from Scratch

You can initially create your folder structure when you create your new VMs; create your templates and move them into the appropriate folder. Another way of creating the folder structure is to plan the layout in a comma-separated value (CSV) file. This type of plan can easily be created in an Excel document, as shown in Figure 1-2, and then exported to the CSV format needed to create the virtual folder structure.

Figure 1-2: Sample CSV layout

In the example CSV file we created, there are two columns. The first column, Name, is used to define the name of the folder that you wish to create. The second column, Path, is used to show the path to where this folder is to be created in vCenter Server. As seen in Figure 1-2, in the Path column all entries begin with vm\. This folder will not be created but is used by the underlying application programming interface (API). Once you have created the CSV file that contains the layout of your folder structure, a script can easily read your CSV file and create the structure using the code shown in Listing 1-5.

Listing 1-5: Using a CSV file to create a vCenter file structure

Exporting a Folder Structure

Both yellow and blue folder views can be exported to a CSV file. You will find this technique useful when you are rebuilding your vCenter Server from scratch or creating a DR replica of the current virtual infrastructure.

The script in Listing 1-6 can be used to export either a blue or a yellow folder structure to a CSV. It can also be used to export the location of the current VMs, ensuring a replicated location when you reimport the structure.

Listing 1-6: Exporting a vCenter structure to a CSV file

Importing a Folder Structure

You can import an existing blue or yellow folder structure into vCenter Server using the Import-Folders function previously shown in Listing 1-5. You can also choose if you would like your VMs moved back into their correct blue folders by using the Import-VMLocation function, as shown in Listing 1-7.

Listing 1-7: Importing VMs to their blue folders

Define Users and Their Privileges

The authorization to perform tasks in your virtual infrastructure is controlled by a role-based access control (RBAC) system. A vCenter Server administrator can specify in great detail which users or groups can perform which tasks on which objects. RBAC systems are defined using three key concepts:

Privilege A privilege is the ability to perform an action or read a property. Examples include powering on a VM or adding a folder.

Role A role is a collection of privileges. Roles provide a way to add all the individual privileges that are required to perform a number of tasks, such as administering a vSphere host.

Object An object is an item on which actions can be performed. vCenter Server objects are datacenters, folders, resource pools, clusters, hosts, and VMs.

Granting Privileges

Privileges are found in the vSphere Web Client. When using the Roles wizard, you are able to add new privileges. The privileges are listed in Figure 1-3.

Figure 1-3 : vCenter Server Privileges

How many privileges are there? Think of any action you have ever performed in the vCenter Client. Think about the actions you have not yet come across or used in your everyday job. Now add them up, and you will have some idea of how many privileges there are in vCenter Server. Luckily, we are able to use PowerCLI to come up with a scientific answer for this question. You can easily list all privileges available to assign to a user through vCenter Server using the Get-VIPrivilege cmdlet:

We purposely truncated the output listing due to the large number of privileges available. You can count the number of privileges available for assigning to your roles and users or groups by using the Measure-Object cmdlet:

You can also use the Get-VIPrivilege cmdlet to show only the privileges available to certain sets of objects like a host:

You can view which groups (collections of privileges) are available by using the Get-VIPrivilege cmdlet with the – PrivilegeGroup parameter, as shown here:

Creating New Roles

A number of default roles come preconfigured with the installation of vCenter Server (see Figure 1-4). By selecting a role in the vSphere Web Client, you can see the list of privileges given to that role (on the right side). Each privilege category may be expanded and collapsed to see all the privileges set for the current role.

Figure 1-4 : vCenter Server roles

You can see an overview of the predefined roles by using the Get-VIRole cmdlet, as shown here:

Now that you know that a role is a group of privileges and you’ve learned to use the Get-VIPrivilege and Get-VIRole cmdlets, we want to introduce you to New-VIRole. You can use the New-VIRole cmdlet with Get-VIPrivilege to define a new role. You can define your own group of privileges, which can later be assigned to your users. An example is shown in Listing 1-8; you can see the results in the vCenter Client, as shown in Figure 1-5.

Listing 1-8: Creating a new role

A new role can also be created at a granular level. First, choose the privileges you want to use:

Figure 1-5: New roles

And then add each of them into an array:

You can then use the array of privileges to apply your specific permissions to the new role:

Bringing In Users

Now that you have defined your roles, you can start using them. Until now, you have only been working with roles and privileges. Once you define what you want your user to be able to do, you need to add users and grant them access to the roles. You can then enable them to start using the features of the vSphere Web Client.

A role or privilege can be assigned to any of the objects within a vCenter Server. Each of the objects can be defined by different roles or privileges. Together, objects, roles, and privileges make up a permission set. Permission sets can be inherited; inheritance ensures that each object underneath a datacenter, cluster, resource pool, or folder gives the users the correct access privileges.

So it comes as no great surprise that, when adding a permission through PowerCLI, you must consider three areas:

Role The role that you will assign to the user

Principal The user or group to which you wish to assign permissions

Entity The object, folder, cluster, datacenter, or resource pool for which you would like to grant permissions to the user

In the code that follows, we grant a user (VSPHERE.local\User01) access to New Custom Role at the datacenter level:

After you’ve set up and tested individual permissions, you can export them to a readable, importable format. This eases multiple installations and the transfer of permissions to further vCenter Servers, and ensures consistency as well. We’ll show you how next.

Exporting Permissions

The script in Listing 1-9 exports all relevant information into a CSV file, which can later be used to import them back into the same or a different vCenter Server. Exporting the permissions can be a great way to satisfy a security audit or ensure the relevant departments or users have the correct permissions.

Listing 1-9: Exporting permissions

Importing Permissions

It is equally important to be able to import the permissions back into your vCenter Server. To do so, you can use the script in Listing 1-10. Understand that because of the way that permissions are created and stored in vCenter, you can only import back into the vCenter from which you exported the permissions.

Listing 1-10: Importing permissions

Configure Datacenters and Clusters

vCenter Server has a hierarchical management structure similar to that of Microsoft Active Directory. Three main containers can be added to vCenter Server:

• Datacenters

• Clusters

• Folders

Datacenters A datacenter is a logical container within vCenter Server used to store clusters, folders, and VMs; they are often named for the physical location where the hosts reside, such as “Boston” or “South West Datacenter.”

Clusters A cluster is defined as a group of like-configured computers that act in a fully redundant setup to ensure availability of applications and operating systems. A vCenter Server cluster is no different. Clusters are used in vCenter Server for three main functions: high availability, load balancing, and high-performance computing. A cluster is made up of two or more physical servers that provide resources for the hosts that are assigned to that cluster.

Folders A folder is a logical way to define how VMs or other vCenter Server objects are organized. Folders are often used to organize VMs into department owners or server functions.

Creating Datacenters

Datacenters are generally created as part of the initial setup process. The setup can be automated by using the following code, which will create a datacenter called Boston and store it in a variable. The Datacenter object held within the variable can then be referred to later in the code as you create clusters or folders:

Creating Clusters

Clusters are more complex than datacenters; there are many configurable items available for a new cluster. Consider the options the vSphere Web Client gives us: the normal cluster options as well as configuration options for VMware High Availability (HA), VMware Distributed Resource Scheduler (DRS), VMware Enhanced VMotion Compatibility (EVC), and VMware Distributed Power Management (DPM).

To create a new cluster in the Boston datacenter you created earlier, you can use the following code:

This code line gives you the basic settings. The sections that follow discuss the additional cluster settings available to you.

Configuring High Availability

When configured in a cluster, VMware HA gives you many advantages, including the following:

• Proactive monitoring of all vSphere hosts and VMs

• Automatic detection of vSphere host failure

• Rapid restart of VMs affected by host failure

• Optimal placement of VMs after server failure

Much like the configuration of a cluster through the vSphere Web Client, you can configure HA within a cluster either as part of the initial cluster setup or you can alter an existing cluster object. For example, to configure a new cluster named Production with HA enabled and an HA failover level of 1 physical host failure and the HA Restart Priority as Medium, you would use the code in Listing 1-11.

Listing 1-11: Enabling HA with a failover host level and restart priority on a new cluster

To complete this same action on an existing cluster, you first need to retrieve the cluster as an object and then push it down the pipeline into the Set-Cluster cmdlet, as shown in Listing 1-12.

Listing 1-12: Enabling HA with a failover host level and restart priority on an existing cluster

Configuring Distributed Resource Scheduler

VMware DRS is a configuration made at the cluster level of the vCenter Server environment that balances VM workloads with available host resources. With VMware DRS, you are able to define the rules for allocation of physical resources among the VMs. DRS can be configured for manual or automatic control. If the workload on one or more VMs drastically changes, DRS redistributes the VMs among the physical servers to ensure the resources are available where needed. Much like HA, DRS can be configured as part of the initial cluster setup or as an alteration to an existing cluster object. For example, to configure a new Production cluster with DRS enabled and a DRS automation level of FullyAutomated with DRSMode set to FullyAutomated, you would use the code in Listing 1-13.

Listing 1-13: Configuring DRS on a new cluster

To complete this same action on an existing cluster, you would again need to retrieve the cluster object and push the object through the pipe into the Set-Cluster cmdlet, as shown in Listing 1-14.

Listing 1-14: Configuring DRS on an existing cluster

Configuring Enhanced vMotion Compatibility

EVC allows you to add multiple hosts with different CPU architectures to your cluster. EVC will, for example, allow you to add older hosts with Intel processors to a cluster that includes hosts with newer Intel processors. It does this by setting a mask on the VMs and ensuring the instruction sets are the same for both sets of hosts. Unfortunately, at this point in time VMware does not include either a PowerCLI cmdlet or a method to enable this feature programmatically. Therefore, configuring EVC is outside the scope of this book.

Configuring Distributed Power Management

DPM provides cost savings by dynamically consolidating VMs onto fewer hosts during periods of low usage. Once the VMs are consolidated onto fewer hosts, the remaining hosts that are no longer hosting any VMs are powered off to save power. Once utilization starts to increase, the vSphere Server will power these hosts back on as needed.

While there are currently no options to enable DPM through the native cmdlets that are provided with PowerCLI, you can address the API and create your own function to enable DPM. For more information about using the SDK/API or Project Onyx, read Chapter 18, “The SDK.”

Listing 1-15 shows how you can enable DPM on a cluster.

Listing 1-15: Configuring DPM on a cluster

Licensing

Licensing is one of the first areas that will be critical to setting up a new host. Without a valid license, you can manage and use your host-to-host VMs for a maximum of 60 days.

You may be surprised to learn that there are no cmdlets to help with licensing ESX hosts or even viewing the current license details. However, the licensing information is available through the Get-View cmdlet, and you can manipulate the SDK to perform the actions necessary to both view license information and set the license key for your hosts. You can write functions to help you deal with these cmdlets and make them a little friendlier than the SDK code.

Viewing License Information

To make things easier, you can use the functions we’ll show you next to list all license keys registered on the vCenter Server and also to set a license key on a host. The Get-LicenseKey function in Listing 1-16 lists all existing license keys.

Listing 1-16: Retrieving license key information from vCenter Server

Each of the existing license keys will be returned in an output listing like this:

Licensing a Host

Once you have a list of the keys, you can use that information to license the ESX hosts attached to the vCenter Server. Listing 1-17 shows how you set the license key for a specific host. Once the license key is set, it will return the server and license key that were specified.

Listing 1-17: Adding a license key to a host