Linux on System z. ProvisioningscenarioswithIBMTivoli Service Automation Manager 7.2.2

Transcription

1 Linux on System z ProvisioningscenarioswithIBMTivoli Service Automation Manager 7.2.2

2

3 Linux on System z ProvisioningscenarioswithIBMTivoli Service Automation Manager 7.2.2

4 Note Before using this information and the product it supports, read the information in Notices on page 37.

5 Contents Figures v Tables vii About this publication ix Chapter 1. Introduction Objectives Summary Chapter 2. Hardware and software configuration Server configuration System x hardware Chapter 3. z/vm and Linux setup Environment description Chapter 4. Installation Providing the installation source files Chapter 5. Workload description Chapter 6. Test scenarios and results 15 Baseline test Image creation times LPAR CPU load CPU load per guest Network traffic Memory utilization Disk throughput CPU scaling Appendix. XML DCM import files used in the project _Cloud_Global_Properties.xml _Cloud_Global_Networksettings.xml _Cloud_Networksettings_zVM.xml _0_Cloud_Bootserver_zVM.xml _1_Cloud_zLinuxImage_zVM.xml _2_Cloud_Vswitches_zVM.xml _Cloud_Pool_zVM.xml References Notices Trademarks Terms and conditions Index Copyright IBM Corp iii

6 iv Linux on System z: Provisioning scenarios with IBM Tivoli Service Automation Manager 7.2.2

7 Figures 1. FlashCopy with background copy Major components for the test environment 5 3. TSAM Cloud network administration TSAM: Cloud customer template TSAM: Create Customer window TSAM: Create projects to provision images TSAM: Log in screen TSAM: Create a new project screen LPAR CPU load while processing 10 images in single image provisioning mode CPU load over time for the infrastructure guests CPU load over time for the provisioned guests Total network throughput (send + receive) from the VSWITCH Disk throughput over time for the infrastructure guests CPU load over time for the new provisioned guests for the scenario2 (3 physical CPUs for z/vm, TSAMbase and TSAMdb2 system with 1 virtual CPU each) Copyright IBM Corp v

8 vi Linux on System z: Provisioning scenarios with IBM Tivoli Service Automation Manager 7.2.2

9 Tables 1. Server software used TSAM installation packages Table of disk space System setup for baseline tests Image creation time for the base line test with 2 z/vm IFLs Average and maximum CPU utilization of the infrastructure guests (100%=1IFL) memory requirements (resident pages) of the infrastructure guests [MB] from z/vm page Provisioning times and CPU load for scaling the number of CPUs Copyright IBM Corp vii

10 viii Linux on System z: Provisioning scenarios with IBM Tivoli Service Automation Manager 7.2.2

11 About this publication This paper provides results for testing Tivoli Service Automation Manager on Linux to provision Linux instances on the z/vm Hypervisor on IBM System z processors. Authors v Dr. Juergen Doelle v David Sadler Acknowledgements Thank you to the following people for their contributions to this project: v Roland Langner, TSAM for System z, system tester v Mark Leitch, STSM Tivoli Performance and High Availability Solutions v The authors of the IBM Redbook DFSMShsm Fast Replication Technical Guide Copyright IBM Corp ix

12 x Linux on System z: Provisioning scenarios with IBM Tivoli Service Automation Manager 7.2.2

13 Chapter 1. Introduction An introduction to the Tivoli Service Automation Manager (TSAM) and what the tests described in this white paper set out to achieve. TSAM assists in the automated provisioning, management, and deprovisioning of hardware servers, networks, operating systems, middleware, and application-level software. Tivoli Service Automation Manager also provides management support for services consisting of a specific set of middleware (WebSphere ND), in combination with AIX and Linux (System x and System z). Many automation service definition templates are provided, including specialized job plans or workflows. TSAM also exploits the entire spectrum of Tivoli process automation engine tools. For more information, refer to: TSAM helps to define and automate services that are lifecycle-oriented. For example, an IT server network can be made available for a limited period of time to run a test or handle a temporary increase in workload. A service definition template specifies the overall framework for a service offering. This service definition template can then be customized and made available as an offering that can be selected when a service is needed. TSAM and the fully integrated provisioning product, Tivoli Provisioning Manager, can be used to create and rapidly provision Linux on System z guests in a z/vm hosting environment. The procedures to install and configure Linux, which as a manual process can take an hour or more, can be automated and reduced to a matter of minutes, depending on the devices configured for the guest and the speed of disk-to-disk copy operations on the storage system hardware. TSAM can be hosted on System z or non-system z hardware to manage System z hardware, software, and operating systems. Objectives This project implements the Tivoli Service Automation Manager for Linux on System z to also manage Linux guests on System z. It uses a deprecated z/vm interface (SMAPI), which is still supported for Tivoli Service Automation Manager (TSAM) users up to z/vm 6.1. It provides a sample installation to guide you through the installation steps and provide sizing suggestions. The results of this project can be used to establish a performance baseline. Summary The performance behavior of TSAM for Linux on System z running on a System z Enterprise and z/vm 6.1 as Hypervisor was investigated in single image provisioning mode. It took an average time of 2 minutes and 13 seconds to create the guest; this was very fast. The resource requirements were very low. After the warming- up phase the average CPU load from the infrastructure guests was about 0.25 IFLs, with peaks Copyright IBM Corp

14 up 0.4 IFLs during the image creation phases. The TSAM base system had the highest CPU load. Noteworthy network traffic appears only between the TSAM base system and the back-end database; the total size of network traffic (send and receive) was moderate with a maximum value of below 2 MBytes/sec. The configured memory size of the infrastructure guests was 24GB. Due to optimizations inside z/vm less than 12GB was actually allocated. The disk I/O requirements were also very moderate at less than 1MBytes/sec. The disk I/O traffic caused by image cloning is executed in a highly optimized manner by the FlashCopy feature of the IBM DS8700 storage server inside the storage server. 2 Linux on System z: Provisioning scenarios with IBM Tivoli Service Automation Manager 7.2.2

