Ensuring Business Continuity with the IBM Fit For Purpose ... - Ensuring... · Business Continuity...

© 2013 IBM Corporation

Ensuring Business Continuity with the IBM Fit For Purpose MethodologyYann KindelbergerSenior Architect, Design CenterIBM Client Center [email protected]

GUIDE SHARE EUROPE

© 2013 IBM Corporation2

GUIDE SHARE EUROPE - Region Belgium-Luxembourg - 32nd Regional Conference

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



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.

� Multiple areas to take into account: – Local Factors– Non Functional Requirements– Integration requirement– Workload characteristics– Overall costs

Systemz

System x

Power

ThroughputHA/DR/Cont.Op.

Security

Data Integration

I/O intense

CPU-boundMemory usage

TCO

Skills

IT Strategy/Technology Adoption

Env. constraints

Scale

Appl. Integration



4

� Though 2-year cycles between nodes will continue, beyond 22 nm new technology nodes, but the historic 35%-per-node increase & doubling of transistor density may drop to 15-20%. Power density is limiting ability to fully translate the transistor performance gain into systems.

Transistor performance scaling to continue, but at a slower rate

Power is limiting practical performance

Single thread performance is slowing dramatically

A B C

Rel

ativ

eTechnology dominant trends show that single core operations are limited



But there are also factors affecting workload scaling in multi-core operations

Cache misses and I/O delays detract from throughput but do not reduce CPU busy time

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 da ta replication

CPU Utilization

Thr

ough

put

Saturation

Queuing and Contention Cache and Buffer Coherence

CPU, I/O and Memory Bandwidth

CPU clock speed and code path length;memory, cache, and I/O size, ports and speed

Cache

Core Core Core

Cache

Core Cache

Core

Cache

Core

Cache

Core

Cache

Core

Memory

Memory Core Cache I/O



Research showed that server design could not cope with all the limiting factors: Tradeoffs are mandatory in server design

Thread Speed

Thread Count

High

Low

High

Low

Low

High

Server Server DesignDesign

Effective Cache/ Thread

Fitness Proxies:

•Thread Speed – Serial Fitness•Thread Count – Parallel Fitness•Cache/Thread – Data Fitness



Temple’s Assertion

Fitness for Data Centric Loads

Fitn

ess

for

Ser

ial L

oads

Blades (x, POWER)iDataplexBlueGene

Highly Scaled NUMA

Closely Coupled Clusters

Mainframes

Power 755 and x3950

X3850 and Midrange Power

p795 High-end Powerp780

p770p750

Parallel Purgatory

Parallel Hell

Parallel Nirvana

IBMer J.Temple asserts that IBM Servers are optimized for different parts of Pfister’s space and proposed this positioning:



These workload segments map to technical characteristics

Shared Data & Work Q – Type 1• Scales up• Updates to shared data

and work queues• Complex virtualization• Business Intelligence with

heavy data sharing

Parallel Data Structures – Type 3

Small Discrete – Type 4Highly Threaded – Type 2

• Scales well on clusters• XML parsing• Buisness intelligence with

little data sharing• HPC applications

• Scales well on large SMP• Web application servers• Single instance of an

ERP system• Some partitioned

databases

• Limited scaling needs• HTTP servers• File and print• FTP servers• Small end user apps

Transaction Processing and Database Analytics and High Performance

Business Applications Web, Collaboration and Infrastructure



Workloads positioning versus Pfister’s Paradigm

How

much sharing is there?

Synchronization T

rafficC

ontention and Coherence D

elays

How much data do we we have to deal with?Bulk Data Traffic – Saturation Delay

Type 1Shared data and work queues

Type 3Parallel data structures

Type 4Small discreet applications

Type 2 Highly threaded

applications

Parallel PurgatoryParallel Nirvana

Parallel Hell



Combining workloads and servers in Pfister’s diagrams allows to match workload types to machines

One size does not fit allPfister’s Paradigm and “Temple’s Assertion”

Type 1Shared data and work queues

Type 3Parallel data structures

Type 4Small discreet applications

Type 2 Highly threaded

applications

Parallel PurgatoryParallel Nirvana

Parallel Hell

How

much sharing is there?

Synchronization T

rafficC

ontention and Coherence D

elaysHow much data do we we have to deal with?

Bulk Data Traffic – Saturation DelayHow much data do we we have to deal with?

Bulk Data Traffic – Saturation Delay

Temple’s Assertion

Blades (x, POWER)iDataplexBlueGene

Highly Scaled NUMA

Closely Coupled Clusters

Mainframes

Power 755 and x3950

X3850 and Midrange Power

p795 High-end Powerp780

p770p750

Parallel Purgatory

Parallel Hell

Parallel Nirvana



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.

� Multiple areas to take into account: – Local Factors– Non Functional Requirements– Integration requirement– Workload characteristics– Overall costs

Systemz

System x

Power

ThroughputHA/DR/Cont.Op.

Security

