Jonathan Gladstone, P.Eng. for CMG Canada – Nov. 20, 2018

Jonathan Gladstone, P.Eng. for CMG Canada – Nov. 20, 2018
Mainframe 101 Parts 1, 2 & 3 What is it, anyway? How will we set it up? How will we pay for it? Jonathan Gladstone, P.Eng. for CMG Canada – Nov. 20, 2018

Copyright © Jonathan Gladstone, 2018
Abstract In the 1960’s and 1970’s, mainframe computing was the dominant paradigm in information processing. Rapid and continuing developments have changed the focus to distributed systems, but mainframes remain an important niche player. When circumstances require very high WRASSS™ (workload reliability, availability, serviceability, security and scalability), mainframes continue to deliver the goods at a competitive TCO per unit of work. But many of our colleagues simply don’t understand the differences in platform architecture, system configuration, or costing. This series of three short presentations should help! Part 1 – What is it, anyway? Part 2 – How will we set it up? Part 3 – How will we pay for it? We assume the audience has some familiarity with IT systems, specifically with the concept of workload-sharing clusters of virtualized distributed systems. CMG Canada: Copyright © Jonathan Gladstone, 2018

Part 1 – What is it, anyway? Agenda What’s the difference between mainframe and distributed systems? How do we choose which to use? What’s more cost-effective? How do mainframes process workloads? Applications, middleware & regions Virtualization & clustering Failover and site backup CMG Canada: Copyright © Jonathan Gladstone, 2018

What’s the difference between mainframe and distributed systems?
Both are ‘general-purpose digital computers’ In theory, you can do anything with any of them… … but you may not always want to! Distributed systems typically run one type of workload in dozens or hundreds of processes. Mainframe systems typically run dozens or hundreds of diverse workloads in many thousands of processes. Advantages of distributed systems Advantages of mainframe systems Further reading: LinkedIn – The Power of One vs the Power of Many: Mainframe vs Distributed DZone – The Mainframe vs the Server Farm: A Comparison Low cost of entry per system image or server Abundant pre-educated staff Relative ease of implementation Lots of outsourcing & cloud options So how do you choose? Play to strengths! For very high WRASSS™ or RPO=0 or heavy OLTP workloads, mainframes are cost-competitive or even less expensive than distributed servers. For legacy mainframe workloads with those business requirements, it’s hard to imagine making a business case for expensive, risky conversion. Extreme scalability within a system image Excellent at workload sharing & OLTP Very mature WRASSS™ & DR capabilities Excellent mixing of CPU- & IO-intensive work CMG Canada: Copyright © Jonathan Gladstone, 2018

How do mainframes process workloads? (1 of 2)
front end middleware dbms DISTRIBUTED front end middleware dbms MAINFRAME Applications, middleware & regions Three-layer design: ‘front end’ (GUI or WUI), a ‘middle’ (queue managers, transaction managers, workload distributors) and a ‘back end’ (database managers) – regardless of system architecture Separate images in distributed systems Together in mainframe Reduced passing & latency in mainframe architecture Virtualization Many VM’s can share a single physical ‘footprint’ – regardless of system architecture In distributed systems, we’ll typically have a VM for each layer In mainframes, each VM might run different applications front end middleware dbms DISTRIBUTED front end middleware dbms MAINFRAME CMG Canada: Copyright © Jonathan Gladstone, 2018

How do mainframes process workloads? (2 of 2)
DISTRIBUTED CF MAINFRAME Clustering We can build groups of VM’s across multiple ‘footprints’ – regardless of architecture In distributed, we have to connect each VM to each other one, and add load distributors & lock managers (not shown here) In mainframe, load distribution can be done within and among VM’s and footprints, and we connect each VM to a Coupling Facility for lock management Failover and site backup We can connect groups of footprints across sites – regardless of architecture In distributed, we have to set up external controls to manage transition In mainframe, those tools are built in (though not simple to configure) CMG Canada: Copyright © Jonathan Gladstone, 2018

Part 2 – How will we set it up?
Agenda Configuring for WRASSS™ Segregated Sites: Production, Dev/Test/QA Normal, local failover, site recovery Combined Sites: Active/Active What about “third sites”? How do we choose which to use? What’s more cost-effective? What works for our applications? What satisfies our business requirements? Remember, WRASSS™ = Workload Reliability, Availability, Serviceability, Security & Scalability. If you think of ‘scalability’ as ‘expandability’, it’s a fish! CMG Canada: Copyright © Jonathan Gladstone, 2018

Configuring for WRASSS™: Segregated Sites: Production, Dev/Test/QA
CMG Canada: Copyright © Jonathan Gladstone, 2018

Configuring for WRASSS™: Segregated Sites: Production, Dev/Test/QA
This doesn’t show any capability for site fallback for Dev/Test/QA, but it could be built. Expense is primarily for extra storage. CMG Canada: Copyright © Jonathan Gladstone, 2018