15 Chapter 2. Hardware and software configuration Server configuration This section provides details about the hardware and software used in our testing. Server hardware System z One z/vm LPAR on a 32 way IBM System z196 EC, 5.2 GHz, model , equipped with: v Up to 4 physical CPUs dedicated to z/vm v 200 GB central memory and 4 GB expanded storage v 2 x 1 GBit OSA card for external LAN communication Storage server setup The storage server is a DS8700, connected with 4 FICON express cards at 2GBit/sec link speed. The FlashCopy feature of the IBM DS8700 storage server was used for image cloning (see Figure 1). Figure 1. FlashCopy with background copy Copyright IBM Corp

16 More details about FlashCopy can be found in the IBM Redbook System Storage DS8000 Series: IBM FlashCopy SE at Server software Table 1 shows the software used on the System z host. Table 1. Server software used Product Version and release IBM DB2 Universal Database Enterprise Server 9.7 fixpack 4 SUSE Linux Enterprise Server SLES 10, SP3 Tivoli Service Automation Manager (TSAM) Version WebSphere Application Server 6.1, part of the TSAM package IBM Tivoli Directory Server (ITDS) 6.2, part of the TSAM package DB2 Universal Database 9.5, part of the TSAM package System x hardware Details about the TSAM software components are listed in the Chapter 4, Installation, on page 7. For this project a Windows XP system is used as the administration server. This is required to install and administer the TSM system, but has not impact of the performance of the system when provisioning images. 4 Linux on System z: Provisioning scenarios with IBM Tivoli Service Automation Manager 7.2.2

17 Chapter 3. z/vm and Linux setup Environment description This topic details the modifications we made to the system setup for our z/vm and Linux environments. Figure 2 shows the major components for the test environment. Figure 2. Major components for the test environment The IBM Tivoli Service Automation Manager (TSAM), Tivoli Provisioning Manager (TPM), DB2 and IBM Tivoli Directory Server (ITDS) components were installed as separate z/vm Linux guests. Note: Under z/vm a very large number of guests can be logged on (about 100,000), for more details, see There is no limitation which enforces how the software components are distributed amongst the guests. All Linux guests were configured with a NIC (simulated network interface card) that attaches to a z/vm Virtual Switch (VSWITCH). A restricted private VM LAN was defined for communication between the MAPSRV Linux guest and the VSMSERVE guest. The master Linux image from which all the provisioned Linux guests were created resides on one minidisk and is not active. Copyright IBM Corp

18 6 Linux on System z: Provisioning scenarios with IBM Tivoli Service Automation Manager 7.2.2

19 Chapter 4. Installation During installation, the Tivoli Service Automation Manager Installation Launchpad was used to check system prerequisites and then to install the prerequisite software and the Tivoli Service Automation Manager product itself. The principal prerequisite for Tivoli Service Automation Manager, is the Tivoli Provisioning Manager (TPM), and this includes the necessary middleware and base services for the shared product environment. TSAM itself is packaged as a set of process management products (PMPs). The Installation Launchpad starts on each server in the management system on which software is to be installed. The Installation Launchpad is also started on the administrative server to install certain platform-independent components on the management system. Software related to the deployment of the components within the management system is installed on the administrative server. You therefore use the administrative server to install product upgrades and applications on the management system. The administrative server is not needed for normal operation, but it is essential for providing service. If you lose the administrative server, you are no longer able to maintain the management server. Also, if you make a backup of your management system, you must also back up the administrative server state that exactly matches it. Otherwise you are not able to apply any further PMP or service upgrades to your management system. Providing the installation source files This topic describes how to prepare the installation source files for Tivoli Service Automation Manager and its prerequisites on various operating system platforms. The software can be installed directly from the product CD or DVD or downloaded from Passport Advantage at Fix packs can be downloaded from Fix Central at You specify the location of the CD or DVD or the source directory for all required packages in the Tivoli Service Automation Manager launchpad. Any software package must be made available on the appropriate management or administrative server on which the launchpad is started for that particular step in the process. To install Tivoli Service Automation Manager (TSAM) an NFS file system was used. Each system that needed to have software installed on it, mounts the NFS files. The Windows XP administration server accessed the files via Samba services. Table 2 lists the TSAM components that were downloaded. Table 2. TSAM installation packages File CI03BML TivSAM_Base_V722.zip Content Tivoli Service Automation Manager Base V7.2.2 Copyright IBM Corp

20 Table 2. TSAM installation packages (continued) File CZZ5JML TPM_V720_Install_Win.zip CZZ5KML TPM_V720_Install_Unix.tar CZFS5ML TPM_V720_Install_Suppl_Win.zip CZFS6ML TPM_V720_Install_Suppl_Unix.tar CZFT5ML TPM_V720_CoreComp_1of2_zLinux64.tar CZZA6ML TPM_V720_CoreComp_2of2_zLinux64.tar CZFV4ML TPM_V72_Midlwr_zLinux64.tar CZPD2ML TSRMfSP_V720.tar CZ9AYML TSRM_Int_Tool_Kit_V720.tar CI0D2ML CI0D2ML.tar Content Tivoli Provisioning Manager V7.2.0 Installer Tivoli Provisioning Manager V7.2.0 Core Components Tivoli Provisioning Manager V7.2.0 Middleware Tivoli Service Request Manager for Service Providers V7.2.0 Multiplatform Tivoli Service Request Manager Int Tool Kit Tivoli Provisioning Manager for Images V7.1.1 In addition to the above, the following required fix packs were obtained from IBM Fix Central: v 7.2-TIV-Components-zLinux-FP0001.tar v 7.2-TIV-TPM-Linux-FP0001.tar v 7.2-TIV-WebComp-Unix-FP0001.tar v 7.2-TIV-WebComp-Windows-FP0001.zip v TIV-Components-zLinux-IF00001.tar v TIV-TPM-Multi-IF00001.zip v 7.2-TIV-WebComp-Unix-FP0002.tar v 7.2-TIV-WebComp-Windows-FP0002.zip v TIV-TSAM-HF0001.zip v TIV-SRM-FP0001-REFRESH.tar v TIV-SRM-FP0001-REFRESH.zip The packages were extracted into the following directory structure: v SRM FP0001-REFRESH.extracted v SRMfSP_V720.extracted v TPM_FP1.extracted v TPM_WebComp-Win-FP1.extracted v SRM extracted v TIV-TSAM-HF0001.extracted v TPM_FP2.extracted v TPM_WebComp-Win-FP2.extracted v SRM7.2.extracted v TPM _iFix1.extracted 8 Linux on System z: Provisioning scenarios with IBM Tivoli Service Automation Manager 7.2.2