Data Integration

I/O intense

CPU-boundMemory usage

TCO

Skills

IT Strategy/Technology Adoption

Env. constraints

Scale

Appl. Integration



Industry standard definitions for Business Continuity

IT ResiliencyContinuous

Businessoperations

Continuous AvailabilityMask outages

HA

Mask unplanned outages

HA: High Availability CO

Mask plannedoutages

CO: Continuous Operations

DR

DisasterRecovery



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



Business Continuity customer situation: architectural trend for CA & DR

2 sites 2 physical sites3 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.

• 2007 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).



F4P Principles Review

Pla

tform

cap

abili

ty

Platform A Platform B

Local Factors

Local Factors

Local Factors Matter• Skills• Organizational • Technology adoption• Strategic direction• ISV support

Business Applications

Transaction Processing and Database

Web, Collaboration and Infrastructure

Analytics and High Performance

Workloads Matter

Data and Application Integration Matters

Non Functional Requirements Matter• Business Continuity• Manageability• Performance & scalability• Flexibility• Security• Workload management



Tooling

Justification and technical considerations

F4P Workshop

SPIDER CHART- BEST FIT PLATFORM FOR NFRS

0

1

2

3

4

5

6

7

8

9

10

Security

Governance

Data Center Constraints

High Availability

Scalability

Skills

User Defined NFR5

Disaster Recovery

Standards

Strategy

System zSystem zSystem zSystem z System xSystem xSystem xSystem x PowerPowerPowerPower Linux on zLinux on zLinux on zLinux on z

PS701PS701PS701PS701 MinMinMinMin ExceedsExceedsExceedsExceeds

PreparationQuestionnaire

�Customer context

�Pain points and local factors

�Workload components

� Non Functional Requirements

Core BankingCore Banking

Data

Channels Channels ServicesServices

Presentation Logic

Channels Channels ServicesServices

Presentation

Payment Payment applicationapplication

Logic

Payment Payment applicationapplication

Logic Data

PRMPRM

Logic Data

Application deployment patterns

Best practices and analysts view

• Oracle RAC vs. DB2 data sharing• DR solutions • Performance benchmarks• Security architecture on SOA • Virtualization techniques• Gartner platform positioning

The F4P Workshop overall picture

Operational models

Platform security (Gartner SEM) : System z + Power

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 interface with CICS Node)

S2

Platform security (Gartner SEM) : System z + PowerS5


Hipersocket – secure network between ESB, WPSS1

Assessment





Secure communication between ESB and CICS (EXCI local connector)

S4



Platform security (Gartner SEM) : HE Power + Intel

The data in transit between the workload components are not encrypted –HTTP requests–JDBC calls

Aspects

S3

Current






S2

Platform security (Gartner SEM) : System z + PowerS5


Hipersocket – secure network between ESB, WPSS1

Assessment





Secure communication between ESB and CICS (EXCI local connector)

S4



Platform security (Gartner SEM) : HE Power + Intel

The data in transit between the workload components are not encrypted –HTTP requests–JDBC calls

Aspects

S3

Current

Topologies assessment



Agenda




Customer example




Workloads identifiedBusiness context & Local Factors

Non Functional Requirements & IT Challenges Local factors & Data/application Integration

Summary of the customer context

� 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

� 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 operations

� 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 .

� 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



Component model



Physical operational model - Production environment



We have selected 6 alternative scenarios for operational models

zBX pBladeAIX

zBX Intel Blade

Windows

zBX pBladeAIX

zLinuxzLinuxzLinuxzLinuxzBX pBlade

AIXzBX pBlade

AIXS2

zLinuxzBX Intel

Blade Windows

zLinuxzLinuxzLinuxzLinuxz/OSzBX pBlade

AIXzLinuxS4

High End Power AIX

High End Power AIX

High End Power AIX

High End Power AIX

FileNet IS

High End Power AIX

High End Power AIX

High End Power AIX

High End Power AIX

Data Services

(Oracle DB)

High End Power AIX

High End Power AIX

zLinux

Intel Windows

Process Services

-Process

(WPS)

High End Power AIX

High End Power AIX

High End Power AIX

High End Power AIX

BRMS

(ILOG)

High End Power AIX

High End Power AIX

zLinux

Intel Windows

Service Registry

(WSRR)

Intel Windows

Intel Windows

Intel Windows

Intel Windows

Process Analytics

and Simulation

High End Power AIX

High End Power AIX

High End Power AIXS5

High End Power AIX

zLinuxHigh End Power AIXS1

High End Power AIX

High End Power AIX

FileNetAE, CE,

PE

z/OS

Intel Windows

ESB

(WMB)

High End Power AIXS3

High End Power AIXCurrent

Business Analytic

Monitoring

(WBM)



NFR’s table – High Availability & Continuity of Operation (1/2)

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.

S2

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

S1

Assessment

Platform reliability (Gartner SEM) : HE Power + Intel

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


Aspects

Current

