Implementing a Server Virtualization Project
•Download as PPT, PDF•
11 likes•5,883 views
![Agenda ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Implementing a Server Virtualization Project
Similar to Implementing a Server Virtualization Project (20)
More from Alan McSweeney
More from Alan McSweeney (20)
Recently uploaded
Recently uploaded (20)
Implementing a Server Virtualization Project
- 1. Introduction to Server Virtualisation and Planning and Implementing a Virtualisation Project Alan McSweeney
- 4. Server Questions to Ask
- 10. Data Centre Costs – Administration and Power
- 14. Projects Associated With Virtualisation
- 17. Server Virtualisation Implementation Process Analysis and Design Implement Virtualisation Platform Physical To Virtual Migration Virtual Server Backup And Replication Reporting and Performance Monitoring Policy-Based Virtual Service Life Cycle Management Stage 1 Stage 2 Stage 3 Stage 4 Stage 5 Stage 6
- 37. Two ESX Servers, VirtualCentre, Backup to Disk, Tape Backup, Virtualised DR Facility with Replication
- 38. Very Large Scale Implementation
- 39. Very Large Scale Implementation
- 48. Operations Acceptance Testing – ITIL Checklist
- 56. esxCharter
- 58. SCOM VMware Management Pack Integration
- 64. Stage 6 - Server Virtualisation Processes
Editor's Notes
- The purpose of this section of the DSS Introduction to Server Virtualisation course is to provide you with details on how to successfully select, design and implement a virtual infrastructure solution that both delivers business benefits and that works in the long-term. The objective is to give you practical information to enable you to initiate a virtualisation project.
- This section coves the following topics Solution Requirements – this lists the requirements of a virtual infrastructure solution Virtualisation Benefits and Applications – this summarises the potential applications and benefits of virtualisation. It will allow you to select one or more areas Why Implement Virtualisation – this lists some of the reasons why other organisations have implemented virtualisation Server Virtualisation Implementation Process – this details a suggested complete six stage process for implementing virtualisation Capacity Planning – this details the contents and outputs from a capacity planning and analysis exercise that will enable you to quantify the scope of a virtualisation project Financial and Cost Benefit Analysis – this describes some implementation configurations and lists their costs and financial benefits Architecture Design – this describes some implementation architectures and configurations Monitoring and Reporting – this details approaches to implementing reporting and monitoring of a virtual infrastructure Project Planning and Implementation – this contains a suggested approach to implementing virtualisation
- A virtual infrastructure is like any IT solution and it should be subject to the same analysis and implementation policies.
- DSS recommend a forma Server Virtualisation Implementation Process (SVIP) to successfully implement server virtualisation projects to deliver you maximum benefits. This is a 6-stage process that realises a complete operational server virtualisation infrastructure, starting from initial analysis and solution design through to virtual server life cycle management. Depending on your requirements some stages can be bypassed or performed in an accelerated manner. This structured approach to implementing server virtualisation will reduce project risk and increase the business benefits delivered. The six stages are: Stage 1 - Analysis and Design Stage 2 - Implement Virtualisation Platform Stage 3 - Physical to Virtual Migration Stage 4 - Virtual Machine Backup and Replication Stage 5 - Performance Monitoring Stage 6 - Policy-Based Virtual Service Life Cycle Management
- DSS recommend that the Analysis and Design stage consists of four steps: Inventory - Discover server hardware and software assets across the data centre. Gather detailed information for each server such as operating system, installed and running applications or services, patch levels, CPU, memory, network and disk resources. Workload Data Collection - Identify workloads and collect utilisation data over days, weeks or months. Gather key data points to determine workload sizes and appropriate resource matching. Once completed, create dynamic reports to identify workload candidate workloads for consolidation and virtualisation. Export the data or copy highly visual graphs to business presentations. Analyse - Perform scenario modelling and planning for server consolidation. Create scenarios for distributing workloads across servers to maximise utilization, and balance application workloads over time and across hardware resources to minimise resource contention. Use “what-if” modelling to determine different combinations of hardware and virtual hosts required for the project. Generate a consolidation plan with detailed project, scenario, and workload assignment reports and charts. Compare different scenarios based on total cost of ownership, consolidation ratio, rack space and power needs. Design and Specify - Generate a consolidated implementation plan with detailed project, scenario, and workload assignment reports and charts. Compare different scenarios based on total cost of ownership, consolidation ratio, rack space and power needs. Accelerate the server consolidation project by producing a detailed set of recommendations and associated implementation plans. Specify the final virtualisation solution and the implementation roadmap.
- There are two capacity planning options: VMware Capacity Planner – this is a hosted and chargeable service provided by VMware. A designated PC that has access to the servers being analysed retrieves information from the servers using the WMI (Windows Management Instrumentation) API interface. Data is retrieved every 15 minutes to 1 hour. The server overhead is very low and the collection is non-intrusive with no software being installed on the servers being analysed. The information is collected on the PC and sent to a facility hosted by VMware where is it analysed. PlateSpin PowerRecon – this is a product from PlateSpin that provides a local data collection and reporting client. PowerRecon is very functional tool but it has cost The advantages of the VMware Capacity Planner tool are: Low hardware requirements with just a single gateway PC required for the interval Low cost The disadvantages of the VMware Capacity Planner tool are: Limited reporting Performance data goes offsite Performance and analysis data is not retained – just the output – so the audit trail is limited The advantages of PlateSpin PowerRecon tool are: It is a very functional product with extensive analysis and reporting capabilities Performance and analysis data is retained in a database for future analysis and for audit purposes The disadvantages of PlateSpin PowerRecon tool are: The product has a relatively high cost The product requires a separate analysis server if data is being retained
- A capacity planning exercise provides answers to key questions such as: What servers do I have and what are their performance characteristics? What is my server utilisation – processor, memory? What is the estimate of my consolidation opportunity? What will the configuration be of the target server virtualisation platform? What are the server virtualisation options? What servers are not recommended for virtualisation? What servers are obsolete? Capacity Planning service provides information to help answer the above questions by enabling you to: Identify every server in your domain(s) Collect detailed server and desktop inventory data, and server performance metrics without installing any agents on the targeted machines Collects and analyses the utilisation of CPU, memory, disk, network, and applications across you entire server base and then presents the findings in clear, easy-to-understand reports and charts Correlate the aggregated data from all your servers to create server load profiles to know when a server is busiest Understand consolidation optimisation recommendations Run what-if consolidation scenarios The outputs from the Capacity Planning exercise will be some or all of: Capacity utilisation metrics and trends Benchmarking and asset-ranking critical condition reports Expandability and balance metrics Ongoing analysis and correlation of utilization and performance statistics Server virtualisation and consolidation and optimisation recommendations "What if" query ability of your data and environment This will enable you to prepare a business case for server virtualisation safe in the knowledge that the information it contains is accurate and detailed. It will equip you with all the facts you need to understand if server virtualisation will deliver you bottom-line business benefits.
- This shows a list of servers from an analysis that may be excluded from the initial consolidation scenarios listed there were deemed not to be good candidates for consolidation due to high levels of paging or disk I/O. Consolidating these servers onto a smaller number of physical servers may cause problems. Of these dub-2k-012 had 50,000.56 I/Os per second. The reason for this high level of I/O should be examined. The volume of data transferred is 67.84 MB/sec. The other servers had high paging rates. In reality, these paging rates may be artificial and are caused by tasks such as disk indexing that are performing I/O using the Windows paging subsystem. This will need to be examined further.
- This a typical server utilisation profile. Most of your servers will have very low levels of resource utilisation. 98 servers have CPU utilisation of less than 10% during business hours. 77 servers have CPU utilization of less than 10% during peak hours. 1 server has utilisation between 10 and 20% during business hours. 13 servers has utilisation between 10 and 20% during peak hours. 1 server has utilisation between 20 and 30% during business hours. 5 servers have utilisation between 20 and 30% during peak hours. 1 server has utilisation between 30 and 40% during business hours. 6 servers have utilisation between 30 and 40% during peak hours. 1 server has utilisation between 40 and 50% during business hours. 1 server has utilisation between 70 and 80% during business hours:
- This can be used to identify multiprocessor servers and report on whether those processes are being utilised fully or if the load balance is uneven. Most new servers are at least dual processor and dual or quad core. Because of application design you will not be able to use these at anything like their full potential.
- An anomaly occurs when a metric exceeds three standard deviations from the mean in either direction. An anomaly could be good, bad or meaningless. If you are experiencing a problem with a server, check the detail in order to diagnose what the issue is. The detail should also be checked before making a decision on P2V migration. An alert occurs when a metric exceeds five standard deviations from the mean in either direction. The VMware Capacity Planner tracks and maintains current software vendor benchmarks for servers in its Information Warehouse and produces the anomalies and alerts showing the servers with performance data that deviates from these vendor values. Metrics are maintained in areas such as: System () Processor Queue Length Processor (_total) % Processor Time Memory () Pages/sec Memory () Cache Bytes Peak System () Context Switches/sec Paging File (_total) % Usage Peak Paging File (_total) % Usage
- This presents the results of a consolidation and virtualisation scenario where the existing physical servers are being moved onto a platform based on a target virtualisation platform. Multiple consolidation scenarios can be created based on various server models and characteristics. In this case, it is a server with four dual-core processors and 24 GB of RAM. The maximum load threshold defines the maximum loading thresholds allowed on each server within the new consolidated and virtualised infrastructure. In this case, each server is allowed to run at 75% processor utilisation. This will ensure that there are sufficient processing resources available in the event of a hardware failure on a server within the virtual cluster.
- This identifies the servers to be virtualised onto the target platforms. The specific servers to be virtualised onto each of the target servers is identified. The resource utilisation of the target servers is identified. This will assist in P2V planning. Server 1 dub-2k-033 dub-2k-049 dub-2k-051 dub-2k3-039 dub-2k3-042 dub-2k3-044 dub-2k3-047 dub-2k3-dc2 dub-2k3-dc3 Server 2 dub-2k-009r2 dub-2k-021 dub-2k-023 dub-2k3-031 dub-2k3-034 dub-2k3-036 dub-2k3-037 dub-2k3-041 DUB-NT-019 nt10
- The shows a simple configuration for illustrative purposes where there are VMs on two sets of servers in a HA cluster. The VMs have Reservation (lower resource limits) and Limits (higher resource limits) values explicitly. The actual level of usage of the VMs is between these two values. When one of blades fails the failing servers will be restarted on the remaining blades in the HA cluster with the result that the allocated resources to the VMs will be reduced dynamically to a lower value closer to their reservation threshold in order to accommodate the new VMs. This contains a suggested approach for setting resource allocation values in order to configure effective automatic recovery in a HA cluster. The following terms are used to define resource requirements: NS Number of servers in one half of a symmetrical HA cluster defined across both HP sites NPPS Number of processors per server PP Processing power of processor HSH High share resource allocation relative ratio number MSH Medium share resource allocation relative ratio number LSH Low share resource allocation relative ratio number NHVM Number of VMs with a share value set to High for which automatic disaster recovery is to be allowed NMVM Number of VMs with a share value set to Medium for which automatic disaster recovery is to be allowed NLVM Number of VMs with a share value set to Low for which automatic disaster recovery is to be allowed RF Reservation Factor – this is a ceiling for the total of the Reservation values for all virtual machines for which recovery is to be automated. Reservation Factor should be set to less than .5 in order to allow for processing resources for the virtualisation hypervisor. TPMR Total physical machine processing resource capacity RVU Reservation value unit – this is a notional amount of resources that when multiplied by RV Reservation value set for a virtual machine RVH This is the suggested reservation value to be set for a virtual server with a High share resource RVM This is the suggested reservation value to be set for a virtual server with a Medium share resource RVL This is the suggested reservation value to be set for a virtual server with a Low share resource TR This is the total of all the reservation values for virtual machines in one side of a symmetrical
- The following is one way of determining how the Reservation values should be set. (1) TPMR = NS x NPPS x PP (2) RVU = TPMR x RF / (NHVM x HSH + NMVM x MSH + NLVM x LSH) (3) RVH = RVU x HSH (4) RVM = RVU x MSH (5) RVL = RVU x LSH (6) TR = RVU x (NHVM x HSH + NMVM x MSH + NLVM x LSH) Number of servers in one half of a symmetrical HA cluster defined across both locations 8 Number of processors per server 2 Processing power of processor 3.2 High share resource allocation relative ratio number 2 Medium share resource allocation relative ratio number 1.5 Low share resource allocation relative ratio number 1 Number of VMs with a share value set to High for which automatic disaster recovery is to be allowed 20 Number of VMs with a share value set to Medium for which automatic disaster recovery is to be allowed 20 Number of VMs with a share value set to Low for which automatic disaster recovery is to be allowed 20 Reservation Factor – this is a ceiling for the total of the Reservation values for all virtual machines for which recovery is to be automated. Reservation Factor should be set to less than .5 in order to allow for processing resources for the virtualisation hypervisor. .45 (1) TPMR = 8 x 2 x 5.2 = 51.2 (2) RVU = 51.2 x .45 / (20 x 2 + 20 x 1.5 + 20 x 1) = 0.256 (3) RVH = 0.256 x 2 = 0.512 (4) RVM = 0.256 x 1.52 = 0.384 (5) RVH = 0.256 x 1 = 0.256 (6) TR = 0.256 x (20 x 2 + 20 x 1.5 + 20 x 1) = 23.04
- Implement the selected infrastructure that will be the platform for server virtualisation. Depending on the requirements, the platform can consist of a number of options. VMware HA enables quick restart of virtual machines on a different physical server within a cluster automatically if the physical hosting server fails. All applications within the virtual machines can enjoy the benefit of high availability. HA monitors all physical hosts in a cluster and detects host failures. An agent placed on each physical host maintains a heartbeat with the other hosts in the resource pool, and loss of a heartbeat initiates the process of restarting all affected virtual machines on other hosts. HA ensures that sufficient resources are available in the physical server cluster at all times to restart virtual machines on different physical hosts in the event of a host failure. VMware DRS aids in resource control and management capability in the virtual data centre. A cluster can be viewed as an aggregation of the computing and memory resources of the underlying physical hosts put together in a single pool. Virtual machines can be assigned to that pool. DRS monitors the workload of the running virtual machines and the resource utilisation of the hosts to assign resources. Using VMotion and an intelligent resource scheduler, VMware DRS automates the task of assigning virtual machines to servers within the cluster to use the computing and memory resources of that server as shown in DRS does the calculation and automates the pairing. If a new physical server is made available, DRS automatically redistributes the virtual machines using VMotion to balance the workloads. If a physical server must be taken down for any reason, DRS automatically reassigns its virtual machines to other servers.
- VMware ESX Server. A robust, production-proven virtualisation layer run on physical servers that abstracts processor, memory, storage, and networking resources into multiple virtual machines. VirtualCentre Management Server (VirtualCentre Server). The central point for configuring, provisioning, and managing virtualised IT environments. Virtual Infrastructure Client (VI Client). An interface that allows users to connect remotely to the VirtualCentre Server or individual ESX Servers from any Windows PC. VMware Virtual Machine File System (VMFS ). This is a high-performance cluster file system for ESX Server virtual machines. VMware Virtual Symmetric Multi-Processing (SMP). Feature that enables a single virtual machine to use multiple physical processors simultaneously. VMware VMotion. Feature that enables the live migration of running virtual machines from one physical server to another with zero down time, continuous service availability, and complete transaction integrity. VMotion is a technology used by the VMware DRS components VMware HA. Feature that provides easy-to-use, cost-effective high availability for applications running in virtual machines. In the event of server failure, affected virtual machines are automatically restarted on other production servers that have spare capacity. VMware Distributed Resource Scheduler (DRS). Feature that allocates and balances computing capacity dynamically across collections of hardware resources for virtual machines. VMware Consolidated Backup. Provides an easy to use, centralised facility for agent-free backup of virtual machines. It simplifies backup administration and reduces the load on ESX Server installations.
- This lists sample costs for various VMware configurations. VMware is priced per pair of processors on which the software runs. VirtualCentre is sold separately. Only one VirtualCentre instance is needed for a virtual infrastructure, subject to architectural limits.
- The elements of this option are: The primary server virtualisation infrastructure consists of two servers There is a separate server to run VirtualCentre to monitor, administer and control the virtual server environment. Data will be stored on a high-capacity, highly-resilient and reliable SAN. Server data will be initially backed-up onto a high-capacity, low-cost disk storage unit. Server data will then be backed-up to a LTO3 tape autoloader unit. This will reduce the manual effort associated with tape handling. The VirtualCentre server will provide centralised management, administration and control of the virtual server infrastructure. In the event of failure of one of the physical servers in the primary site, the HA component of VMware will allow the virtual servers on the failing physical server to be recovered onto the other physical server automatically.
- Data will be backed-up from the primary SAN to a low-cost, high-capacity disk storage unit. This will enable rapid backup with minimal impact on production systems during the backup process. Data will then be backed-up to an LTO3 tape autoloader. This will reduce the manual effort associated with tape handling during backup.
- Data will be backed-up from the primary SAN to a low-cost, high-capacity disk storage unit. This will enable rapid backup with minimal impact on production systems during the backup process. Data will then be backed-up to an LTO3 tape autoloader. This will reduce the manual effort associated with tape handling during backup. The backup data on the primary disk backup unit will be copied to a storage unit in the backup site to provide a copy from which data can be restored in the event of failure of the primary site. Backup tapes can be moved from the primary site to the backup site.
- There are a number of architectural limits that affect large scale implementation: Number of virtual machines (for management server scalability) 1500 Number of physical hosts per DRS cluster 32 Number of physical hosts per HA cluster 16 Number of physical hosts per VirtualCentre server 100 Ultimately this will require two or more entirely separate Virtual Infrastructures each of which will be managed by entirely separate VirtualCentre systems. In this configuration, each Virtual Infrastructure has three blade enclosures of 16 blade servers each in each data centre. This means each Virtual Infrastructure has 96 physical hosts – 48 in each data centre for symmetry. This will impose additional hardware requirements for VirtualCentre systems and VirtualCentre database servers. In reality the number of physical hosts per Virtual Infrastructure may be lower because of the number of virtual machines running on the physical servers. 96 physical hosts should be able to run a minimum of 750 virtual servers which is considerably less than the threshold of 1,500. This minimum of 750 is based on an average of around four virtual machines per blade processor.
- Multiple Clusters are defined up to the current maximum of 16 physical servers per HA cluster. VMware clusters are defined symmetrically across both sites. So, for a cluster of 16 physical servers, eight are located in each site. The VMware Cluster is designed to maximise recoverability while meeting agreed any SLA terms for resilience and high availability, maximising resource utilisation and long-term flexibility and minimising physical resource requirement. There is no ideal design that optimises all the factors. Some compromise is required. The easiest VMware Cluster design consists of two sets of identical resources across both data centres.
- Like any IT project, the investment in implementing server virtualisation should be justified to ensure that it delivers real benefits. A cost benefit analysis is important to l enable you to prepare a business case for server virtualisation safe in the knowledge that the information it contains is accurate and detailed. It will equip you with all the facts you need to understand if server virtualisation will deliver you bottom-line business benefits.
- There are two principal Physical to Virtual Server conversion tools available to HP: PlateSpin PowerConvert – this is a very functional tool but it has a relatively high cost. VMware Converter Enterprise – this is a new product from VMware It is available at no additional cost to existing and new VirtualCentre Management Server customers customers who have valid support and subscription contracts. DS are recommending that VMware Converter be used initially. It has no cost and provides sufficient functionality to meet the initial needs of HP. PlateSpin PowerConvert offers more functionality but this is not needed for HP virtualisation projects initially. However, there are a number of circumstances where VMware Converter will not work successfully and where PlateSpin PowerConvert will be required: The physical machines must have at least 364MB of RAM to use a boot CD required by VMware Converter. In practice we have found that only a server with at least 296MB of RAM will boot the CD without throwing up errors. Power Converter provides the facility to select the NIC speed at the time of conversion. VMware Converter does not allow the NIC speed to be selected therefore has to accept the default offered by the switch. We have found in testing that this effectively doubles the time taken to perform a migration using VMware Converter. PlateSpin PowerConvert is priced based on a per server price, depending on the number of servers being converted: Description Cost PowerConvert Project - Per Use for 1-99 conversions € 171.09 PowerConvert Project - Per Use for 100-499 conversions € 154.30 PowerConvert Project - Per Use for 500-999 conversions € 145.31 PowerConvert Project - Per Use for 1000+ conversions € 136.72 For example, the costs for converting the following numbers of servers are: Number of Servers Being Converted Cost Per Server Server Price Band Total Cost 50 €171.09 1-99 €8,554.69 100 €154.30 100-499 €15,429.69 150 €154.30 100-499 €23,144.53 200 €154.30 100-499 €30,859.38 250 €154.30 100-499 €38,574.22 500 €145.31 500-999 €72,656.25 600 €145.31 500-999 €87,187.50 While these costs may seem substantial, the cost per server is quite modest. The effort saved by using PowerConvert could justify these costs.
- In order to ensure that any virtual machine can be recovered safely and quickly, it is important that image-level backups be captured periodically. DSS recommends that users consider using VMware Consolidated Backup in conjunction with Vizioncore esxRanger Professional and their existing for this purpose – see http://www.vizioncore.com/esxRanger.html for more details on Vizioncore esxRanger. VMware Consolidated Backup provides a set of drivers and scripts that enables LAN-free backup of virtual machines running any supported operating system from a centralised Windows 2003 proxy server using an industry standard backup agent. A backup job is created for each virtual machine and that job is dispatched on a Consolidated Backup proxy. A pre-backup script takes a virtual machine snapshot and mounts the snapshot to the proxy server directly from the SAN. For virtual machines running Microsoft Windows operating systems, the pre-backup script also quiesces NTFS inside the virtual machine. The backup client then backs up the contents of the virtual machine as a virtual disk image. Finally, a post-backup script tears down the mount and takes the virtual disk out of snapshot mode. esxRanger Professional is a Windows-based software tool that allows you to perform automated backups of virtual machines running in the ESX Server environment and to restore backed up VMs in the event of a disk failure or if you want to revert to a previous version of a particular VM. esxRanger Professional performs these backups while the virtual machine is running, requiring no downtime. esxRanger Professional can be run in batch mode allowing jobs to be created which perform VMware Consolidated Backup-assisted backups which are then stored in Vizioncore’s proprietary compressed format on disk. From here they can be transferred to tape using HP Data Protector for offsite storage and archival purposes. A typical backup job would operate as follows: A backup job is created that specifies an esxRanger Professional batch job as a pre-backup script. This batch job performs a LAN-free backup of a virtual machine using VMware Consolidated Backup routines. The resulting image is stored as a compressed image file on the VCB proxy. From here, Data Protector transfers the image to tape. A typical restore job would operate as follows: If not still on disk, the backup tool restores the required image file from tape to local disk on the VCB Proxy. The esxRanger Professional GUI is then used to restore the virtual machine to the VMware ESX server via a LAN connection.
- Protection of virtual machines will require a solution based on three separate technologies that will be integrated to provide a simple backup and restore strategy. The three key elements are: VMware Consolidated Backup esxRanger Professional with VCB Plugin Backup software VMware Consolidated Backup works by attaching the Windows 2003 proxy server to the SAN and presenting to it the VMFS volumes containing the virtual machine files that you wish to protect. Virtual machines are then backed up across the SAN connection at high speed to a volume attached to the proxy server. VMware Consolidated Backup achieves this by utilising VMware ESX snapshot technology to create a consistent image-level backup of the virtual machine. esxRanger Professional is a Windows-based software tool that allows you to perform automated backups of virtual machines running in the VMware ESX server environment and to restore backed up VMs in the event of disk failure, disaster recovery or to revert to a previous version. esxRanger Professional is integrated with VMware VirtualCentre allowing backup jobs to be created by referring to VMs as they appear in the VirtualCentre inventory. VMware Consolidated Backup integration allows esxRanger to backup virtual machines at SAN speeds. Restores of Virtual Machines can be performed using the esxRanger interface, allowing restore images to be selected from a catalogue. VMs can be restored to their original locations or to an alternative location in the event of disaster recovery. Having configured a backup job with esxRanger, the job can be saved as a command line script by right clicking at the bottom of the job configuration window. This script can then be used as a pre-backup script for another backup product.
- DSS recommends that VMware Server Monitoring, Reporting and Capacity Management processes are implemented. Real-time and historical monitoring and performance control solution for the virtual server environment is important. As the Virtual Environment Grows requirements for managing the capacity of the environment will increase. With a virtual infrastructure, the user can upgrade the underlying virtual infrastructure independently of the underlying virtual servers. Hardware upgrades can take placed in a planned and controlled manner without affecting the operation of the virtual servers. VMware will scale out. Processing capacity can be automatically redistributed when additional resources are made available. In order to achieve this, a proper reporting process is required. Monitoring the system resources in and VM performance information will give a trending information on how much the utilisation of the Virtual environment has grown. From this data an informed decision can be made on what level to scale the virtual platform to. Utilising Resource Groups and DRS having a balanced environment that meets the current needs and future needs can be achieved. However these must be monitored so that resources are not being overcommitted an underutilised. There are a number of options available: Using VirtualCentre – VirtualCentre provides centralised management, administration and control of virtual machines and ESX servers. Using a third-party reporting tool such as esxCharter from VizionCore – this tool provides additional reporting and analysis facilities. More details on esxCharter can be found at http://www.vizioncore.com/esxCharter.html . Using performance information collected by the nWorks SPI (Smart Plug-In) for VMware Using a custom reporting tool – the SQL data created by VirtualCentre can be interrogated and reported on. These options are not mutually exclusive.
- VirtualCentre Management Server provides a convenient centralised management interface for all the physical and virtual servers managed by the VirtualCentre instance. It aggregates physical resources from multiple ESX Servers and presents a central collection of simple and flexible resources for the system administrator to provision to virtual machines in the virtual environment. VirtualCentre can play a key role in reporting on the performance of the virtual infrastructure. VirtualCentre can gather extensive sets of measurements on performance, resource utilisation, and basic statistics of all parts of the environment, including virtual machines, ESX Server hosts, resources pools, and host clusters. These metrics can be viewed using the VI Client, and are also available to external programs via the VMware Infrastructure SDK . All measurements may be obtained in real-time, or from a historic record. The real-time metrics are obtained by connecting directly to the source of the data and transmitting the desired measurements as they are collected. The metrics are collected every 20 seconds for ESX Server hosts. They can be viewed through a VI Client session with VirtualCentre or directly with an ESX Server host; in the latter case, only metrics pertaining to that host or the virtual machines on it are available. The historical metrics are drawn from the VirtualCentre database, and can only be viewed with a VI Client connected to the VirtualCentre server, or a program that uses the VMware Infrastructure SDK. VirtualCentre aggregates the value of each metric over successively larger time intervals, using smaller intervals to generate values which are then rolled. The volume and level of granularity of the virtual infrastructure historical data available depends upon the two factors: The Statistics Collection Level The Statistics Collection Interval The Statistics Collection Level determines which metrics are stored, and can be set between 1 and 4, with 4 being the maximum amount of data. Each higher number setting increases the amount of data collected. The latter determines both the time for which the data is kept, as well as the period over which the data is averaged. Both of these times can be configured, and you can have multiple Statistics Collection Intervals so that different levels of aggregation can be kept for different amounts of time.
- The Statistics Collection Level determines which metrics are stored, and can be set between 1 and 4, with 4 being the maximum amount of data. Each higher number setting increases the amount of data collected. The latter determines both the time for which the data is kept, as well as the period over which the data is averaged. Both of these times can be configured, and you can have multiple Statistics Collection Intervals so that different levels of aggregation can be kept for different amounts of time. Level 1 - This includes basic metrics—Average Usage for CPU, Memory, Disk, and Network; System Uptime, System Heartbeat, and DRS metrics. Does not include statistics for devices. Level 2 - This includes all metrics for CPU, Memory, Disk, and Network counters (average, summation, and latest rollup types; does not include maximum and minimum rollup types); System Uptime, System Heartbeat, and DRS metrics. It does not include statistics for devices. Level 3 - This includes all metrics (including device metrics) for all counter groups (average, summation, and latest rollup types; does not include maximum and minimum rollup types). Level 4 - This includes all metrics supported by VirtualCentre, including maximum and minimum rollup types. DSS recommend collecting Level 3 statistics initially. This will provide the greatest level of data in order to report on and diagnose problems: Evaluation of virtual machine co-location: determine which virtual machines can be shared effectively on the same server because of complementary memory sharing Capacity planning: observe how much memory is active, to determine whether or not it is possible to put another virtual machine on the same host Determining effectiveness of VSMP (by comparing ready and wait times for each virtual CPU) Diagnosing device performance, or comparing the performance of two different devices Setting the Statistics Collection Level to Level 4 will cause a large volume of data to be generated. However, the VirtualCentre server and database server specification recommended by DSS will ensure that there is sufficient resources to ensure this does not adversely impact performance. The size of the database will vary depending on the number of hosts and virtual machines managed, the frequency of performance data collection and type of database. The factors include: Each statistics sample collected is about 60 bytes for SQL, 100 bytes for Oracle, and each event stored is 1600 bytes for SQL, 600 bytes for Oracle. Using default settings, the statistical data for 25 hosts running 8-16 VMs per host will plateau around 40-60 MB in a year (80-140 MB if set to “full”). Each month, the average number of events generated will also consume about 190 MB in SQL, and 70 MB in Oracle. Total DB size after a year is expected to be around 2.20 GB in SQL, and 1.0 GB in Oracle. Using default settings, the statistical data for 75 hosts running 8-16 VMs per host will plateau around 90-150 MB in a year (200-330 MB if set to “full”). Each month, the average number of events generated will also consume about 190 MB in SQL, and 70 MB in Oracle. Total DB size after a year is expected to be around 2.40 GB in SQL, and 1.2 GB in Oracle.
- esxCharter is a real-time, top down management and reporting tool that provides key information for managing VMware ESX Server systems. esxCharter rolls up key performance metrics to a root level spreadsheet type view, allowing you to sort the information in a variety of ways. The objective of esxCharter is to allow many levels of administrators to access the data necessary to keep VMware ESX Servers performing according to required service levels. It provides a single interface to view a variety of key metrics easily from the host level, down to the guest level in real-time. Reports for capacity planning, trending and troubleshooting can be run against the historic data that has been collected. The data can be exported to CSV or TAB format at regular intervals. The reports can be regularly sent at predetermined intervals via email. Some of the key features of esxCharter include: "Top-down" views of entire virtual infrastructure Allows many level administrators to monitor VMware ESX Server Easily understand key performance metrics Find bottlenecks in the ESX Server farm Get "under the hood" type information presented in a Windows interface Consolidated real-time views of your ESX Servers Make on-the-fly performance adjustments Reports for performance trending Threshold alerts and automated emails of reports Billback properties for global host and VM
- esxCharter shows ESX Server host metrics along with "inside the guest" operating system metrics. The host metrics consist of but are not limited to: CPU %Used vs. %Ready (at the VMware Host level) Kernel vs. User (in the guest) Memory Total Free Active Swapped Ballooned Disk MB Read MB Write VMFS Free Space VMDK files Open .REDO files I/O per second Network Utilisation Mbit Receive Mbit Transmit Duplex Nic Errors Packets per second Console OS (COS) Information Free COS disk space Free Memory ESX Server version Guest OS Information esxCharter allows you to drill down to the guest and gain insight on the processes running in the guest.
- MOM stands for “Microsoft Operations Manager”. It is a system monitoring and reporting tool. It is used to monitor and collect data from servers and other sources. It can generate alerts based on events such as server outage, service failure or Low disk space. These alerts can then be assigned and tracked.
- MOM consists of a number of components: Database Server . Hold the managements pack configuration. Collects the events colleted by the Management Servers. Reporting Server . Collect the Events from the database server. The database server only holds event and other data for the short term and is pruned daily. The reporting server can hold the data long term. It only limited by the database size and performance. The reporting server is used for reporting trends etc. Management Servers . Collect events and data from the managed computers. Also update the managed computer with any changes in the rule that effect them, e.g. changing the period collection of performance data. Managed Computers . These are the computers (servers) that are being monitored. These computers can have an agent installed or be agentless. Those with the agents can collect more detail data. Consoles . these can be install on any computer and are used to read MOM data or modify its configuration. Operator Console, an MMC snap-in to allow operator to view Alerts, events and performance data. It also allows them update Alerts with resolution states and data Web Console, a slimed down version or operator console access via a web browser Administrator Console Reporting Console
- DSS recommend the nworks MOM Management Pack for VMware is selected for MOM integration if required. The nworks MP provides full Alerting and Performance charting on VMware VI3 enterprise system status, as well as operational information. It collects: Performance and Event data for VMware ESX Hosts, either from VirtualCentre or ESX directly Performance and Event data for VMware ESX Guest Virtual Machines, either via VirtualCentre or ESX directly Events and Alerts from VirtualCentre in many categories such as security, status/state-change, object creation/deletion and other management & admin actions taken in VirtualCentre. The Topology of the Virtual Infrastructure within VirtualCentre – Data centres, Folders, Clusters, Hosts and Guests Events and Alerts from nworks own VEM Collector service The detailed data available in the nworks MP is delivered by use of the VMware SDK on VirtualCentre, which gives an accurate picture of the status of VirtualCentre, the managed Hosts, and the Guest Virtual Machines. The MOM Management Packs runs the nworks Collector. The nworks Collector component is a Windows service which can run on a physical server or a Virtual Machine. The Collector is also referred to as VEM (Virtual Enterprise Monitor). The VEM server can be a virtual server to reduce cost. The nworks Collector architecture does not require the installation of software on the ESX Server. The nworks MOM Management Pack two versions: VMware Events Only MP for MOM - handled only VMWare events VMware MP for MOM - covers both events and performance logging The second version is more expensive but more functional. It can collect up to 300 metrics on the operation of virtual servers.
- Server software patching arises in a virtual infrastructure just like a standard server infrastructure.
- Upgrades and patches are distributed as bundles. Bundles are classified as security, critical or general. You must subscribe to receive VMware patches. They are distributed monthly. Esxupdate allows patches to be installed from a centralised server. This can be a local virtual server. Patch update can be automated. Esxupdate maintains a database of patching activity. Note that some bundles may require the ESX server to be rebooted. This will need to be scheduled. You will need to develop and test an ESX patching strategy.
- An approach to patching of the virtualised server will be required to be developed, agreed and implemented if required. Failure to implement a patch management strategy could have serious consequences for HP. Business critical systems may fail, or security-sensitive systems could be maliciously exploited. Microsoft SMS, WSUS or a similar tool can be used to implement server patching. The use of VMware can assist in server patching by allowing server snapshots to be taken before patching takes place. This will reduce the testing effort by allowing an element of “implicit” testing where, unless problems occur, the patches remain applied. Implementing this will allow you to deploy mandatory software updates with limited user involvement. Tools such as SMS or WSUS provides facilities and processes to: Identify critical patches Determine vulnerable systems Deliver patches reliably and quickly Accurately report delivery status The steps are: Configure the patch management tool for software update management Install and deploy software update inventory tools Install and deploy a software updates installation agent Install and configure synchronisation component requires Internet connectivity and be installed on a separate server or patch management server Install and configure software update distribution s Wizard on the patch management server and administrator consoles
- Some or all of the following processes can be manage the physical and virtual infrastructure: Server Requisition And Tracking Process - This process will define how requests for new servers are to be handled and actioned. Server Resource Requirements Gathering Process - This process will define how the resource requirements for new servers are to be gathered, defined and documented. Server Inventory and Virtualisation Planning Initiation Process - This process will define how the virtualisation of existing servers will be handled including gathering an inventory of servers and how the planning process and the interaction with the customer will be handled. Server Capacity Planning Process - This process will define how server capacity planning is to be handled and implemented. Server Capacity Planning Analysis and Reporting Process - This process will define how the outputs from the server capacity planning and analysis process will be analysed and reported on and the results reviewed and communicated to the customer. Server Virtualisation Infrastructure Requirements Process - This process will define how the outputs from the server capacity planning and analysis process in translated into physical server requirements and how the virtual servers will be implemented. Virtual Infrastructure Expansion Process - This process will define how required additional physical infrastructure required to support additional virtual servers will be installed and implemented and how the virtual infrastructure will be expanded to accommodate additional physical servers. Server Virtual Infrastructure Setup Process - This process will define the process for implementing virtual servers. It will cover the implementation of new virtual servers and the virtualisation of existing physical servers. Server Virtualisation Process Including UAT and OAT - This process will define how User Acceptance Testing and Operations Acceptance Testing are to be performed on both new virtual servers and existing physical server that are being virtualised. Server Monitoring and Reporting Process - This process will define how virtual servers are to be monitored and reported on after virtualisation. It will include monitoring compliance with server SLAs. Server Management Process - This process will define the ongoing server management process including integration within ActiveDirectory for access to VMware VirtualCentre functionality, access to iLo (Integrated Lights Out) functionality of the physical servers and server patching and updating procedures. Server Retirement/Archival Process - This process will define the process for retiring servers that are not required permanently or for the quiescing of enduring OAT environments.
- A project to implement a virtual server infrastructure will consist of the following general activities and tasks: Project Initiation Phase Produce Project Initiation Document (PID) Planning Phase Define customer requirements Virtualisation architecture planning and documentation Solution design Execution Phase Install and configure Server migration Cutover Documentation Training Maintenance Project Management Manage project, scope, change, communications Project Close Ensure project closes satisfactorily