21 v v v v v v TPM_V720_Install_Suppl_Unix.extracted TPMfI_ extracted SRM_Int_Tool_Kit_V720.extracted TPM7.2.extracted TPM_V720_Install_Win.extracted TivSAM_Base_V722.extracted Note: It can take up to 30 hours to complete the installation of all the required components. Special attention must be paid to the space required on each system to complete the installation. Table 3 lists the file sizes used in our environment. Table 3. Table of disk space Header Header Header ITDS / /home /opt /tmp /usr DB2 server / /home /opt /tmp /usr /var TPM server / /home /opt /tmp /usr /var 6.8 GB 8.9 GB 5.0 GB 3.0 GB 3.0 GB 6.8 GB 24.0 GB 4.0 GB 4.0 GB 3.0 GB 6.0 GB 6.8 GB 8.9 GB 23.0 GB 6.0 GB 7.9 GB 8.9 GB The correctly sized volumes were provided as logical volumes based on LVM volume groups. A problem was encountered during the installation when the option to create a persistent store for TPM was selected. The database MAXSIBDB was not automatically created by the installation scripts. This meant that the MAXSIBDB database had to be created manually, and the installation scripts created the correct data source for the persistent store. To create the MAXSIBDB database, the instructions were followed as described here: topic=%2fcom.ibm.tivoli.tpm.ins.doc%2finstall%2ft_ccmdb_manconfigdatasource.html The provisioning backend z/vm must be configured after the TSAM product has been installed. The following outlines the basic steps in this process: 1. Plan for the environment. 2. Define CP_Owned and User_Volume DASD. 3. Set up the z/vm Network version 5.4, and VSWITCH. 4. Update the TCP/IP configuration. 5. Set up DIRM. 6. Enable VSMSERVE. For details, see Chapter 4. Installation 9

22 7. Create the Linux prototype. 8. Install the Linux master system. 9. Enable personalization. Systems that have RACF enabled require additional setup by the security administrator. For more information about z/vm, and Linux on System z, see the z/vm publication Getting Started with Linux on System z. Configuring the cloud server pools The final step to completing the TSAM installation and configuration is to configure the cloud server pools. All these configuration steps were performed manually using the Cloud Server Pool Administration application. The configuration of a z/vm cloud server pool can be performed using DCM import files only, and it consists of the following steps: 1. Customize the DCM import files that are delivered with the Tivoli Service Automation Manager media: v 00_Cloud_Global_Properties.xml, Common file for all hypervisor types Note: Since fixpack 2 this xml file is no longer required. v 10_Cloud_Global_NetworkSettings.xml. Global file containing all network DCM objects v 13_Cloud_NetworkSettings_zVM.xml, Hypervisor network configuration for z/vm. Virtual Switch templates for management and customer network. v 23_0_Cloud_Bootserver_zVM.xml. Boot server configuration for z/vm. v 23_1_Cloud_zLinuxImage_zVM.xml. Image definitions for z/vm. v 23_2_Cloud_Vswitches_zVM.xml. VSWITCH definition for z/vm. v 33_Cloud_Pool_zVM.xml. Cloud Pool definition for z/vm. v 42_Cloud_ITM_Agent_Linux.xml (if IBM Tivoli Monitoring is required) 2. Load the customized DCM import files. 3. Create a cloud server pool for z/vm using the Cloud Server Pool Administration application. 4. Run the z/vm discovery and enable the cloud server pool. XML DCM import files used in the project, on page 25 contains the xml DCM import files used in this project. After you have imported the required xml files, the following steps need to be completed before you can start using the TSAM user interface. 1. Import the Network Template xml, for example, PMZHB_SingleNicNetworkTemplate.xml and set it to active Goto > Service Automation > Cloud Network Administration 10 Linux on System z: Provisioning scenarios with IBM Tivoli Service Automation Manager 7.2.2

23 Figure 3. TSAM Cloud network administration 2. To create a Cloud Customer template and assign the Cloud Network template, go to Service Automation > Configuration > Cloud Customer Administration Figure 4. TSAM: Cloud customer template The Network Configuration template is available for assignment in the TSAM interface when you create the customer. 3. Log on to the TSAM interface and continue with the following steps: a. Create a customer from the Home window. To do this, Select Request a New Service > Virtual Server Management > Manage Customers > Create Customer. The Create Customer window opens: Chapter 4. Installation 11

24 Figure 5. TSAM: Create Customer window b. Assign customer resources. Log on to the administrative interface. Select Go To > Service Automation > Configuration > Cloud Customer Administration. Filter for the customer name assigned above and then assign the cloud server pool to the customer. Now projects can be created to provision images. Figure 6. TSAM: Create projects to provision images 12 Linux on System z: Provisioning scenarios with IBM Tivoli Service Automation Manager 7.2.2

25 Chapter 5. Workload description Rational Performance Tester was used to drive the workload for the test. About this task RPT scripts were recorded to simulate the action of a user creating a projects. The recorded test was then used to create various RPT schedules to drive the performance tests. The RPT recorded test consists of the following actions: Procedure 1. Log on to SimpleSRM. (Web 2.0 UI to define service requests) Figure 7. TSAM: Log in screen 2. Create a new project. Copyright IBM Corp