� Requirement: Very high – 24X7



NFR’s table – High Availability & Continuity of Operation (2/2)

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


S3

Platform reliability (Gartner SEM) : Power High End

Clustering mechanism and workload distribution–OS clustering relying on HACMP for IS and BAM–Software clustering for WAS, WMQ and Oracle


S5

Assessment

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


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.

Aspects

S4



WMQ HA - Comparison of Technologies



Single System Image FeatureClustered 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 ofa multi-z/VM environment

– Single user directory

– Cluster management from any member

• Apply maintenance to all membersin the cluster from one location

• Issue commands from one memberto operate on another

– Built-in cross-member capabilities

– Resource coordination and protectionof network and disks

z/VM 2

z/VM 1

z/VM 4

z/VM 3

Shared disks

Private disks

Cross - system communications for“ single system image ” management

Cross - system external network connectivity for guest systems

z/VM 2

z/VM 1

z/VM 4

z/VM 3

Shared disks

Private disks

Cross - system communications for“ single system image ” management

Cross - system external network connectivity for guest systems



NFR’s table - Disaster Recovery

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

S2

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 Automation Application Manager or Geographically Dispersed Open Clusters (GDOC) for automation recovery procedures.

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

S4

The workloads’ components hosted on Linux z (WPS, WMB, WSRR ) can be managed using the current System z procedures.

–For example GDPS policy.S1

Assessment

Simplified infrastructure might be easier to manage using exiting automation recovery procedures –Removal of critical components (WPS & WMB) from Intel environment

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

Aspects

S3

Current

� Requirement: Very high



Lin1

z/VM

LPAR1

Lin2 Lin3 Lin4

System Automation (SA)for Multiplatforms

CICS& DB2

z/OS

LPAR2

SA z/OSNetView

SAP DBServer

z/OS

LPAR3

SA z/OSNetView

GDPS System

z/OS

LPAR4

SA z/OSNetView

ESS

LPAR5

ESS

SAP App Servers

Site 1 Site 2

PPRC

Site

z/OS Sysplex

Expend-able

Workload

Takeover

GDPS™/PPRC Multiplatform Resiliency for System z

� Designed for customers with distributed applications

� SAP application server running on Linux for zSeries

� SAP DB server running on z/OS

� Coordinated near-continuous 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



Assessment and positioning of current, S1, S2, and S5 topologies

SPIDER CHART- BEST FIT PLATFORM FOR NFRS

0

1

2

3

4

5

6

7

8

9

High Availability

Performance

System Management

Disaster Recovery

Security

Quality of Service

Risk

Enterprise integration strategy

Migration effort

Skills

Current - WMB, W PS & WSRR on IntelCurrent - WMB, W PS & WSRR on IntelCurrent - WMB, W PS & WSRR on IntelCurrent - WMB, W PS & WSRR on IntelS1 - W MB, WPS and WSRR on Linux on System zS1 - W MB, WPS and WSRR on Linux on System zS1 - W MB, WPS and WSRR on Linux on System zS1 - W MB, WPS and WSRR on Linux on System zS2 - Extension of S1 with zEnterpriseS2 - Extension of S1 with zEnterpriseS2 - Extension of S1 with zEnterpriseS2 - Extension of S1 with zEnterpriseS5 - Optimize the exist ing investment on High End Power SystemS5 - Optimize the exist ing investment on High End Power SystemS5 - Optimize the exist ing investment on High End Power SystemS5 - Optimize the exist ing investment on High End Power System



Agenda




Customer example




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



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 execution(IBM & Client)

•Proposition and assessment of alternate topologies•Assessment, positioning, value•IBM Systems deep dive (Opt.)•Next steps

Workshop preparation(IBM F4P Internal)

•Workloads analysis•Pattern-based approach•Build new operational models based on IBM systems•Show added value

2-3 weeks

Preparation & gathering

session with client

(<1 day)

Question-naire sent

1-2 weeks 1 week

Final Report delivered

(+2-4 days)

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)



• Client’s Business Objectives

• Technology documentation

• Mission-critical application

• Typical outage description

• [Subject Matter Experts]

HACoC Workshop

Client’s input • Key findings and observations

• Technology recommendations

• Process recommendations

• Implementation roadmap

Report

Workshop Output

• Technology Best practices (HA/DR)

• ITIL Service ManagementB

est p

ract

ices

‘in

put

• HACoC Technical leader & IT Service Management Specialist

• [IBM Subject Matter Experts] E

xper

t‘s in

put

HACoC can help you reach your Business Continuity needs !!

Assessment WorkshopWhere are you nowin terms of IT availability?

Where do you want to gobased on your business

requirements?

How will you get therewith your current system

and processes?



QuestionsQuestions

Ensuring Business Continuity with the IBM Fit For Purpose ... - Ensuring... · Business Continuity...

Documents

Transcript of Ensuring Business Continuity with the IBM Fit For Purpose ... - Ensuring... · Business Continuity...