Ensuring Business Continuity with the IBM Fit For Purpose Methodology

Transcription

1 GUIDE SHARE EUROPE Ensuring Business Continuity with the IBM Fit For Purpose Methodology Yann Kindelberger Senior Architect, Design Center IBM Client Center Montpellier

2 Agenda Workload and platform positioning The Key Fit for Purpose principles The Non Functional Requirements: Business Continuity Customer example IBM PSSC F4P & HACoC workshops offering 2

3 The Fit for Purpose approach help define the right platform matching the client workload requirements Fit for Purpose is a client centric thought process that provides rational platform choices, which are in line with client workloads requirements and local conditions. Scale Throughput HA/DR/Cont.Op. Env. constraints Security Multiple areas to take into account: Local Factors Non Functional Requirements Integration requirement Workload characteristics Overall costs IT Strategy/ Technology Adoption Skills TCO System z Power System x I/O intense Appl. Integration Data Integration Memory usage CPU-bound 3

4 Technology dominant trends show that single core operations are limited Though 2-year cycles between nodes will continue, beyond 22 nm new technology nodes, but the historic 35%-pernode increase & doubling of transistor density may drop to 15-20%. Power density is limiting ability to fully translate the transistor performance gain into systems. A B C Transistor performance scaling to continue, but at a slower rate Power is limiting practical performance Single thread performance is slowing dramatically Relative 4 4

5 But there are also factors affecting workload scaling in multi-core operations Queuing and Contention Cache and Buffer Coherence Core Cache Core Cache Core Cache Core Cache Core Core Core Cache Core Cache Memory Queuing or contention for shared resources such as memory, network, I/O, busses, locks, software structures Cache to cache traffic caused by data sharing or data replication Saturation CPU, I/O and Memory Bandwidth Throughput I/O Memory Cache Core CPU Utilization Cache misses and I/O delays detract from throughput but do not reduce CPU busy time CPU clock speed and code path length; memory, cache, and I/O size, ports and speed 5

6 Research showed that server design could not cope with all the limiting factors: Tradeoffs are mandatory in server design Thread Speed Fitness Proxies: Thread Speed Serial Fitness Thread Count Parallel Fitness Cache/Thread Data Fitness Low High High High Low Low Thread Count Server Design Effective Cache/ Thread 6

7 IBMer J.Temple asserts that IBM Servers are optimized for different parts of Pfister s space and proposed this positioning: Temple s Assertion Parallel Hell Mainframes Fitness for Serial Loads Blades (x, POWER) idataplex BlueGene X3850 and Midrange Power p795 High-end Power p780 p770 p750 Power 755 and x3950 Highly Scaled NUMA Closely Coupled Clusters Parallel Nirvana Parallel Purgatory Fitness for Data Centric Loads 7

8 These workload segments map to technical characteristics Transaction Processing and Database Shared Data & Work Q Type 1 Scales up Updates to shared data and work queues Complex virtualization Business Intelligence with heavy data sharing Analytics and High Performance Parallel Data Structures Type 3 Scales well on clusters XML parsing Buisness intelligence with little data sharing HPC applications Business Applications Highly Threaded Type 2 Scales well on large SMP Web application servers Single instance of an ERP system Some partitioned databases Web, Collaboration and Infrastructure Small Discrete Type 4 Limited scaling needs HTTP servers File and print FTP servers Small end user apps 8

9 Workloads positioning versus Pfister s Paradigm How much sharing is there? Synchronization Traffic Contention and Coherence Delays Type 4 Small discreet applications Type 3 Parallel data structures Type 1 Shared data and work queues Type 2 Highly threaded applications Parallel Hell Parallel Nirvana Parallel Purgatory How much data do we we have to deal with? Bulk Data Traffic Saturation Delay 9

10 Combining workloads and servers in Pfister s diagrams allows to match workload types to machines Type 4 Small discreet applications Type 3 Parallel data structures Type 1 Shared data and work queues Type 2 Highly threaded applications Parallel Hell How much sharing is there? Synchronization Traffic Contention and Coherence Delays Temple s Assertion Blades (x, POWER) idataplex BlueGene X3850 and Midrange Power Parallel Hell Mainframes p795 High-end Power p780 p770 p750 Power 755 and x3950 Highly Scaled NUMA Closely Coupled Clusters Parallel Nirvana Parallel Purgatory Parallel Nirvana Parallel Purgatory How much data do we we have to deal with? Bulk Data Traffic Saturation Delay How much data do we we have to deal with? Bulk Data Traffic Saturation Delay 10 One size does not fit all Pfister s Paradigm and Temple s Assertion