26 Figure 8. TSAM: Create a new project screen 3. Loop checking status until either Success or Failed status Results The above actions were recorded and stored in a RPT script that was then used to create the workload used in our tests. 14 Linux on System z: Provisioning scenarios with IBM Tivoli Service Automation Manager 7.2.2

27 Chapter 6. Test scenarios and results Baseline test The project is organized into two test cases. The Baseline test shows the resource utilization for single VM (virtual machine = guest) provisioning, followed by a CPU scaling test. Single VM provisioning was tested, that is, one or more single projects are created, which are executed serially. The master image is SLES10 SP3, the provisioning images are Linux on System z (z/vm Hypervisor) as target, residing on a mod9 (fullpack minidisk) DASD device. Swapping is implemented via swapfile (no dedicated partition or disk). The master image is contained on a single minidisk. v v The baseline is determined with a small setup, where the z/vm has only 2 IFLs. The important factor here is the amount of resources required to drive the management infrastructure. A CPU scaling was performed to identify the SMP requirements. This test case is to test the setup and provide the performance baseline for the single VM provisioning throughput test. It loops ten times over an image create. Table 4 shows the system setup for this test. Table 4. System setup for baseline tests Memory[GB] REAL + System #CPUs XSTORE Architecture z/vm 6.1 2, physical LPAR Tivoli Service Automation 1, virtual 10 Linux guest Manager (TSAM) DB2 1, virtual 12 Linux guest IBM Tivoli Directory Server 1, virtual 1 Linux guest (ITDS) MAPSRV 1, virtual 0.5 Linux guest Image creation times The following table gives the relative start and completion times for each image (the size of the master disk was 6 GB). Table 5. Image creation time for the base line test with 2 z/vm IFLs Start [hh:mm:ss] End [hh:mm:ss] Elapsed time [hh:mm:ss] 0:00:44 0:03:05 00:02:21 0:04:42 0:06:52 00:02:10 0:08:43 0:10:54 00:02:11 0:12:43 0:14:53 00:02:10 0:16:12 0:18:31 00:02:19 0:20:13 0:22:23 00:02:10 Copyright IBM Corp

28 Table 5. Image creation time for the base line test with 2 z/vm IFLs (continued) Start [hh:mm:ss] End [hh:mm:ss] Elapsed time [hh:mm:ss] 0:24:13 0:26:26 00:02:13 0:27:44 0:29:53 00:02:09 0:31:13 0:33:31 00:02:18 0:35:13 0:37:22 00:02:09 LPAR CPU load Observation The average is 2 minutes and 13 seconds with a deviation of -4 seconds from the minimum and +8 seconds from the maximum. This elapsed time is the time taken for the RPT simulation of the TSAM GUI to create a project and the time that TPM takes to provision the image and verify that it is operational. Conclusion A value of 2 minutes and 13 second to log on, install the image and verify the install is very short, these are very good values! These results discuss the impact on the LPAR CPU load in single provisioning mode. Figure 9 shows the LPAR CPU load while processing 10 images in single image provisioning mode. The times when the images are created are super-imposed on the charts as a series of vertical bars. Figure 9. LPAR CPU load while processing 10 images in single image provisioning mode 16 Linux on System z: Provisioning scenarios with IBM Tivoli Service Automation Manager 7.2.2

29 CPU load per guest Observation The CPU utilization is below 0.4 IFLs most of the time. Noticeable events are the two spikes in CPU utilization at 18 and 33 minutes. Conclusion The amount of 0.4 IFLs can be considered as low CPU cost to drive the whole infrastructure. These peaks are unexpected. To analyze these spikes further, the CPU utilization for each guest system was examined. This topic discusses the average and maximum CPU load. Table 6 shows the average and maximum CPU load for the infrastructure guests (DIRMAINT, VMSERVE, TSAMbase, TSAMdb2 and ITDS). Table 6. Average and maximum CPU utilization of the infrastructure guests (100%=1IFL) DIRMAINT tsambase tsamdb2 itds MAPSRV VSMSERVE Average 1,2% 12,5% 6,3% 0,8% 1,3% 2,1% Max 8,6% 60,1% 20,6% 2,1% 4,5% 10,0% Observation All guests have a low CPU consumption. The TSAMbase guest has the highest CPU consumption and this is 12% on average and 60% at its maximum. The database uses on average only 6% of one IFL, and at its maximum 21%. All other infrastructure guests are on average around 2% or below, with a maximum of 10%. Conclusion The CPU resources required by the infrastructure guests is very low. The sum of the average CPU usage from all TSAM guests is about 1/4th IFL. As expected, the TSAMbase system with its large software stack has the highest utilization. From the z/vm perspective it does not matter if the application stack is distributed over multiple guests or if it is concentrated in one guest. CPU load over time for the infrastructure guests Figure 10 on page 18 shows the CPU load over time for the infrastructure guests (DIRMAINT, VMSERVE, TSAMbase, TSAMdb2 and ITDS) and figure 10 shows it for the newly provisioned guests (LNXCLD01-LNXCLD10). Chapter 6. Test scenarios and results 17

30 Figure 10. CPU load over time for the infrastructure guests Observation The highest CPU load occurs only at the start of the workload. For the remaining phase the average CPU load from the infrastructure guests is about 0.25 IFLs, with peaks during the image creation phases. The maximum CPU load here is 0.4 IFLs. The TSAM base system uses the most CPU load. Conclusion The relatively high peak at the beginning is certainly caused by the servers warming up (allocating memory buffers, loading data and so on), it does not reach that load during normal operation. The CPU spikes observed in the LPAR load are not caused by the infrastructure guests. That the TSAM base system consumes the most CPU is expected, because it has the largest and most complex software stack of all infrastructure guests. However, the average load of 0.25 IFLs with peaks up to 0.4 IFLs for the infrastructure is a very small effort. 18 Linux on System z: Provisioning scenarios with IBM Tivoli Service Automation Manager 7.2.2

