The downside to the workgroup configuration is the multiuser account management now in place. Users accessing VirtualCenter will now use a completely different user account that is not susceptible to the domain password policies. </p> </cite> <p>VirtualCenter has a more structured hierarchy with greater depth than an ESX Server host. As outlined in the previous section, the only way to organize virtual machines on an individual ESX host is to build a resource pool, and then move the appropriate virtual machines into that resource pool. The VirtualCenter hierarchy opens opportunities to create folder structures for organizing objects like datacenters and virtual machines. </p> <p>In the VirtualCenter environment, start by creating, as a minimum, a datacenter. The datacenter object is the building block of a VirtualCenter hierarchy.</p> <p>Perform the following steps to create a datacenter object:</p> <p>1. Use the VI Client to connect to a VirtualCenter server.</p> <p>2. Right-click the Hosts & Clusters root node in the inventory and select the New Datacenter option, as shown in Figure 8.17.</p> <p>3. Type a name for the new datacenter object.</p> <p>So what exactly is a datacenter object used for? A datacenter is used to organize ESX Server hosts, resource pools, virtual machines, and templates based on a company's management style. It is the building block of the VirtualCenter inventory, much like organizational units are the foundation of an Active Directory structure. An ESX host cannot be added directly to the VirtualCenter. A datacenter must exist in order to add an ESX Server. VirtualCenter is designed as an enterprise management application for all of the ESX servers in your worldwide organization. So the question remains: How do you manage resources? Is your management strategy based on geography, departments, or projects? Or do you prefer an arbitrary management style? In any case, Virtual-Center supports your style. Datacenters can be named by location, department, project, or can be given generic names like Datacenter1, Datacenter2, and so forth.</p> <img src=#i_295.png" > <p> <strong>Figure 8.17</strong>The Datacenter object is the building block of the VirtualCenter inventory.</p> <empty-line > <p>Think about what would happen if you were to place every document in your computer at the root of your hard drive. Finding documents would be difficult to say the very least, and assigning permissions to objects would be similarly difficult. Thus would be the case if our virtual infrastructure objects (hosts, resource pools, virtual machines, templates) were all located in a flat structure under the root.</p> <p>Take, for example, an organization with offices in St. Petersburg, Florida, and Los Angeles, California, where each office will have several ESX hosts and dozens of virtual machines and template objects. The infrastructure might be constructed so that the hosts in Los Angeles are attached to a shared storage device in Los Angeles, and the St. Petersburg ESX Server hosts are attached to a second shared storage device local to their site. Keep in mind that these servers will be able to talk to each other via a WAN connection, but they can only access storage in their specific region. In addition, if the company has an IT staff in each location, then the administrators will create logical datacenter objects based on physical location.</p> <p>This example could just as easily have been detailed as a departmental-specific configuration in which the finance, marketing, and sales departments have their own respective ESX Server hosts. In this case, the logical datacenter objects would be labeled by department rather than physical location.</p> <p>This organization also does one more thing: a datacenter is a boundary for the configuration of VMotion, HA, and DRS. In other words, you can only migrate a virtual machine with VMotion to another host in the same datacenter where it is currently running, in the same way that HA can only fail over to another host in the same datacenter. The VMotion, HA, and DRS topics will be covered in more detail in Chapters 9 and 10.</p> <p>But what happens if there are 30 datacenters in your organization, some located in Europe, some in North America, some in South America — and all with different teams of administrators managing them? The simple answer is to create folders under the root object in VirtualCenter and then create (or move) your datacenter objects under those folders. Creating folders under the root and placing datacenter objects beneath them allows for broader access control management. Think about why you create folders on network drives: to organize files and other folders and to simplify the assignment of permissions to many objects. Designing a VirtualCenter inventory employs the same logic. Figure 8.18 details a VirtualCenter inventory where multiple datacenter objects exist beneath a folder structure that provides an additional layer of management and access control. In this case, the datacenters are managed by geography: East Coast or West Coast.</p> <img src=#i_296.png" > <p> <strong>Figure 8.18</strong>Folders created above the datacenter object offer flexibility in providing broader access control.</p> <empty-line > <p>In the same way you can use folders to organize datacenters, you can also create folders within the datacenter to organize virtual machines according to your needs. For more detailed micromanaging scenarios, folders within folders can be created. Figure 8.19 details an inventory structure where datacenters are organized by geography and servers are managed by the rack in which they exist.</p> <img src=#i_297.png" > <p> <strong>Figure 8.19</strong>Creating folders beneath a datacenter provides more granular access control and management strategies.</p> <empty-line > <p>As explained in the previous section, a special type of folder called a resource pool is used to organize virtual machines. The key difference between a regular folder and a resource pool is that a resource pool allows for the carving of CPU and memory resources to provide resource limitation to virtual machines within the pool. Resource pool functionality will be discussed with more detail in Chapter 9; for now, our focus is on the access control capabilities of the resource pool as an object in the inventory.</p> <p>VirtualCenter offers two main views of the objects within the inventory: Hosts & Clusters and Virtual Machines & Templates. Until now we have remained in the default view of Hosts & Clusters, but the Virtual Machines & Templates view is extremely valuable for organizing virtual machines with respect to the management and access control needs of the traditional Windows administrators. The alternate views available in VirtualCenter maintain their own respective structures to support management of the various objects. For example, changes to objects in the Hosts & Clusters view does not necessarily result in changes to the objects in the Virtual Machines & Templates view. Figure 8.20 shows details of a Virtual Machines & Templates view constructed to support access control implementation based on the types of virtual machines in the infrastructure. The inventory is made up of several custom folders called Finance VMs, Medical System VMs, Infrastructure VMs, and the default Discovered Virtual Machine, which catches any unassigned virtual machines. These folders, like those in the Hosts & Clusters view, provide a boundary for assigning permissions.</p> <img src=#i_298.png" > <p> <strong>Figure 8.20</strong>The Virtual Machines & Templates view maintains its own hierarchical structure to enhance access control possibilities.
Читать дальше
Конец ознакомительного отрывка
Купить книгу