11 The Fit for Purpose approach help define the right platform matching the client workload requirements Fit for Purpose is a client centric thought process that provides rational platform choices, which are in line with client workloads requirements and local conditions. Scale Throughput HA/DR/Cont.Op. Env. constraints Security Multiple areas to take into account: Local Factors Non Functional Requirements Integration requirement Workload characteristics Overall costs IT Strategy/ Technology Adoption Skills TCO System z Power System x I/O intense Appl. Integration Data Integration Memory usage CPU-bound 11

12 Industry standard definitions for Business Continuity IT Resiliency Continuous Business operations Continuous Availability DR Disaster Recovery Mask outages HA: High Availability HA CO CO: Continuous Operations Mask unplanned outages Mask planned outages 12

13 What is the difference between CA and DR? Continuous Availability (CA): When one component of the IT infrastructure (HW or SW) fails (unplanned) or stops (planned), the service to the users is not impacted, or impacted in a very limited scope (only the in-flight transactions they will have to be rolled-back). Examples of CA features: For systems: Parallel Sysplex, Partition Mobility, PowerHA For data: HyperSwap, LVM mirroring, Metro Mirror (synchronous data replication), Oracle RAC Worst case will lead to a restart (not a recovery). This can be done within minutes. If there is an outage wider than IT components, this has nothing to do with CA... Disaster Recovery (DR): When there is a wide outage impacting several or all components of a location (can be more than IT infrastructure), then it s called a disaster. In such situation, all the IT services are interrupted and there is a decision to be made by management whether to recover or not to the alternate remote location. This can be done within hours or days, with more or less data loss. Examples of DR feature on Power Systems: GDPS/GM or XRC, PowerHA/XD, Oracle Dataguard 13

14 Business Continuity customer situation: architectural trend for CA & DR 2 sites 2 physical sites 3 logical sites 3 sites Business and regulatory pressures: Information Technology is now an integral part of the Corporate strategy. IT is no longer in a support role. IT services are now customer-facing and the company image is at risk, and potentially the company itself Gartner survey: Eight-day IT outage would cripple most companies. Various financial services regulatory bodies are requiring long distance disaster recovery solutions (Basel II, FSA, FED/SEC, Sarbanes Oxley, MiFID). 14

15 F4P Principles Review Transaction Processing and Database Analytics and High Performance Local Factors Matter Skills Organizational Technology adoption Strategic direction ISV support Platform capability Local Factors Local Factors Business Applications Web, Collaboration and Infrastructure Platform A Platform B Workloads Matter Non Functional Requirements Matter Business Continuity Manageability Performance & scalability Flexibility Security Workload management Data and Application Integration Matters 15

16 The F4P Workshop overall picture Customer context Pain points and local factors Workload components Non Functional Requirements Preparation Questionnaire Channels Services Channels Presentation Services Presentation Payment application Payment application Logic Logic Data Core Banking Logic Logic PRM Application deployment patterns Data Data Oracle RAC vs. DB2 data sharing DR solutions Performance benchmarks Security architecture on SOA Virtualization techniques Gartner platform positioning Best practices and analysts view Tooling F4P Workshop Current S1 Justification and technical considerations Assessment Platform security (Gartner SEM) : HE Power + Intel The data in transit between the workload components are not encrypted HTTP requests JDBC calls Platform security (Gartner SEM) : System z + Power Hipersocket secure network between ESB, WPS Aspects SPIDER CHART- BEST FIT PLATFORM FOR NFRS Topologies assessment Security 10 9 Strategy Governance Standards 3 Data Center Constraints Platform security (Gartner SEM) : System z + Power Private data network (IEDN) between pblades and System z S2 VLAN configuration is performed only through Unified Resource Manager Disaster Recovery High Availability Hipersocket secure network between ESB, WPS and Oracle DB Secure communication between ESB and CICS (EXCI interface with CICS Node) S3 Platform security (Gartner SEM) : System z + Power Secure communication between ESB and CICS (EXCI interface with CICS Node) Platform security (Gartner SEM) : System z + Power 16 Operational models S4 S5 Private data network (IEDN) between pblades and System z VLAN configuration is performed only through Unified Resource Manager Hipersocket secure network between ESB, WPS and Oracle DB Secure communication between ESB and CICS (EXCI local connector) Platform security (Gartner SEM) : System z + Power User Defined NFR5 System z PS701 Skills System x Min Scalability Power 2013 IBM Linux Corporation on z Exceeds