31 CPU load over time for the provisioned guests Figure 11. CPU load over time for the provisioned guests Network traffic Observation This chart shows that each guest consumes a a small amount CPU after it has been created. The large peaks in CPU load are caused by the last three to four provisioned guests. Conclusion After the new guest has been created, it is started and several verification tasks are performed. This is shown in the chart. After creating four guests some additional work is executed on these guests (and only on these guests). Figure 12 on page 20 shows the network throughput (send + receive) from the TSAMbase system, the database, the ITDS system, and the total traffic. The total traffic contains the network throughput from all guests, but the contribution from all other guests is below 30KBits/sec, which can be ignored. This includes the network traffic to the newly created guests (sending some commands one time only to that guest, also falls into that category). Chapter 6. Test scenarios and results 19

32 Figure 12. Total network throughput (send + receive) from the VSWITCH Observation There is network communication only between the TSAMbase system and the database, and it is in the same amount, which means that they are mostly talking to one another. Communication with other guests appears to be very limited. There are multiple peaks between image creation times. Only two peaks are above 14 Mbit/sec, they are correlated with the peaks shown in CPU load, but 2 minutes earlier. Conclusion Only the communication between the TSAMbase system and the database is remarkable. There is some network activity from other guests (continuously at ITDS and MARPSRV, and also from the newly created guest when it is created), but this is at a very low intensity. The total size of network traffic (send and receive) is moderate at a maximum value of below 2 MBytes/sec. It seems that there is one peak each in the network traffic between TSAMbase and the database before and after the image creation phase. The peak before is certainly related to gathering the required information, scheduling, and executing the provisioning step, while the peak after the image has been created stores the result of that process in the database. There are two extraordinary high peaks, before the image creation phases, which have the peak in CPU load at the end. That indicates that these activities are triggered by TSAM. 20 Linux on System z: Provisioning scenarios with IBM Tivoli Service Automation Manager 7.2.2

33 Memory utilization Memory requirements are important for sizing considerations. Table 7 shows the memory requirements for the infrastructure guests. Table 7. memory requirements (resident pages) of the infrastructure guests [MB] from z/vm page [MB] DIRMAINT tsambase tsamdb2 itds MAPSRV VSMSERVE Total (infrastructure) configured guest size maximum resident memory Disk throughput Observation The resident memory is the amount of memory allocated in real storage. In all cases there is a difference between the amount of resident memory and the configured memory guests size. Conclusion The difference between the real memory allocation and the defined guest size shows that, at least for single provisioning mode, the guests definitions are oversized. However, it shows also that z/vm handles that very well by allocating only the memory, which is really in use. This test investigates disk activity and disk I/O requirements. Figure 13 on page 22 shows the total disk throughput for the infrastructure guests over time. Chapter 6. Test scenarios and results 21

34 Figure 13. Disk throughput over time for the infrastructure guests Observation The major contribution to disk I/O comes from the database system. The disk activity from the other guests can be ignored. After the warmup phase the total amount of disk throughput is below 1 MB/sec. Conclusion The disk I/O requirements are very moderate in the single image provisioning mode. The disk activity appears to be correlated with the network activity and is caused by TSAM triggering the execution of the TPM workflows. Copying from the master image to the provisioned guest image is done using flash-copy. This is executed directly on the storage server and therefore this traffic is neither visible in Linux nor in z/vm. CPU scaling These results investigate the impact that scaling CPUs can have on provisioning times and CPU load. Table 8 shows the provisioning times and CPU load when scaling the number of virtual and physical CPUs. Table 8. Provisioning times and CPU load for scaling the number of CPUs # physical CPUs # virtual CPUs Average values Peak values Provisioning Scenario z/vm TSAMbase tsamdb2 time LPAR load LPAR load :13 0,32 1, :10 0,28 1,78 22 Linux on System z: Provisioning scenarios with IBM Tivoli Service Automation Manager 7.2.2

35 Table 8. Provisioning times and CPU load for scaling the number of CPUs (continued) # physical CPUs # virtual CPUs Average values Peak values Provisioning Scenario z/vm TSAMbase tsamdb2 time LPAR load LPAR load :11 0,29 1, :11 0,31 1,15 Observation The scenarios where the sum of the virtual CPUs from the TSAMbase and TSAMdb2 system is identical to the number of physical CPUs show higher CPU load and longer provisioning times than the setup where the number of virtual CPUs is smaller (scenario 2 in Table 8 on page 22). But the differences are small. The lower peak LPAR CPU value from the first scenario with two z/vm CPUs is related to a longer duration of the peaks. Conclusion The setup 2. with the smallest sizing for TSAMbase and TSAMdb2 and an 'extra' physical CPU, which is fully available even when these two important guests are under load, performs best. This is not surprising because there is also some load from the CMS guests (DIRMAINT and VSMSERVE) and from the newly provisioned guests, which can run on that extra CPU. This seems to reduce a slight contention, even the CPU load never exceeds the total capacity. CPU consumption for the newly provisioned guests Figure 14 on page 24 shows the CPU consumption for the newly provisioned guests from scenario 2 in Table 8 on page 22. Chapter 6. Test scenarios and results 23

36 Figure 14. CPU load over time for the new provisioned guests for the scenario2 (3 physical CPUs for z/vm, TSAMbase and TSAMdb2 system with 1 virtual CPU each) Observation The overall CPU load is slightly lower than in figure 10 (CPU load from scenario 1 in Table 8 on page 22), the peaks are sharper and higher. Conclusion The mechanism which causes these load peaks on the newly provisioned guests is the same in all scenarios. The lower overall CPU load compared to the scenarios 3 and 4 (see table Table 8 on page 22) confirms the experience that it is always good not to oversize guests. Scenario 1 shows the performance toolkit report more guests with wait states for CPUs than in all other scenarios. Even the total CPU capacity is never exceeded as you can see in Figure 9 on page 16, and there are small percentage wait values for the CPU. This indicates that there are moments where multiple guests want run with a total of more than two virtual CPUs at the same time. 24 Linux on System z: Provisioning scenarios with IBM Tivoli Service Automation Manager 7.2.2