Configuring for WRASSS™: Combined Sites: Active/Active

Third sites & other limitations
Metro mirror can only handle sites ≤100km apart Metro mirror can only handle two sites for RPO=0 fallback That leaves two ways that more than two sites can be used Third site for data only RPO>0, but distance not limited Works for all sysplexes simultaneously Can be used for Dev/Test/QA as well as for Production Multiple sites with two sites per sysplex RPO=0, distance limited to 100km Fully active/active, but each plex only in two sites CMG Canada: Copyright © Jonathan Gladstone, 2018

How do we choose? Segregated Sites Active/Active Takes less capacity overall Lower costs for hardware, software Less complex implementation Doesn’t require as much cross-site planning More accessible for legacy applications Doesn’t require all code to handle site-to-site data transfer Requires delay for site fallback Service impact is full Production outage for at least a few hours Site fallback capacity only for one direction at a time Build for Production and Dev/Test/QA separately Takes more capacity overall Higher costs for hardware, software More complex implementation Requires cross-site planning for all eventualities Less accessible for legacy applications May require significant code changes to handle site-to-site data transfer No delay for site fallback Only service impact is loss of in-flight transactions Site fallback capacity for both Production and Dev/Test/QA Inherent to active/active, but can be designed for only Production Both can provide RPO=0 and usual mainframe WRASSS™ (except for site fallback). CMG Canada: Copyright © Jonathan Gladstone, 2018

Part 3 – How will we pay for it?
Agenda External cost – a moving target! IBM – hardware and software MLC vs OTC Parallel Sysplex, Countrywide Multiplex pricing Advanced Workload, New Application pricing Container pricing Other vendor software Cross-charging – charge-back, show-back and shame-back What’s effective? What makes business sense? Price per unit of revenue Price per unit of capacity (by demand during peak) Price per unit of utilization (by resource consumption during a period) CMG Canada: Copyright © Jonathan Gladstone, 2018

First things first You’re going to pay for hardware, and for software Hardware is paid by purchase or lease, to IBM or a VAR Most shops pay more for software… Mainframes are expensive! Think of railways compared to cars (again)1… … so they are almost always a shared resource … and it will be important to optimize cost2. Optimized cost requires good decisions about how to use resources… … and that requires some form of cost transfer Some workloads need ‘special cars’ – like tankers & livestock carriers … and others need to be transferable – like containers3. Cost is driven by peak demand True whether you’re looking at capacity or utilization a lot more a lot more 1 - Railways need a dedicated roadbed, large curve radius, <1% incline… but at large scale, they deliver excellent cost per unit of service. Mainframes, as we’ve discussed, are similar. 2 – Why optimize, not minimize? Remember, we need local failover, data duplication for RPO=0, DR or active/active capability… 3 - ‘Special’ workloads might include things like legacy mainframe code, high-volume OLTP, very large high-security RDB’s… while ‘container’ workloads might include things like web front-ends, queue managers, and anything whose server location doesn’t really matter. CMG Canada: Copyright © Jonathan Gladstone, 2018

Pricing – MLC versus OTC
Once upon a time… the OS was free with the hardware! Not any more! Now we pay for z/OS … and for Db2, CICS, IMS, MQSeries, WebSphere Most of these are paid for as a monthly licence – that’s MLC1, most simply based on the enabled capacity of each CEC2 (physical server) Typically includes maintenance, but not version or hardware upgrades And we pay for monitors, performance management software, batch schedulers, application assistance and development software, etc… often by OTC3 Doesn’t usually include maintenance And there are version and hardware upgrade charges again Is this complicated? We’re not even started… 1 – MLC = monthly licence charge 2 – CEC = Central Electronic Complex. Aren’t acronyms fun? 3 – OTC = one-time charge CMG Canada: Copyright © Jonathan Gladstone, 2018

Sub-Capacity License Charges
To reduce cost on MLC products, pay only for utilization PSLC – Parallel Sysplex1 License Charges Pay for peak monthly four-hour rolling average per CEC for OS, and for selected other software (e.g. Db2, CICS, IMS, WebSphere) Only pay for one copy of each, as long as the ‘dominant’ LPAR2 in the CEC belongs to the declared sysplex CMLC – Countrywide Multiplex Licence Charges Like sysplex, but peak monthly four-hour rolling average is computed across as many CEC’s as you like within one ‘geography’3 ‘Dominant’ LPAR rule is waived Multiple version charging is waived4 Pricing based on a three-month sample of previous PSLC usage… so price doesn’t go down, but won’t rise as quickly in a growth scenario Both influenced by “soft caps”5 Complicated enough yet? We’re not done… 1 – A parallel sysplex is a group of systems running in one or more CEC’s, capable of sharing workloads. 2 – Really? You’re an IT professional, and you’re asking this? “Logical PARtition” was invented here… it’s a container of resources in which to run an image of the OS, just like in any other virtualized processing platform. 3 – Usually a country… but this is IBM we’re talking about, so who knows? 4 – In PSLC, when you move from one major release of a given software package (e.g. Db2) to the next, you only have 12 months by default to finish migration, after which you’ll be charged for both versions in as many boxes as both are still running. What, that wasn’t obvious? 5 – If you missed Jonathan’s explanation of this, you’re just going to have to look it up. CMG Canada: Copyright © Jonathan Gladstone, 2018