17 Agenda Workload and platform positioning The Key Fit for Purpose principles The Non Functional Requirements: Business Continuity Customer example IBM PSSC F4P & HACoC workshops offering 17

18 Summary of the customer context Business context & Local Factors Business Strategy Customer is the large commercial bank in Asia. It has 18 million accounts including business and retail customers. A nationwide network of ~ 1000 branches. The bank developed a self-service network, including > 7,600 ATMs, phone banking facility, and an internet banking service. Strategy is to propose additional value to their customers and create a real differentiation against other banks Customer s plan is also to expand its services to the Chinese market and oversea IT Strategy Maximize utilization of existing assets Optimize day to day operation, to keep user satisfaction very high Channel Management is the highest priority Workloads identified Enterprise Content Management + SOA Application with high visibility that needs user acceptance High service level requirement for planned and unplanned outages ESB component is the cornerstone of the Enterprise integration strategy Throughput is estimated to 8000 transaction/day for the first deployment in production Non Functional Requirements & IT Challenges NFRs Continuous availability (HA & continuity of operations) (High priority) Disaster Recovery (Enterprise strategy) (Medium priority) Scalability & Flexibility (Medium priority) Performance (High priority) Manageability (High priority) Quality of service (Medium priority) Security (Medium priority) IT Challenges The major operation concern is system monitoring, SLA achievement in order to get the operations run smoothly and to have IT focus on new initiatives rather than on 18 operations Local factors & Data/application Integration Local factors Key IT standards: Cobol (MF), Java + C (Unix),.Net (Window) Customer applications are home made and ISV based. Customer s trend is to replace obsolete applications with ISV. Some distributed applications are virtualized (Hyper V, Power VM) Skills on Mainframe, AIX and Windows. No skill on Linux. Application Integration Strategy is to move to an Enterprise integration Bus (WMB) Data Integration Critical data are stored on the Mainframe. There are some Data Marts but no real DW. Synchronizations with Data Marts are done by Cobol batch.

19 Component model 19

20 Physical operational model - Production environment 20

21 We have selected 6 alternative scenarios for operational models FileNet AE, CE, PE FileNet IS ESB (WMB) Process Services - Process (WPS) Data Services (Oracle DB) Service Registry (WSRR) BRMS (ILOG) Process Analytics and Simulation Business Analytic Monitoring (WBM) Current Intel Windows Intel Windows Intel Windows Intel Windows S1 zlinux zlinux zlinux Intel Windows S2 zbx pblade AIX zbx pblade AIX zlinux zlinux zlinux zlinux zbx pblade AIX zbx Intel Blade Windows zbx pblade AIX S3 z/os Intel Windows S4 zlinux zbx pblade AIX z/os zlinux zlinux zlinux zlinux zbx Intel Blade Windows zlinux S5 Intel Windows 21