37 Appendix. XML DCM import files used in the project A list of the import files that were you used in the in samples in this project. 00_Cloud_Global_Properties.xml Note: The XML file is part of the Tivoli Service Automation Manager product and may by used only by the licensee of the product for the configuration of the program. The product license IPLA applies accordingly. <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE datacenter PUBLIC "-//Think Dynamics//DTD XML Import//EN" "xmlimport.dtd"> <!-- ****************************************************************** * Licensed Materials - Property of IBM * IBM Product Name (program number 5724-W78) * (C) Copyright IBM Corp All Rights Reserved. * * US Government Users Restricted Rights * Use, duplication or disclosure restricted by GSA ADP Schedule * Contract with IBM Corp. * * DISCLAIMER OF WARRANTIES : * * Permission is granted to copy and modify this Sample code, and to * distribute modified versions provided that both the copyright * notice,- and this permission notice and warranty disclaimer appear * in all copies * and modified versions. * * THIS SAMPLE CODE IS LICENSED TO YOU AS-IS. * IBM AND ITS SUPPLIERS AND LICENSORS DISCLAIM ALL WARRANTIES, EITHER EXPRESS OR * IMPLIED, IN SUCH SAMPLE CODE, INCLUDING THE WARRANTY OF NON-INFRINGEMENT AND THE * IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. IN NO * EVENT WILL IBM OR ITS LICENSORS OR SUPPLIERS BE LIABLE FOR ANY DAMAGES ARISING * OUT * OF THE USE OF OR INABILITY TO USE THE SAMPLE CODE, DISTRIBUTION OF THE SAMPLE * CODE, OR COMBINATION OF THE SAMPLE CODE WITH ANY OTHER CODE. IN NO EVENT SHALL * IBM OR ITS LICENSORS AND SUPPLIERS BE LIABLE FOR ANY LOST REVENUE, LOST PROFITS * OR DATA, OR FOR DIRECT, INDIRECT, SPECIAL, CONSEQUENTIAL,INCIDENTAL OR PUNITIVE * DAMAGES, HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY,-, EVEN IF * IBM OR ITS LICENSORS OR SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH * DAMAGES. ****************************************************************** --> <datacenter> <kanaha-config> <dcm-object id="0" type="managedsystem" name="kanaha"> <property component="kanaha" name="pmrdp.net.multinicsupport" value="true"/> <property component="kanaha" name="cloud.disable_host_on_failure" value="false"/> <property component="kanaha" name="cloud.failure_retry_count" value="1"/> <property component="kanaha" name="cloud.host_transaction_number_limit" value="30"/> <property component="kanaha" name="cloud.max_concurrent_server_operations" value="10"/> <property component="kanaha" name="cloud.mpio_san_enable" value="true"/> <property component="kanaha" name="cloud.mhzpercpuunit" value="1000"/> <property component="kanaha" name="cloud.tftp_server_name" value="cloud-tftp"/> <!-- replace TIO_HOME with fully qualified path name --> <property component="kanaha" name="cloud.rsafile" value="/opt/ibm/tivoli/tpm/keys/tsam/identity"/> <!-- deprecated properties --> <property component="kanaha" name="cloud.vmguestprefix" value="vm"> <!--legacy network configuration properties, don t use with PMRDP.Net.MultiNicSupport /--> Copyright IBM Corp

38 <!--property component="kanaha" name="cloud.dual_nic_mode" value="false" /--> <!--property component="kanaha" name="cloud.enable_vlan_support" value="false" /--> <!--property component="kanaha" name="cloud.vrf_mode" value="false" /--> <!--property component="kanaha" name="cloud.nativevlanid" value="4" /--> <property component="kanaha" name="cloud.dynamic_host_networks" value="false"/> <property component="kanaha" name="cloud.delete_backup_image" value="true"/> </dcm-object> </kanaha-config> <!-- used during provisioning to hold temporary network information --> <server name="tempnicserver" locale="en_us" ignored-by-resource-broker="false" failed="false"> <!-- object to hold temporarily computer artifacts needed during buildup of a new virtual machine ip is not needed, name binding, do not change name --> <resource name="computer" resource-type="generic" managed="false" partitionable="false"> <property component="kanaha" name="computer.manufacturer"/> <property component="kanaha" name="computer.serialnumber"/> <property component="kanaha" name="computer.type"/> </resource> </server> </datacenter> 10_Cloud_Global_Networksettings.xml Note: The XML file is part of the Tivoli Service Automation Manager product and may by used only by the licensee of the product for the configuration of the program. The product license IPLA applies accordingly. <?xml version="1.0" encoding="utf-8"?><!doctype datacenter PUBLIC "-//Think Dynamics//DTD XML Import//EN" "xmlimport.dtd"> <!-- ****************************************************************** * Licensed Materials - Property of IBM * IBM Product Name (program number 5724-W78) * (C) Copyright IBM Corp All Rights Reserved. * * US Government Users Restricted Rights * Use, duplication or disclosure restricted by GSA ADP Schedule * Contract with IBM Corp. * * DISCLAIMER OF WARRANTIES : * * Permission is granted to copy and modify this Sample code, and to * distribute modified versions provided that both the copyright * notice,- and this permission notice and warranty disclaimer appear * in all copies * and modified versions. * * THIS SAMPLE CODE IS LICENSED TO YOU AS-IS. * IBM AND ITS SUPPLIERS AND LICENSORS DISCLAIM ALL WARRANTIES, EITHER EXPRESS OR * IMPLIED, IN SUCH SAMPLE CODE, INCLUDING THE WARRANTY OF NON-INFRINGEMENT AND THE * IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. IN NO * EVENT WILL IBM OR ITS LICENSORS OR SUPPLIERS BE LIABLE FOR ANY DAMAGES ARISING * OUT * OF THE USE OF OR INABILITY TO USE THE SAMPLE CODE, DISTRIBUTION OF THE SAMPLE * CODE, OR COMBINATION OF THE SAMPLE CODE WITH ANY OTHER CODE. IN NO EVENT SHALL * IBM OR ITS LICENSORS AND SUPPLIERS BE LIABLE FOR ANY LOST REVENUE, LOST PROFITS * OR DATA, OR FOR DIRECT, INDIRECT, SPECIAL, CONSEQUENTIAL,INCIDENTAL OR PUNITIVE * DAMAGES, HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY,-, EVEN IF * IBM OR ITS LICENSORS OR SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH * DAMAGES. ****************************************************************** --> <datacenter> <!-- data center network infrastructure template for TSAM For details on how to define DCM objects with XML files see TPM documentation--> <!-- Define all involved subnets in the following section --> 26 Linux on System z: Provisioning scenarios with IBM Tivoli Service Automation Manager 7.2.2

