Nội dung

VMware vCloud Director 1.5 Performance and Best Practices ® Performance Study TECHNICAL WHITE PAPER ™ VMware vCloud Director 1.5 Performance and Best Practices Table of Contents Introduction...................................................................................................................................................................................................................3 vCloud Director Architecture ................................................................................................................................................................................3 vCloud Organization ......................................................................................................................................................................................... 4 vCloud Virtual Datacenters ............................................................................................................................................................................ 4 Catalogs ...................................................................................................................................................................................................................5 Test Environment ........................................................................................................................................................................................................5 Hardware Configuration ...................................................................................................................................................................................5 Software Configuration ....................................................................................................................................................................................5 Oracle Database ..........................................................................................................................................................................................................5 Latency Overview for Frequent Operations.................................................................................................................................................. 6 Linked Clone .................................................................................................................................................................................................................8 Comparison between Full Clone and Linked Clone ............................................................................................................................ 9 Chain Length Limit ............................................................................................................................................................................................ 10 Scalability .............................................................................................................................................................................................................. 14 Linked Clones across Datastore and vCenter ...................................................................................................................................... 14 Shadow VM Copy ........................................................................................................................................................................................ 15 Datastore Accessibility.............................................................................................................................................................................. 16 I/O Workflows for Linked Clone ................................................................................................................................................................. 19 Eight Host Limit .................................................................................................................................................................................................. 21 Sizing for Number of Cell Instances ................................................................................................................................................................ 22 Configuration Limits ............................................................................................................................................................................................... 23 Conclusion .................................................................................................................................................................................................................. 25 References .................................................................................................................................................................................................................. 26 TECHNICAL WHITE PAPER /2 VMware vCloud Director 1.5 Performance and Best Practices Introduction VMware vCloud® Director™ 1.5 gives enterprise organizations the ability to build secure private clouds that dramatically increase datacenter efficiency and business agility. Coupled with VMware vSphere®, vCloud Director delivers cloud computing for existing datacenters by pooling virtual infrastructure resources and delivering them to users as catalog-based services. vCloud Director 1.5 helps you build agile infrastructure-as-a-service (IaaS) cloud environments that greatly accelerate the time-to-market for applications and responsiveness of IT organizations. vCloud Director 1.5 adds the following new features specific to accelerating application delivery in the cloud:  Fast Provisioning  vSphere 5.0 Support  vCloud Custom Guest Data  Microsoft SQL Server Support  Expanded vCloud API and SDK  Globalization  vCloud API Query Service  vShield Five Tuple Firewall Rules  vCloud Messages  Static Routing  Cisco Nexus 1000v Integration  IPSec Site-to-Site VPN This white paper addresses three areas regarding vCloud Director performance:  vCloud Director sizing guidelines and software requirements  Best practices in performance and tuning  Performance characterization for key vCloud Director operations vCloud Director Architecture Figure 1 shows the deployment architecture for vCloud Director. A customer accesses vCloud Director by using a Web browser or REST API. Multiple vCloud Director Server instances can be deployed with a shared database. In the vCloud Director 1.5 release, both Oracle and Microsoft SQL Server databases are supported. A vCloud Director Server instance connects to one or multiple VMware vCenter™ Servers. From now on, we use vCloud Director Server instance and cell interchangeably. TECHNICAL WHITE PAPER /3 VMware vCloud Director 1.5 Performance and Best Practices ESXi Hosts vCloud Director REST API vCloud Director Server instances vCenter vCenter ServervCloud Director Cells vCloud Director Web Interface Cloud Director Database vCenter Database Figure 1. VMware vCloud Director high level architecture Next we introduce the definitions for some key concepts in vCloud Director 1.5. These terms have been used 8 extensively in this white paper. For more information, refer to the vCloud API Programming Guide . vCloud Organization A vCloud organization is a unit of administration for a collection of users, groups, and computing resources. Users authenticate at the organization level, supplying credentials established by an organization administrator when the user was created or imported. vCloud Virtual Datacenters A vCloud virtual datacenter (vDC) is an allocation mechanism for resources such as networks, storage, CPU, and memory. In a vDC, computing resources are fully virtualized and can be allocated based on demand, service level requirements, or a combination of the two. There are two kinds of vDCs: • Provider vDCs A provider virtual datacenter (vDC) combines the compute and memory resources of a single vCenter Server resource pool with the storage resources of one or more datastores available to that resource pool. Multiple provider vDCs can be created for users in different geographic locations or business units, or for users with different performance requirements. • Organization vDCs An organization virtual datacenter (vDC) provides resources to an organization and is partitioned from a provider vDC. Organization vDCs provide an environment where virtual systems can be stored, deployed, and operated. They also provide storage for virtual media, such as floppy disks and CD-ROMs. A single organization can have multiple organization vDCs. An organization administrator specifies how resources from a provider vDC are distributed to the vDCs in an organization. TECHNICAL WHITE PAPER /4 VMware vCloud Director 1.5 Performance and Best Practices Catalogs Organizations use catalogs to store vApp templates and media files. The members of an organization that have access to a catalog can use the catalog's vApp templates and media files to create their own vApps. A system administrator can allow an organization to publish a catalog to make it available to other organizations. Organization administrators can then choose which catalog items to provide to their users. Catalogs contain references to virtual systems and media images. A catalog can be shared to make it visible to other members of an organization and can be published to make it visible to other organizations. A vCloud system administrator specifies which organizations can publish catalogs, and an organization administrator controls access to catalogs by organization members. Test Environment For the experiment results in this paper, we used the following test bed setup. Actual results may vary significantly and depend on many factors including hardware and software configuration. Hardware Configuration  vCloud Director Cell: 64-bit Red Hat Enterprise Linux 5, 4 vCPUs, 8GB RAM  vCloud Director Database: 64-bit Windows Server 2003, 4 vCPUs, 8GB RAM  vCenter: 64-bit Windows Server 2003, 4 vCPUs, 8GB RAM  vCenter Database: 64-bit Windows Server 2003, 4 vCPUs, 8GB RAM  All of these components are configured as virtual machines and are hosted on a Dell PowerEdge R610 box with 8 Intel Xeon CPUs@2.40GHz, and 16GB RAM. Software Configuration  vCenter: vCenter Server 5.0  vCenter Database: Oracle DB 11g  vSphere Host: vSphere ESXi 5.0  Storage: Dell EqualLogic model 70-0115 Oracle Database A database server configured with 16GB of memory, 100GB storage, and 4 CPUs should be adequate for most vCloud Director clusters. The database must be configured to allow at least 75 connections per vCloud Director cell plus about 50 for Oracle's own use. Table 1 shows how to obtain values for other configuration parameters based on the number of connections, where C represents the number of cells in your vCloud Director cluster. TECHNICAL WHITE PAPER /5 VMware vCloud Director 1.5 Performance and Best Practices ORACLE CONFIGURATION PARAMETER VALUE FOR C CELLS CONNECTIONS 75*C+50 PROCESSES = CONNECTIONS SESSIONS = CONNECTIONS*1.1+5 TRANSACTIONS = SESSIONS*1.1 OPEN_CURSORS = SESSIONS Table 1. Oracle Database Configuration Parameters 10 For more information on best database practices, refer to vCloud Director Installation and Configuration Guide . Latency Overview for Frequent Operations In this section, we present the latency overview for some typical vCloud Director Operations. Figure 2 shows latency results for the following operations, which are performed by a group of eight users simultaneously. Note that these latency numbers are only for reference. Actual latency could vary significantly with different deployment setups.  Clone vApp in workspace  Capture vApp as template from workspace to catalog  Instantiate vApp from template to workspace  Delete vApp in workspace  Delete vApp template in Catalog  Edit vApp  Create Users  Deploy vApp in workspace, with or without a fence  Undeploy vApp in workspace, with or without a fence Clone vApp, capture vApp, instantiate vApp all involves VM clone operations. Clone vApp occurs as a workspaceto-workspace copy inside of vCloud. Capture vApp includes a copy operation from workspace to catalogue. Instantiate vApp includes the copy from catalogue to workspace. The vApp and vApp template we tested include a single VM with the same size (400MB). Figure 2 shows that with a linked clone, performance improves for all these operations. (Note that in Figure 2, (F) means full clone and (L) means linked clone.) We also observed the instantiate is faster than clone and capture operations, either in the full clone or linked clone case. For more information on a performance comparison between a linked clone and a full clone, refer to ”Linked Clone.” Other operations, including delete vApp, delete vApp template, edit vApp, and create users take only a minimal amount of time. TECHNICAL WHITE PAPER /6 Latency(Time in Seconds) VMware vCloud Director 1.5 Performance and Best Practices 20 18 16 14 12 10 8 6 4 2 0 Figure 2. Latency overview for vCloud Director operations Next, we looked into vApp deployment performance. vApp can be deployed with or without a fence as Figure 3 shows. Figure 3. Deploy vApp with or without fence TECHNICAL WHITE PAPER /7 VMware vCloud Director 1.5 Performance and Best Practices Fence deploy and undeploy operations take extra time when compared to deploying and undeploying a vApp without a fence. This is because vCloud Director needs to perform extra configuration in order to deploy vApp with a fence. When a vApp is deployed without a fence, the vApp directly connects with the organization network. When a vApp is deployed with a fence, the connections between the vApp and the organization network traverse a vShield Edge virtual appliance, which provides protection for the vApp network and also enables extension of the organization network to run identical virtual machines in different vApps. By extending the organization network in this way, it is possible to run multiple identical vApps without conflict: the vShield Edge deployed on a per-vApp network basis isolates the overlapping Ethernet MAC and IP addresses. For more information on the vCloud Director network, including configuration details for various organization networks 12 and vApp networks, please refer to vCloud Director Administrator's Guide 1.5 and vCloud Director User's Guide 13 1.5 . Latency(Time in Seconds) 140 120 100 80 60 40 20 0 FenceDeploy FenceUndeploy Deploy Undeploy Figure 4. Fenced and unfenced deployment operations Linked Clone vCloud Director 1.5 provisions quickly using linked clones. Linked clones utilize the vSphere redo-log linked clone implementation to provide statistically fast VM provisioning within and across datastore and vCenter boundaries. Compared with full clone, linked clone improves agility in the cloud by reducing provisioning time, providing near-instant provisioning of virtual machines in a cloud environment. NOTE: Fast Provisioning is supported only for vSphere 5.0. Mixed clusters of ESX/ESXi 4.x and ESXi 5.0 with vCenter 5.0 is not supported. For the experiments in this section, the test bed is configured as described in “Test Environment.” Other configurations include:  Each test vApp has a single virtual machine.  The virtual machine operating system is Linux 5.0.  The test vCloud Director cell has one datacenter and two clusters.  Two ISCSI datastores are connected.  Each cluster has two vSphere hosts. TECHNICAL WHITE PAPER /8 VMware vCloud Director 1.5 Performance and Best Practices Comparison between Full Clone and Linked Clone Figure 5. Linked clone and full clone If provisioning a virtual machine using full clone, the entire virtual disk is replicated, then a new independent virtual machine is created. For linked clone, a delta disk will be created and a link with the base disk. Typically in the virtual machine in full clone, writes go to the VMDK and reads come from the same VMDK. In Figure 5, virtual machine A is a primary virtual machine in which reads and writes go to the same VMDK. When a linked clone virtual machine is provisioned, as shown by virtual machine A, a small 16MB VMDK is created. This VMDK is an empty delta disk that serves to capture disk writes for the newly created virtual machine. This takes very little time to create and consumes a very small amount of disk space. Writes to disk from virtual machine A then go to this delta disk, which grows to accommodate the writes. Disk read operations traverse up the linked clone chain until the desired block is found. We conducted an experiment to compare the clone operation latency between full clone and linked clone. The virtual machine had one chain hop after the clone operation. We measured the linked clone latency by copying a vApp with a single virtual machine from a catalog to My Cloud work space. The virtual machine had one virtual disk. The virtual disk sizes were different for each run. Figure 6 shows the results of this test. TECHNICAL WHITE PAPER /9 VMware vCloud Director 1.5 Performance and Best Practices Latency (Time in Seconds) Full Clone Linked Clone 700 600 500 400 300 200 100 0 0 5,000 10,000 15,000 20,000 25,000 30,000 35,000 40,000 vApp Disk Size in MB Figure 6. Linked clone and full clone latency in various disk sizes Figure 6 shows that the latency of a vApp full clone increases as the vApp disk size grows. Linked clone latency remains the same short time regardless of the vApp disk size. During our tests, we measured linked clone latency as between 7-9 seconds. Because a linked clone is a copy of a delta disk file with a consistent small size, the operation latency is not increased by the primary vApp disk size. NOTE: VMs with I/O-intensive workloads might not benefit from using linked clones. See “I/O Workflows for Linked Clone” for details. Chain Length Limit Every time a linked clone is created from a VM, a new delta disk is created on the primary, which increases the chain length by one. As more virtual machines are created, the linked clone chain increases in size and VM performance will begin to degrade. To ensure optimal linked clone performance, vCloud Director limits the chain length to 30. If the vApp is copied more than 29 times through a linked clone operation, the operation will change to a full clone. When this occurs, the clone response time increases as the underlying clone method is changed to a full clone. It is not possible to shorten the chain length by deleting the cloned VM because the delta file on the primary VM cannot be removed. Thus, the linked clone becomes a full clone after 29 linked clone copies, regardless of the deletions of the cloned vApp. TECHNICAL WHITE PAPER /10