22 NFR s table High Availability & Continuity of Operation (1/2) Requirement: Very high 24X7 Current S1 S2 22 Assessment Platform reliability (Gartner SEM) : HE Power + Intel Aspects Clustering mechanism and workload distribution OS clustering relying on HACMP for IS and BAM Software clustering for WAS, WMQ and Oracle WMQ clustering mechanism in place need to be explained WPS golden topology (several clusters: Apps, ME, Support apps ) HW balancer used to balance the HTTP requests Platform reliability (Gartner SEM) : System z (Linux on z) + HE Power Clustering mechanism and workload distribution z/vm Single System Image Feature - Clustered Hypervisor with Live Guest Relocation OS clustering relying on HACMP for IS and BAM Software clustering for WAS, WMQ and Oracle WPS golden topology (several clusters: Apps, ME, Support apps ) HW balancer used to balance the HTTP requests Platform reliability (Gartner SEM) : zenterprise including System z (z/os + zlinux) + Power blade zbx hardware is defined for redundancy (n+1) : all component are redundant (Power, Switch ) Single VIO server on Power Blade Clustering mechanism and workload distribution z/vm Single System Image Feature - Clustered Hypervisor with Live Guest Relocation OS clustering relying on HACMP for IS and BAM Software clustering for WAS, WMQ and Oracle WPS golden topology (several clusters: Apps, ME, Support apps ) HW balancer used to balance the HTTP requests zenterprise Network The networks are redundantly cabled and the switches are configured to allow a non-disruptive failover in case a failure in a switch or cable occurs. The platform-provided networks are continuously monitored and under permanent surveillance.

23 NFR s table High Availability & Continuity of Operation (2/2) Assessment Aspects S3 S4 S5 Platform reliability (Gartner SEM) : System z (z/os) + HE Power Clustering mechanism and workload distribution z/os Sysplex cluster - Sub System cluster WMB/WMQ fully leverage z/os Sysplex functionalities MQ Shared Queues OS clustering relying on HACMP for IS and BAM Software clustering for WAS, WMQ and Oracle WPS golden topology (several clusters: Apps, ME, Support apps ) HW balancer used to balance the HTTP requests Platform reliability (Gartner SEM) : zenterprise including System z (z/os + zlinux) + Power blade zbx hardware is defined for redundancy (n+1) : all component are redundant (Power, Switch ) Single VIO server on Power Blade Clustering mechanism and workload distribution z/os Sysplex cluster - Sub System cluster WMB/WMQ fully leverage z/os Sysplex functionalities MQ Shared Queues z/vm Single System Image Feature - Clustered Hypervisor with Live Guest Relocation OS clustering relying on HACMP for IS and on other mechanism like TSA for BAM Software clustering for WAS, WMQ and Oracle WPS golden topology (several clusters: Apps, ME, Support apps ) HW balancer used to balance the HTTP requests zenterprise Network The networks are redundantly cabled and the switches are configured to allow a non-disruptive failover in case a failure in a switch or cable occurs. The platform-provided networks are continuously monitored and under permanent surveillance. Platform reliability (Gartner SEM) : Power Clustering mechanism and workload distribution OS clustering relying on HACMP for IS and BAM Software clustering for WAS, WMQ and Oracle WPS golden topology (several clusters: Apps, ME, Support apps ) HW balancer used to balance the HTTP requests 23

24 WMQ HA - Comparison of Technologies 24

25 Single System Image Feature Clustered Hypervisor with Live Guest Relocation Provided as an optional priced feature. Connect up to four z/vm systems as members of a Single System Image (SSI) cluster Provides a set of shared resources for member systems and their hosted virtual machines Cluster members can be run on the same or different System z servers Simplifies systems management of a multi-z/vm environment Single user directory z/vm 1 Cross - system communications for single system image management z/vm 3 Cluster management from any member Apply maintenance to all members in the cluster from one location Issue commands from one member to operate on another Shared disks Built-in cross-member capabilities Resource coordination and protection of network and disks z/vm 2 Cross - system external network connectivity for guest systems z/vm 4 Private disks 25

26 NFR s table - Disaster Recovery Requirement: Very high Current S1 Assessment Aspects DR infrastructure in place in RAMA3 for content management What about WPS & ESB? Heterogeneous infrastructure might be more complex to manage using automation recovery procedures i.e Multiple storage sub systems to be mirrored on DR site, multiple physical server Few sophisticated automation recovery procedures SAN mirroring Oracle Dataguard Synchronous or Asynchronous? SQL Server log shipping If WAS or WPS requires distributed transaction (i.e. DB2 + WMB) then multiple source of transaction log to handle could be more complex to manage The workloads components hosted on Linux z (WPS, WMB, WSRR ) can be managed using the current System z procedures. For example GDPS policy. S2 S3 System z manages the complete DR plan: All the workload components can be managed using a single set of consistent processes Possibility of using sophisticated automation recovery procedures like GDPS GDPS V3.8 Enhancements for zenterprise GPDS can be used to manage the overall zenterprise Simplified infrastructure might be easier to manage using exiting automation recovery procedures Removal of critical components (WPS & WMB) from Intel environment 26 S4 S5 System z manages the complete DR plan: All the workload components can be managed using a single set of consistent processes Possibility of using sophisticated automation recovery procedures like GDPS GDPS V3.8 Enhancements for zenterprise GPDS can be used to manage the overall zenterprise Simplified infrastructure might be easier to manage using automation recovery procedures Removal of critical components (WPS & WMB) from Intel environment Possibility of using solutions like IBM Tivoli System Automation for Multiplatforms and Tivoli System 2013 Automation IBM Corporation Application Manager or Geographically Dispersed Open Clusters (GDOC) for automation recovery procedures.