39 <!-- Name is what you want to use to define the subnet --> <!-- IP address is your subnet range of IP addresses to deploy --> <!-- Netmask is the IP subnet mask address --> <!-- Gateway value is your default route --> <!-- This DCM object defines the subnet used for the Management VLAN --> <subnetwork name="management Network" ipaddress=" " netmask=" "> <blocked-range from=" " to=" "/> <blocked-range from=" " to=" "/> <blocked-range from=" " to=" "/> <blocked-range from=" " to=" "/> <blocked-range from=" " to=" "/> <blocked-range from=" " to=" "/> <!-- Required Parameter. Has always to be set to true --> <property component="kanaha" name="pmrdp.net.cloud" value="true"/> <!-- Defines the Gateway for this subnet --> <property component="kanaha" name="pmrdp.net.gateway" value=" "/> <!-- Defines the broad cast address for this subnet --> <property component="kanaha" name="pmrdp.net.broadcast" value=" "/> <!-- Defines a single Default route for this subnet. The following 3 parameters have to be set to define a default route. --> <!-- Defines the destination ip address of the default route for this subnet --> <property component="kanaha" name="pmrdp.net.defaultroute.destination" value=" "/> <!-- Defines the netmask of the default route for this subnet --> <property component="kanaha" name="pmrdp.net.defaultroute.netmask" value=" "/> <!-- Defines the metric value (priority) of the default route for this subnet --> <property component="kanaha" name="pmrdp.net.defaultroute.metric" value="2"/> <!-- Defines the domain name of the hostname for the provisioned virtual machine for this subnet --> <property component="kanaha" name="pmrdp.net.domainname" value="perf.pok.ibm.com"/> <!-- Defines the hostname prefix for the provisioned virtual machine for this subnet --> <property component="kanaha" name="pmrdp.net.hostnameprefix" value="cld"/> <!-- references to the virtual switch templates. Multiple of these references must be set if this subnet is used with multiple hypervisors. --> <!-- Defines the Virtual switch DCM Name reference for System z for this subnet. The DCM name must exist in the currrent DCM configuration. --> <property component="kanaha" name="pmrdp.net.systemz.switchtemplate" value="systemz_switchtemplate1"/> </subnetwork> </datacenter>< 13_Cloud_Networksettings_zVM.xml Note: The XML file is part of the Tivoli Service Automation Manager product and may by used only by the licensee of the product for the configuration of the program. The product license IPLA applies accordingly. <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE datacenter PUBLIC "-//Think Dynamics//DTD XML Import//EN" "xmlimport.dtd"> <!-- ****************************************************************** * Licensed Materials - Property of IBM * IBM Product Name (program number 5724-W78) * (C) Copyright IBM Corp All Rights Reserved. * * US Government Users Restricted Rights * Use, duplication or disclosure restricted by GSA ADP Schedule * Contract with IBM Corp. * * DISCLAIMER OF WARRANTIES : * * Permission is granted to copy and modify this Sample code, and to * distribute modified versions provided that both the copyright * notice,- and this permission notice and warranty disclaimer appear * in all copies * and modified versions. * * THIS SAMPLE CODE IS LICENSED TO YOU AS-IS. * IBM AND ITS SUPPLIERS AND LICENSORS DISCLAIM ALL WARRANTIES, EITHER EXPRESS OR Appendix. XML DCM import files used in the project 27

