1 / 66

Virtualization in the Real World A customer experience Session 9214 Speaker: Mike Reeves

Virtualization in the Real World A customer experience Session 9214 Speaker: Mike Reeves mike.reeves@fmr.com. Virtualization in the Real World A customer experience. Virtualization in the Real World. zSeries & s/390 Linux. The zSeries Linux Implementation Formula

titus
Download Presentation

Virtualization in the Real World A customer experience Session 9214 Speaker: Mike Reeves

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Virtualization in the Real World A customer experience Session 9214 Speaker: Mike Reeves mike.reeves@fmr.com 1

  2. Virtualization in the Real World A customer experience Virtualization in the Real World 2

  3. zSeries & s/390 Linux The zSeries Linux Implementation Formula Unix versus z/VM & Linux Infrastructure Reduction Grid on zSeries Support Model Practical Examples TCO Model Workload management 3

  4. zSeries & s/390 Linux The zSeries Linux Implementation Formula ((((RIT * PT)NITP)M2)V3)NTW ISVPTABNYD PIT= PIT RIT PT NITP M V NTW ISVP TABNYD - Project Implementation Time - Real Implementation Time - Project Time - Needlessly Involved Technical People - Managers - Vice Presidents - Number of Turf Wars - ISV Products - Talked About But Not Yet Delivered 4

  5. Unix versus z/VM & Linux

  6. Typical Open environment Linux on z/VM Network z/OS Cable Cable Cable Cable Virtual Cables App App App App App App UNIX AIX Win.. Linux Linux Linux Server Server Server z/VM processors, memory, channels... Shared Disks Unix versus z/VM & Linux Discrete compared to virtualized with z/VM IEEE VLAN 6

  7. Workload Management Manageability of the Virtual Environment Virtual Consoles Single Console Image Facility PROP(CA) or VM/Oper (CA) Performance Toolkit Standard VM monitor data MICS and/or Merrill’s MXG Integrate with z/OS data RMF LPAR reporting RMF for Linux Virtual Console SCIF CMS CMS Linux VM OPER (REXX) Linux Perf. Toolkit Linux Linux CP Hypervisor operations CP Monitor Monitor Data z/VM 7

  8. Application Application Middleware Middleware Linux OS Linux OS Application Application Application Application Middleware Middleware Middleware Middleware Linux OS Linux OS Linux OS Linux OS Unix versus z/VM & Linux On Demand is there today!! Dynamic addition of resources is possible for certain resources and is expanding rapidly in the zSeries infrastructure. zSeries Hardware z/VM Virtualization layer Automation Management zSeries Hardware layer 8

  9. z/OS Network Blade Frame Blade Frame Cable Cable Virtual Cables Virtual Cables App App App App App App Linux Win.. Linux Win.. Linux Win.. VMWare cpu-mem-I/O VMWare cpu-mem-I/O VMWare cpu-mem-I/O Unix versus z/VM & Linux Discrete compared to virtualized with VMWare Typical Open environment Windows & Linux on VMWare Cable Cable Cable App App App UNIX AIX Win.. Server Server Server 9

  10. zSeries z/VM Virtualization layer zSeries Hardware layer Unix versus z/VM & Linux What are some differences? Instruction based Virtualization End-to-End Error Recovery Workload Management Dynamic pathing to Disk Hipersockets between LPARs On Demand Infrastructure Simplified Administration, Monitoring and Automation Infrastructure simplification Shared Segments & Disk Sharing Maintenance and Upkeep Virtualization with 3 decades of IBM software and hardware experience behind it. 10

  11. Unix versus z/VM & Linux Virtualization Considerations for Mainframe Users 11

  12. Intranet Internet Infrastructure Reduction Typical Server Environment – What are the Problems? What is Missing? Web Server Web Server Web Server Firewall Firewall Database Server Database Server eMail Server Database Server eMail Server Application Server Firewall Application Server Firewall Application Server Backup Server Security Server Backup Server Security Server 12

  13. Infrastructure Reduction What are the problems with the distributed Infrastructure? • Something will always be broken or malfunctioning • Something in this infrastructure needs upgrade • Hardware/software upgrade • Upgrade (technology exchange) is very disruptive • No provision for dynamic upgrades • The majority of this infrastructure will be underutilized • But when processing spikes occur, there will always be a bottleneck somewhere • Unknown SPOFs • End-to-End management is difficult to impossible • Monitoring Management & control does not span silos • Administration is difficult and requires to many levels of interaction to solve problems • No real way to achieve significant infrastructure & administrative cost reduction • Automation is difficult so autonomic computing and Disaster Recover are nearly impossible to achieve 13

  14. Internet Infrastructure Reduction What’s Missing?  Support Infrastructure! Web Server Web Server Web Server Firewall Firewall Database Server Database Server Database Server eMail Server eMail Server Application Server Firewall Application Server Firewall Intranet Application Server Security Server Backup Server Security Server Backup Server This configuration contains 50+ levels of infrastructure 14

  15. Internet z9xx z/VM-a z/OS-a Tape mgt File server MQSeries CICS Backup server DB2 Application server DB2 Connect tape File server MQSeries Backup server Tape mgt Application server CICS DB2 Connect DB2 z/OS-b z9xx z/VM-b Infrastructure Reduction Reduce Infrastructure with Linux on zSeries Web Server Web Server Web Server Firewall Firewall Database Server Database Server Database Server eMail Server eMail Server Application Server Firewall Application Server Firewall Intranet Application Server Security Server Backup Server Security Server Backup Server In this configuration, 14+ levels of infrastructure have been eliminated 15

  16. Infrastructure Reduction Consolidation on zSeries – What are the Benefits? • Virtualization simplifies the infrastructure • Common software provides for simpler upgrades and hardware can be transparently upgraded • Administration and management simplified • Real cost savings can be achieved because levels are moved from real to virtual • Resources can be better utilized • On Demand dynamic addition of resources • Better automation, autonomic computing • Disaster recovery actually possible 16

  17. Grid on zSeries • JES2 MAS • Jobs processed where resources are available • CICS MRO • Function shipping throughout sysplex based on available resources • Transactions routed based on available resources or transaction affinity • DB2 Data Sharing • Data-sharing allows any CICS region to access data as though it were local • VSAM Record Level Sharing • Allows access to VSAM from individual regions across a sysplex rather than from file owning regions • On Demand resource addition Workload Manager Java Java DB2 CICS CICS CICS CICS CICS CICS CICS CICS CICS CICS CICS CICS Network VSAM Java Java Java Parallel Sysplex 17

  18. WebSphere – A Grid? Grid on zSeries Work Load Manager • Sysplex Websphere grid • Servers dynamically added & quiesced • Resources balanced across sysplex • WebSphere Application Server • Can take advantage of z/OS security, crypto and zAAP features • Work Load Manager • Dynamic Management of WAS application servers • Work loads prioritized and balanced • Running hardware at 100% with heterogeneous workloads • On Demand resource addition • Activate standard processors, zAAPs, IFLs and Memory dynamically • Deactivate resources dynamically Servelet Network Java EJB Parallel Sysplex 18

  19. DB2 Data Sharing – A Grid? CICS CICS CICS CICS CICS CICS CICS CICS Grid on zSeries Workload Manager • WebSphere & CICS • CICS Web Server • J2EE, Java transactions • Business transformation logic • DB2 Data Sharing • Enterprise Java Beans • Stored Procedures • DB2 Connect • VSAM Record Level Sharing • Sysplex wide sharing of VSAM files • Web enabled VSAM connectors • On Demand resource addition • Add resources manually or automatically • Scale up and/or out Java Java DB2 Network VSAM Java Java Parallel Sysplex 19

  20. Grid on zSeries Data Grid Exploitation with zSeries Hosting Environment We could this, but our applications groups would have to recode all of our applications to fit this model. Eventually this will happen, but not in the short term. Grid Service Container User-Defined Services Base Services System-Level Services OGSI Spec Implementation Security Infrastructure Web Service Engine Open Grid Services Architecture Gatekeeper Job Manager Resource Manager Client Security Infrastructure Resource Library Process Process Process Security admin. RSL admin. Process 20

  21. Grid on zSeries DB2 Conn Guest 1 Data Grid Exploitation with zSeries Linux & DB2 Connect DB2 Conn Guest 2 hipersockets z/OS 1 Compute environment taking advantage of zSeries data grid to provide a high speed connection to DB2 data on the zSeries sysplex. Low network latency & high data rates can be achieved with hipersockets. Example of this configuration in “Practical Example”. z/VM 1 DB2/DS DB2 Conn Guest 3 OSA/X DB2/DS DB2 Conn Guest ..n DB2/DS sysplex Compute Intensive Processing DB2 Conn Guest 1 DB2 Conn Guest 2 hipersockets DB2/DS z/OS 2 z/VM 2 DB2 Conn Guest 3 DB2/DS OSA/X DB2/DS DB2 Conn Guest ..n 21

  22. Support Model How we do zSeries Linux installation & support Test/Dev/QA – Mainframe z/OS Support Middleware & DBMS Support Java DB DB WAS WAS WAS MQ DB Production – UNIX Technical Support z/VM & Virtual Guests OS support with IBM for level1 & 2 – level 3 support with RedHat. Mainframe Hardware & Storage Management zSeries Hardware 22

  23. YOUR New Linux Support Model Server Creation Server Creation Servers can be provisioned through “Server Central”. Once the request is received it takes about ½ hour to create the server and in many cases the server can be completely provisioned in less than one day. Test/Dev/QA supported by z/OS support group. Production supported by UNIX Technical Support group. Middleware & DBMS supported by Open Systems DBMS support. Linux MQSeries Linux DB2 Conn Linux WAS 5 z/VM (ZVMx) LPAR1 LPAR2 z/OS (CPUx) 23

  24. Support Model Dev – Test – QA zSeries – Test/QA Intranet Linux mail Linux Java Linux c++/ftp Linux MQSeries Linux DB2 Conn Linux WAS 5 z/VM TestPlex QA Plex z/OS 24

  25. Support Model Production zOS/zVM Other Plexes zSeries – Prod zOS/zVM Linux mail Linux Java Linux c++/ftp Linux MQSeries Linux DB2 Conn Linux WAS 5 Site 1 z/VM zOS/zVM Intranet Site 2 zOS/zVM z/OS Other Plexes 25

  26. Practical Examples DB2 Connect • AIX Servers in a High Availability multi-site configuration resulting in unused capacity • Maintenance difficult to schedule because all connects share the same DB2 binaries • Multiple network hops increase latency resulting in higher response times • Memory configuration limited to total memory available on hardware Old Configuration Site 1 z/OS 1 DBMS AIX C1 C2 C3 DBMS DBMS DBMS Site Dist. IP Dist. z/OS 2 DBMS Site 2 DBMS AIX C1 C2 C3 DBMS DBMS 26

  27. z/OS 1 z/OS 2 DBMS DBMS DBMS DBMS DBMS DBMS DBMS DBMS Practical Examples DB2 Connect • Shares hardware in a continuous availability configuration • Maintenance can be easily scheduled because each instance has its own DB2 binaries • One network hop reduces network latency to near zero • Memory can be customized for each server guest New Configuration z/VM 1 IP Dist. z/VM 2 27

  28. Practical Examples WAS 5.1.0 applications CSC Hostbridge & EOS • High availability configuration • Mainframe centric applications with low utilization. • One network hop reduces network latency to near zero (except in failover) • Both Hostbridge and EOS are running on a single guest to leverage server costs. 28

  29. Practical Examples DB2 Connect/Java • High availability configuration • Maintenance can be easily scheduled because each instance has its own DB2 binaries • One network hop reduces network latency to near zero (except in failover) • Low utilization server allows for consolidation, simplification and low network latency z/VM 1 z/OS 1 DBMS Dallas IP Dist. High Availability Failover z/VM 1 z/OS 1 DBMS Merrimack 29

  30. EE GW CIP CIP CIP DLSw DLSw Practical Examples SNA Elimination – Current Environment SNA environments will be around for some time and have evolved to become a complex infrastructure. SNA over IP requires many levels of infrastructure. DLSw and EE gateway technologies are not always compatible and when a problem occurs, diagnosis is very difficult. Channel Attached CIP Routers SNA SNA Apps Load Balancing SNA App z/OS EE TN3270 OSA/e z9xx SNA TCP/IP SNA TCP/IP z9xx WAN 37xx SNA Apps 37xx 37xx Data Center Remote 37xx 30

  31. TCP/IP Practical Examples SNA Elimination – Future Environment zSeries Linux Communications Server, Communications Controller, and SSL server provide the ability to collapse the SNA infrastructure back into the mainframe platform eliminating the need for distributed SNA appliance technology which is reaching end-of-life status over the next 12-24 months. SNA Apps SNA App SNA TN3270 CSCC z/OS OSA/e Remote Data Center SNA Apps 31

  32. TCO versus TCA! “We project that improving UNIX/Intel workload management will drive average utilization rates from the 15% to 20% to 40% to 50% within three years. When the significant Intel/zSeries annual price/performance improvement gap is overlaid on these projections, it becomes clear that any business case for mainframe Linux will evaporate by 2005/06, in the face of the Linux on Intel juggernaut.” (Meta Group, “Mainframe Linux Server Consolidation: The Near-Term Business Case”, Delta 2107 Mar 03) 32

  33. TCO versus TCA! “Action Item: Investigate all options to consolidate. Closely evaluate the migration costs, all assumptions (including staffing efficiency and over-provisioning for peak workloads), availability requirements and alternative mechanisms for reducing TCO. Those who dismissed Linux on the zSeries two years ago may wish to revisit it because IBM has made progress.” (Gartner, “The IBM Mainframe: 40 Years, Now What?”, 30 November – 2 December 2004) 33

  34. TCO versus TCA! • Long Term costs versus initial cost! • How long before hardware push-pull is required? • Total Infrastructure costs versus server hardware cost!! • How much infrastructure resources does the server require? • How much capacity will go unused? • Low utilization equals poor ROI • Utilization only during certain time frames • Downtime does have a cost! • Server outages should include appropriate resolution costs • Business outages do cost real dollars • Ongoing maintenance, monitoring and capacity planning costs real dollars! • What real networking, monitoring, admin & capacity planning costs are visible to the project? 34

  35. TCO versus TCA! • Benchmarks are not real workloads!! • Benchmarks don’t represent real production workloads • One-to-One hardware comparisons don’t work!! • Single application hardware comparison: ex. blade-IFL $$$ • Sharing not considered as part of the model!! • Workload sharing is become a necessity in all environments • 24X7 utilization • Downtime not considered as part of the model!! • Outages should include appropriate resolution costs • Infrastructure reduction not considered!! • Networking, monitoring, admin & capacity planning cost $$$ • On Demand versus excess capacity is a reality on zSeries! • Add and remove resources dynamically • No unused infrastructure for capacity is required 35

  36. Actual Implementation zSeries 10% 2 IFL zSeries 10% 2 IFL Intel 10% 3 Ghz Intel 10% 3 Ghz Intel 10% 3 Ghz Intel 10% 3 Ghz Intel test Intel qa Shared resources zSeries Test zSeries qa TCO versus TCA! One-to-One Comparisons are Misleading Cost Comparison The comparison is done on one box but the deployment is implemented in the standard high availability configuration which is much more costly. zSeries 20% 2 IFL Intel 40% 3 Ghz 36

  37. TCO versus TCA! What are the Opportunities So far all of the testing has focused on “Primary Shift” projects. This only takes advantage of a window of resources available on zSeries Linux. This leaves more than 60% of the resources available for other application deployments. WAS Oracle UDB Java/DB2 Connect Web Portal 8:00 5:00 5:00 8:00 Great area of opportunity lies between end and start of primary shift Offshore development Extracts and reporting Other exploitation of unused timeframe 37

  38. zSeries is designed for sharing so scaling can be accomplished both vertically and horizontally Web Server App Server DBMS Server Web Server App Server DBMS Server z9xx z/VM-a z/OS-a Web Server App Server DBMS Server App Server MQSeries DBMS Server MQSeries App Server CICS DBMS Server App Server CICS DBMS Server Database Server Web Server Report Extract Database Server Report Extract Report Extract Database Server Web Server Report Extract Database Server Report Extract tape Web Server Report Extract Database Server TCO versus TCA! Prime Shift Applications Non-Prime Hours Applications 38

  39. Test Test Production Production Linux Java Linux Java Linux WAS 5 Linux WAS 5 Linux WAS 5 Linux DB2 Conn Linux WAS 5 Linux WAS 5 Linux DB2 Conn Linux DB2 Conn Linux WAS 5 Linux DB2 Conn Linux WAS 5 Linux WAS 5 TCO versus TCA! Heterogeneous workloads can reduce costs Use the workload management capability of z/VM to allow production peaks to utilize the test & development resources. • Provision Test/Dev • Build as many test/development guests as you can to fill unused resources • Set the priority of the test/dev guests low • Provision Production • Build production guests with the intent of satisfying peaks by stealing resources from test/dev • Set the priority of the production guests high • Configure the LPAR with sufficient resources to run both z/VM z/OS 39

  40. Network Cable OLD Cable NEW App App s/w s/w UNIX UNIX h/w h/w Server Server disk disk TCO versus TCA! The Boundless Proliferation loop! Current Unix Life Cycle Strategy • Provision server • Floor space, Power & Hardware • OS, Network & Middleware • Test the configuration • Install the application • QA the configuration • Run parallel to validate the application • Cutover to production • Decommission the old server

  41. Network Cable Cable Virtual Cables Virtual Cables App App App App App App Linux Linux Linux Linux Linux Linux z/VM processors, memory, channels... Shared Disks Shared Disks NEW z/VM processors, memory, channels... TCO versus TCA! Ending the loop with zSeries Linux! zSeries Linux Life Cycle Strategy OLD

  42. TCO versus TCA! What works in zSeries Linux! 42

  43. TCO versus TCA! How do you decide what works? 43

  44. Workload Management Manageability of the Virtual Environment Virtual Consoles Single Console Image Facility PROP(CA) or VM/Oper (CA) Performance Toolkit Standard VM monitor data MICS and/or Merrill’s MXG Integrate with z/OS data RMF LPAR reporting RMF for Linux Virtual Console SCIF CMS CMS Linux VM OPER (REXX) Linux Perf. Toolkit Linux Linux CP Hypervisor operations CP Monitor Monitor Data z/VM 44

  45. z/VM #1 z900 zSeries hardware z/VM & z/OS Test – 25 Prod – 10 PROD CICS / DBMS Local CPRD CICS / DBMS FMN Linux mail Linux Java Linux c++/ftp Linux MQSeries Linux DB2 Conn Linux WAS 5 z/VM #2 z990 Test – 22 Prod – 12 z/VM (ZVMx) z990 Test – 0 Prod – 2 IFL Disk Memory OSA/X hipersockets CPU Disk Memory QPRD CICS / DBMS z/OS (CPUx) z990 Test – 0 Prod –0 RPRD CICS / DBMS Remote Workload Management 45

  46. Workload Management All z/VM accounting data was pulled for the week of 2005/01/31 and 2005/02/04. Only records between the hours of 09:00 and 17:00 EST were included. The data was summarized for 15 minute intervals. The graph below reflects the average cpu utilization for the week between 09:00 and 17:00 EST normalized to 100%. z/VM #1 Average CPU Usage for 01/31-02/24 z900 46

  47. Workload Management All z/VM accounting data was pulled for the week of 2005/01/31 and 2005/02/04. Only records between the hours of 09:00 and 17:00 EST were included. The data was summarized for 15 minute intervals. The graph below reflects the average server size for production and test as well as the demand paging rate for each. z/VM #1 Average Paging for 01/31-02/24 47

  48. Workload Management All z/VM accounting data was pulled for the week of 2005/01/31 and 2005/02/04. Only records between the hours of 09:00 and 17:00 EST were included. The data was summarized for 15 minute intervals. The graph below reflects the average cpu utilization for the week between 09:00 and 17:00 EST normalized to 100%. z/VM #2 Average CPU Usage for 01/31-02/24 z990 48

  49. Workload Management All z/VM accounting data was pulled for the week of 2005/01/31 and 2005/02/04. Only records between the hours of 09:00 and 17:00 EST were included. The data was summarized for 15 minute intervals. The graph below reflects the average server size for production and test as well as the demand paging rate for each. z/VM #1 Average Paging for 01/31-02/24 49

  50. Workload Management Based on the current usage patterns of the ZVM5 infrastructure the average production utilization is ~.5% and that of test is ~.25%. The chart below shows how that utilization would scale across 8+ CPUs in one or more environments. This would allow for ~.5 hours of CPU utilization for each production guest.** 50

More Related