27 GDPS /PPRC Multiplatform Resiliency for System z Lin1 SAP App Servers Lin2 Lin3 Lin4 z/vm LPAR1 SA z/os NetView CICS & DB2 z/os LPAR2 SA z/os NetView SAP DB Server z/os LPAR3 z/os Sysplex SA z/os NetView GDPS System z/os LPAR4 ESS PPRC Site 1 Site 2 Site System Automation (SA) for Multiplatforms Takeover Expendable Workload LPAR5 ESS Designed for customers with distributed applications SAP application server running on Linux for zseries SAP DB server running on z/os Coordinated nearcontinuous availability and DR solution for z/os, Linux guests, and z/vm Uses z/vm HyperSwap function to switch to secondary disks Sysplex support allows for site recovery 27

28 Assessment and positioning of current, S1, S2, and S5 topologies SPIDER CHART- BEST FIT PLATFORM FOR NFRS High Availability 9 Migration effort Skills Performance System Management Enterprise integration strategy Disaster Recovery Risk Security Quality of Service Current - WMB, W PS & WSRR on Intel S1 - W MB, WPS and WSRR on Linux on System z S2 - Extension of S1 with zenterprise S5 - Optimize the existing investment on Power System 28

29 Agenda Workload and platform positioning The Key Fit for Purpose principles The Non Functional Requirements: Business Continuity Customer example IBM PSSC F4P & HACoC workshops offering 29

30 The objectives of the F4P workshop The objective of the workshop is to propose and assess different deployment topologies for an identified workload. The value assessment is based on Fit for Purpose criteria like workload characteristics, Non Functional Requirements, Workload integration requirements, and customer local factors. The main topics covered in the workshop are: Presentation of the key principles of workload and platform positioning Analysis of the workload in scope and the requirements Identification and description of new deployment topologies Justification and assessment of the new deployment topologies versus workload requirements Technical presentation and value of the target platforms Analyst point of view Customer experiences, IBM best practices and lessons learned 30

31 The F4P workshop: A 3-phase workshop process Workload data gathering (IBM & Client) Workloads selection Workloads description Information gathering and sharing with F4P team Workshop preparation (IBM F4P Internal) Workloads analysis Pattern-based approach Build new operational models based on IBM systems Show added value Workshop execution (IBM & Client) Proposition and assessment of alternate topologies Assessment, positioning, value IBM Systems deep dive (Opt.) Next steps 2-3 weeks 1-2 weeks 1 week Questionnaire sent Preparation & gathering session with client (<1 day) F4P workshop session (1 day) Gather relevant architectural diagrams for the target workload Gather operational (non-functional) requirements and other local factors (e.g. standards) Performed via questionnaires and Client interview (live meeting or via remote connection) Final Report delivered (+2-4 days) 31

32 HACoC can help you reach your Business Continuity needs!! Where are you now in terms of IT availability? Where do you want to go based on your business requirements? Assessment Workshop How will you get there with your current system and processes? Best practices input Technology Best practices (HA/DR) ITIL Service Management Client s Business Objectives HACoC Workshop Report Technology documentation Mission-critical application Typical outage description [Subject Matter Experts] Client s input HACoC Technical leader & IT Service Management Specialist [IBM Subject Matter Experts] Expert s input Workshop Output Key findings and observations Technology recommendations Process recommendations Implementation roadmap 32

33 Questions 33