40 * IMPLIED, IN SUCH SAMPLE CODE, INCLUDING THE WARRANTY OF NON-INFRINGEMENT AND THE * IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. IN NO * EVENT WILL IBM OR ITS LICENSORS OR SUPPLIERS BE LIABLE FOR ANY DAMAGES ARISING * OUT * OF THE USE OF OR INABILITY TO USE THE SAMPLE CODE, DISTRIBUTION OF THE SAMPLE * CODE, OR COMBINATION OF THE SAMPLE CODE WITH ANY OTHER CODE. IN NO EVENT SHALL * IBM OR ITS LICENSORS AND SUPPLIERS BE LIABLE FOR ANY LOST REVENUE, LOST PROFITS * OR DATA, OR FOR DIRECT, INDIRECT, SPECIAL, CONSEQUENTIAL,INCIDENTAL OR PUNITIVE * DAMAGES, HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY,-, EVEN IF * IBM OR ITS LICENSORS OR SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH * DAMAGES. ****************************************************************** --> <datacenter> <!--data center network infrastructure template for TSAM For details on how to define DCM objects with XML files see TPM documentation--> <!-- Define all involved virtual switch templates in the following section --> <switch name="systemz_switchtemplate1" locale="en_us" failed="false" number-of-ports="10"> <!-- Required Parameter. Has always to be set to true --> <property component="kanaha" name="pmrdp.net.cloud" value="true"/> <!-- Required Parameter. Has always to be set to Virtual Switch Template --> <property component="kanaha" name="pmrdp.net.switchtype" value="virtual Switch Template"/> <!-- reference to existing z/vm virtual switch --> <property component="kanaha" name="pmrdp.net.vswitchname" value="testsw4"/> <!-- Property which defines the port device number --> <property component="kanaha" name="pmrdp.net.zvm_networkportdevicenumber" value="6400"/> <!-- Property which defines the port device range --> <property component="kanaha" name="pmrdp.net.zvm_networkdevicerange" value="3"/> </switch> </datacenter> 23_0_Cloud_Bootserver_zVM.xml Note: The XML file is part of the Tivoli Service Automation Manager product and may by used only by the licensee of the product for the configuration of the program. The product license IPLA applies accordingly. <?xml version="1.0" encoding="utf-8"?&> <!DOCTYPE datacenter PUBLIC "-//Think Dynamics//DTD XML Import//EN" "xmlimport.dtd"&> <!-- ****************************************************************** * Licensed Materials - Property of IBM * IBM Product Name (program number 5724-W78) * (C) Copyright IBM Corp All Rights Reserved. * * US Government Users Restricted Rights * Use, duplication or disclosure restricted by GSA ADP Schedule * Contract with IBM Corp. * * DISCLAIMER OF WARRANTIES : * * Permission is granted to copy and modify this Sample code, and to * distribute modified versions provided that both the copyright * notice,- and this permission notice and warranty disclaimer appear * in all copies * and modified versions. * * THIS SAMPLE CODE IS LICENSED TO YOU AS-IS. * IBM AND ITS SUPPLIERS AND LICENSORS DISCLAIM ALL WARRANTIES, EITHER EXPRESS OR * IMPLIED, IN SUCH SAMPLE CODE, INCLUDING THE WARRANTY OF NON-INFRINGEMENT AND THE * IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. IN NO * EVENT WILL IBM OR ITS LICENSORS OR SUPPLIERS BE LIABLE FOR ANY DAMAGES ARISING * OUT * OF THE USE OF OR INABILITY TO USE THE SAMPLE CODE, DISTRIBUTION OF THE SAMPLE * CODE, OR COMBINATION OF THE SAMPLE CODE WITH ANY OTHER CODE. IN NO EVENT SHALL * IBM OR ITS LICENSORS AND SUPPLIERS BE LIABLE FOR ANY LOST REVENUE, LOST PROFITS 28 Linux on System z: Provisioning scenarios with IBM Tivoli Service Automation Manager 7.2.2

41 * OR DATA, OR FOR DIRECT, INDIRECT, SPECIAL, CONSEQUENTIAL,INCIDENTAL OR PUNITIVE * DAMAGES, HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY,-, EVEN IF * IBM OR ITS LICENSORS OR SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH * DAMAGES. ****************************************************************** --> <datacenter&> <!-- data center boot server infrastructure template for TSAM --> <!-- Define all involved boot servers in the following section --> <!-- Boot Server Name is the description field --> <!-- Host Platform "value" is the name of the MAP ID --> <boot-server name="mapsrv-bootserver" locale="en_us" is-device-model="zvm_bootserver" type="zvm" failed="false"> <property component="kanaha" name="hostplatform" value="mapsrv"/> </boot-server&> </datacenter&>< 23_1_Cloud_zLinuxImage_zVM.xml Note: The XML file is part of the Tivoli Service Automation Manager product and may by used only by the licensee of the product for the configuration of the program. The product license IPLA applies accordingly. <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE datacenter PUBLIC "-//Think Dynamics//DTD XML Import//EN" "xmlimport.dtd"> <!-- ****************************************************************** * Licensed Materials - Property of IBM * IBM Product Name (program number 5724-W78) * (C) Copyright IBM Corp All Rights Reserved. * * US Government Users Restricted Rights * Use, duplication or disclosure restricted by GSA ADP Schedule * Contract with IBM Corp. * * DISCLAIMER OF WARRANTIES : * * Permission is granted to copy and modify this Sample code, and to * distribute modified versions provided that both the copyright * notice,- and this permission notice and warranty disclaimer appear * in all copies * and modified versions. * * THIS SAMPLE CODE IS LICENSED TO YOU AS-IS. * IBM AND ITS SUPPLIERS AND LICENSORS DISCLAIM ALL WARRANTIES, EITHER EXPRESS OR * IMPLIED, IN SUCH SAMPLE CODE, INCLUDING THE WARRANTY OF NON-INFRINGEMENT AND THE * IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. IN NO * EVENT WILL IBM OR ITS LICENSORS OR SUPPLIERS BE LIABLE FOR ANY DAMAGES ARISING * OUT * OF THE USE OF OR INABILITY TO USE THE SAMPLE CODE, DISTRIBUTION OF THE SAMPLE * CODE, OR COMBINATION OF THE SAMPLE CODE WITH ANY OTHER CODE. IN NO EVENT SHALL * IBM OR ITS LICENSORS AND SUPPLIERS BE LIABLE FOR ANY LOST REVENUE, LOST PROFITS * OR DATA, OR FOR DIRECT, INDIRECT, SPECIAL, CONSEQUENTIAL,INCIDENTAL OR PUNITIVE * DAMAGES, HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY,-, EVEN IF * IBM OR ITS LICENSORS OR SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH * DAMAGES. ****************************************************************** --> <datacenter> <!-- Define all involved zlinux images --> <!-- software stack is a software module containing software module(s) or images --> <software-stack name="sles10 GM OS for Minidisks" locale="en_us" is-device-model= "Cloud Suse Linux Operating System" vendor="ibm" version="1.0" build-number="1" stack-type="declared"> <!--property component="kanaha" name="soaonramp_vst" value="5464"/--> <property component="kanaha" name="swtype" value="os"/> <software-capability type="os" name="os.family" value="linux"/> <software-capability type="os" name="os.distribution" value="sles10 s390x"/> Appendix. XML DCM import files used in the project 29