Special One-Time Charges
There may be more than one of these… AWLC – Advanced Workload License Charges – converts non-MLC product charges to a fixed rate regardless of CEC IWP – Integrated Workload Pricing – adds products to an LPAR without increasing that LPAR’s utilization metrics for pricing MWP – Mobile Workload Pricing – reduces cost of growth for transactions originating from a mobile source zCAP – Collocated Application Pricing1 – reduces cost of base programs in support of applications migrating in from another platform zWPC – Workload Pricing for Cloud2 – reduces cost for public cloud transactions zNALC3 – New Application License Charges – reduces the cost of z/OS in systems that run “qualified applications”4 Container pricing – solutions are priced based on “business value” 5, with no direct impact on costs of other, unrelated mainframe workloads There’s a growing herd of these too… NAS, ADTS, SCLC6… 1 – Ignore the ‘z’ – it just means ‘mainframe’ in IBM-ese. 2 – Yup. Ignore the ‘z’ again. 3 – Hey, you figured it out! 4 – Those would be ones that IBM wants to attract to the platform 5 – That is to say, agreed price by negotiation. 6 – New Application Solution, Application Development & Test Solution, and Solution Consumption License Charges… of course! CMG Canada: Copyright © Jonathan Gladstone, 2018

Other Vendor Software Usually OTC… but sometimes MLC too Most vendors don’t honour soft caps, but some will It’s complicated! To get the best value, you need an expert team to manage all of this carefully, as a single contiguous platform … which means shared billing. CMG Canada: Copyright © Jonathan Gladstone, 2018

Shared Billing Charge-back, show-back, shame-back… doesn’t matter which What’s effective? What makes business sense in your enterprise? Price per business metric Sum up the lot and charge it out proportionally to LoB revenue, profit, user count, head count, etc. Price per unit of capacity (by demand during peak) Charge out by MIPS1 usage during peak hour But is this fair? Don’t heavy overnight batch users get off easy? Price per unit of utilization (by resource consumption during a period) Charge out by standard CPU-hours2 of utilization each month But is this fair? Don’t heavy peak-time users get off easy? OK, so there’s no single right answer… Differential charges for non-peak hours, or days of the week Differential charges by workload priority Etc. 1 – Originally “Millions of Instructions Per Second” (so singular is 1 MIPS); now “Meaningless Indicator of Processor Speed” (still 1 MIPS). 2 – Usually based on comparisons of IBM processor ratings to some long-defunct mainframe processor type, so as to eliminate differential charges for use of different configurations or generations of processor. CMG Canada: Copyright © Jonathan Gladstone, 2018

Wrap-up? What Wrap-up? Got any Questions?

About the Author Jonathan Gladstone, P.Eng., is a senior information systems professional, educator, planner and team leader with over thirty years of applied experience in IT, focused on capacity management, business continuity management, ITIL process management, development & implementation, and project initiation for large corporate I/T infrastructures. He currently works full-time for the Bank of Montreal as mainframe and midrange systems capacity planner, and teaches a variety of certificate- and diploma-track courses in Computer Studies at Georgian College in Barrie, ON. He also swings a sword for fun. He has been at the BMO Financial Group for over 20 years, and working in capacity planning for much of that time. He is BMO’s representative on the Advisory Committee for the School of Computer Studies at Georgian College in Barrie, ON, where he also teaches part-time. Jonathan holds a B.A.Sc. degree in Electrical Engineering from the University of Toronto and P.Eng. certification from Professional Engineers Ontario and is certified in ITIL v2 and v3 fundamentals. Jonathan has made many IT presentations over the years, including at CMG Canada, CMG Mid-west and CMG International. You can find him online at LinkedIn, on or at his occasional blog, CMG Canada: Copyright © Jonathan Gladstone, 2018

Jonathan Gladstone, P.Eng. for CMG Canada – Nov. 20, 2018

Similar presentations

Presentation on theme: "Jonathan Gladstone, P.Eng. for CMG Canada – Nov. 20, 2018"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Jonathan Gladstone, P.Eng. for CMG Canada – Nov. 20, 2018

Similar presentations

Presentation on theme: "Jonathan Gladstone, P.Eng. for CMG Canada – Nov. 20, 2018"— Presentation transcript:

Similar presentations

About project

Feedback