© 2013 IBM Corporation IBM STG Servers and Storage within IBM's High Availability and Data Protection portfolio IBM STG Server and Storage Solutions John

© 2013 IBM Corporation

IBM STG Servers and Storage within IBM's High Availability and Data Protection portfolio

IBM STG Server and Storage Solutions

John Sing, Executive IT Consultant, Sarasota, Florida [email protected]

IBM Tivoli Storage Software Solutions

©2011 IBM Corporation© 2013 IBM Corporation

22

John Sing 31 years of experience with IBM in high end servers, storage, and

software– 2009 - Present: IBM Executive Strategy Consultant: IT Strategy and Planning,

Enterprise Large Scale Storage, Internet Scale Workloads and Data Center Design, Big Data Analytics, HA/DR/BC

– 2002-2008: IBM IT Data Center Strategy, Large Scale Systems, Business Continuity, HA/DR/BC, IBM Storage

– 1998-2001: IBM Storage Subsystems Group - Enterprise Storage Server Marketing Manager, Planner for ESS Copy Services (FlashCopy, PPRC, XRC, Metro Mirror, Global Mirror)

– 1994-1998: IBM Hong Kong, IBM China Marketing Specialist for High-End Storage– 1989-1994: IBM USA Systems Center Specialist for High-End S/390 processors– 1982-1989: IBM USA Marketing Specialist for S/370, S/390 customers (including

VSE and VSE/ESA) [email protected]

IBM colleagues may access my intranet webpage:– http://snjgsa.ibm.com/~singj/

You may follow my daily IT research blog– http://www.delicious.com/atsf_arizona

You may follow me on Slideshare.net:– http://www.slideshare.net/johnsing1

My LinkedIn:– http://www.linkedin.com/in/johnsing

October 2012 Budapest charts by JSing: – http://snjgsa.ibm.com/~singj/public/2012_Budapest_Europe_Storage_S

ymposium/



33

Today’s Goals

IBM approach to today’s IT High Availability and IT Business Continuity best practices

IBM STG Servers and Storage products positioning

– Within the IBM High Availability, Disaster Protetion portfolio

Role of IBM STG Server and Storage Storage solutions

– in any high availability, business continuity, disaster recovery design

3



44

2. Made possible by IBM Server and

StorageVirtualization

Things to remember

1. IT Consolidation / Efficiency is foundation



5

TrueCluster

UFSSun Cluster

PolyServe

MSCS

PPRC

ASMZFS

SecurePath

InstantImage

MPxIO

JFS

LVM

TrueCopy

JFS2

HDLM

SVM Ext3

MPIO

LDM

PowerPath

TimeFinderShadowCopy

SAM FS

QFSSDS

MirrorDisk-UX

SnapView

MirrorView

SRDF

OCFSSAN-FS

ReiserFSGPFS

Snap RepliStor

ServiceGuard

Data Replication Manager

EVM

SVC

FlashCopy

HACMP

GeoSpan

SAN Copy

DLM

ShadowImage

SnapShotDoubleTake

ClusterFrame

SNDR

QFSTOOLS

SHOWN:

0102030405060708091011121314151617181920212223242526272829303132333435363738394041424344454647484950+

Cannot efficiently recover an in-efficient, non-standardized infrastructure

If this is today’s infrastructure……….Efficient Disaster Recovery pre-req: Standardized, virtualized IT



6

? IT Virtualization, Consolidation enhances

Data Protection

Funding given today’s cost crunch?Complexity of infrastructure to recover?Priorities? Resources? Data Protection is an intended side benefit of

Consolidation, Virtualization

Fact: accelerating IT Consolidation, Virtualization, will accelerate Data Protection

Strategic Approach: Data protection is intended side-benefit of IT Consolidation and Virtualization

Data Protection Fewer Components to Recover Invest percentage of Savings

Invest in more robust Business Resiliency

Standardize and optimize IT and Business Resiliency solution design

Load Balancing Solution architecture

HA/BC pre-requisite:IT Virtualization and Consolidation

Cost-Effective Server,

Storage IT Efficiency

Application Servers

High-End Workstations

Database

End Users

Protocols

SANCIFSNFS

HTTPFTP

ManagementCentralAdministratio

nMonito

ringFile

Mgmt

AvailabilityData Migration

ReplicationBackup Application Servers


Database

End Users

Protocols

SANCIFSNFS

HTTPFTP

ManagementCentralAdministratio

nMonito

ringFile

Mgmt

AvailabilityData Migration

ReplicationBackup



7

How efficient is your customer’s IT? (pre-req’s for HA/BC/DR)

http://public.dhe.ibm.com/common/ssi/ecm/en/rlw03007usen/RLW03007USEN.PDF http://www-935.ibm.com/services/us/igs/smarterdatacenter.html

April 2012

Power requirement determines 80% of CAPEX to construct

new data center

Power requirement determines 80% of CAPEX to construct

new data center



8

Application transactionintegrity recovery

Timeline of an IT Recovery ==>

?

Production ☺ Network Staff

Operations StaffOperations Staff

Data

Operating System

Physical Facilities

Telecom Network

Management Control

Execute hardware, operating system, and data integrity recovery

Assess

Now we're done!

Applications Staff

Recovery Time Objective (RTO)of hardware data integrity

Outage!

RPO

IBM STG portfolio has automated products / tools to help implement

and manage this entire process

8

RPO

Recovery Point Objective

(RPO)

How much datamust be

recreated?

Recovery Time Objective (RTO)of transaction integrity

Applications



9

Tape Backup

SecsMinsHrsDays Wks Secs Mins Hrs Days Wks

Recovery PointRecovery Point Recovery TimeRecovery Time

Synchronous replication / HA

Periodic Replication

Asynchronous replication

Replication Technology Drives RPO (Recovery Point Objective)

For example:

Recovery point =

How current is my recovered data?



10

Recovery Time includes:

– Fault detection

– Recovering data

– Bringing applications back online

– Network access

Manual Tape Restore



End to end automated clustering

Storage automation

Recovery Automation Drives RTO (Recovery Time Objective)

For example:

Recovery time =

How long it takes me to recover after outage



111111 October 2011

Recovery Time Objective (guidelines only)

15 Min. 1-4 Hr.. 4 -8 Hr.. 8-12 Hr.. 12-16 Hr.. 24 Hr.. Days

Co

st

/ Va

lue

BC Tier 4 – Add Point in Time replication to Backup/Restore

BC Tier 3 – VTL, Data De-Dup, Remote vault

BC Tier 2 – Tape libraries + Automation

BC Tier 7 – Add Server or Storage replication with end-to-end automated server recovery

BC Tier 6 – Add real-time continuous data replication, server or storage

BC Tier 1 – Restore from Tape

Organizing High Availability, Business Continuity Technologies Balancing recovery time objective with cost / value

BC Tier 5 – Add Application/database integration to Backup/Restore

Recovery from a disk image Recovery from tape copy



1212

How to position IBM STG Servers and Storage in Disaster Recovery and Data Protection in 2013?



1313

Site Load Balancer

Web Server Clusters

Application / DBServer Clusters

Server Clusters Disk

Production Site

Many choices for high availability and replication architectures

Local backup

Software:Application

or Database replication

ServerReplication

StorageReplic.

Geographic Load Balancer

Geographic Load Balancer Site

Load Balancer

PIT Image, Tape B/U

Web Server Clusters

Application / DBServer Clusters

Server Clusters

Other Site(s)

Software:Workloadbalancer



1414

Comparing IT replication method choices

Software: App / DB / file system replication / workload balancer– Typically requires the least bandwidth– May be required if the scale of storage is very large (i.e. internet scale)– Span of consistency is that application, database or file system only– Well understood by database, application, file system administrators– Can be more complex implementation, must implement for each application

File system,

DB, Applic.

Aware

File system,

DB, Applic.

Agnostic

Server Replication (traditional IT) – Utilizes operating system skills set in administrators– Storage and application independent, uses server cycles– Span of recovery limited to that server platform

Storage Replication (traditional IT)– Can provide common recovery across multiple application stacks and multiple

server platforms– Can require more bandwidth– Utilizes storage replication skill set in storage administrators

Site Load Balancer

Web Server Clusters

Application / DB Server Clusters

Server Clusters Storage

Production Site

LocalBackup

Application / DB Replication

ServerReplication

StorReplic.



Load Balancer Replication,

PiT Image, Tape

Web Server Clusters


Server Clusters

Multiple Site(s)

WorkloadBalancer

Customer will make their

architectural choice….

Customer will make their

architectural choice….



1515

Comparing IT replication method choices

Software: App / DB / file system replication / workload balancer– Typically requires the least bandwidth– May be required if the scale of storage is very large (i.e. internet scale)– Span of consistency is that application, database or file system only– Well understood by database, application, file system administrators– Can be more complex implementation, must implement for each application

Server Replication (traditional IT) – Utilizes operating system skills set in administrators– Storage and application independent, uses server cycles– Span of recovery limited to that server platform

Storage Replication (traditional IT)– Can provide common recovery across multiple application stacks and multiple

server platforms– Can require more bandwidth– Utilizes storage replication skill set in storage administrators

Site Load Balancer

Web Server Clusters


Server Clusters Storage

Production Site

LocalBackup

Application / DB Replication

ServerReplication

StorReplic.



Load Balancer Replication,

PiT Image, Tape

Web Server Clusters


Server Clusters

Multiple Site(s)

WorkloadBalancer

IBM STG Servers and

Storage

IBM STG Servers and

Storage



16

Key IT High Availability, Business ContinuityRequirements Questions (in proper order):

1. What applications or databases to recover?

2. What platform? (z, p, i, x and Windows, Linux, heterogeneous open, heterogeneous z+Open)

3. What is desired Recovery Time Objective (RTO)?

4. What is distance between the sites? (if there are 2 sites)

5. What is the connectivity, infrastructure, and bandwidth between sites?

7. What is the Level of Recovery?- Planned Outage- Unplanned Outage- Transaction Integrity

8. What is the Recovery Point Objective?

9. What is the amount of data to be recovered (in GB or TB)?

10. Who will design the solution?

11. Who will implement the solution?

12. Remaining solutions are valid choices to give to detailed DR evaluation team

6. What are the specific h/w equipment(s) that needs to be recovered?

Tier 4Tier 3

Tier 2

Tier 7Tier 6

Tier 5

Tier 1



1717

Virtualization is fundamental to addressing today’s traditional IT diversity

Virtualization



1818

Key strategy: virtualize servers and data into logical storage / server pools. Sell foundation, followed by two enhancement stages

Continuous Availability (CA) – E2E automation– RTO = near continuous, RPO = small as possible (Tier 7)– Priority = uptime, with high value justification

Lower cost

Rapid Data Recovery (RDR) – enhance backup/restore/avail– For data that requires it– RTO = minutes, to (approx. range): 2 to 6 hours– BC Tiers 6, 4– Balanced priorities = Uptime and cost/value

Backup/Restore/Available (B/R) – assure efficient foundation

– Standardize backup/restore, availability, virtualization foundation – Provide universal basic data and server virtualization-based

workload movement and recovery capability– Address requirements for archival, compliance, green energy– Priority = cost

Mission Critical

Start by selling/install efficient foundation first,

Even while still in future phase sell cycle

Start by selling/install efficient foundation first,

Even while still in future phase sell cycle

Enabled by

IBM Server and Storage

Virtualization



1919

IBM Server, Storage

VirtualizationIBM STG Server andStorage Solutions

Real Time Server or storage replication

Real Time Server or storage replication

IBM Server or StoragePeriodic PiT replication:

-Point in Time Disk- VTL to VTL with Dedup

IBM Server or StoragePeriodic PiT replication:

-Point in Time Disk- VTL to VTL with Dedup

-IBM’s data protection portfolio- tape / VTL / de-dup products-IBM’s data protection portfolio- tape / VTL / de-dup products

PetaByteUnstructure

dWorkloads

PetaByteUnstructure

dWorkloads

PetabyteUnstructured

PetabyteUnstructured

Petabyte unstructured, due to usage and large scale, today typically uses

application level intelligent redundancyfailure toleration design

Petabyte unstructured, due to usage and large scale, today typically uses

application level intelligent redundancyfailure toleration design

Tivoli Storage Productivity Center 5.1

(with Replication

mgmt)

Tivoli FlashCopy Manager

Tivoli Storage Manager

True internet scale wkloads often require separate

application–level recovery



2020

Recovery Time Objective

Co

st

Solutions for HA / BC / DR:in stages, from bottom up

SAN SAN

Add: Point-in-time Copy, disk to disk, Tiered Storage (Tier 4)Foundation: electronic vaulting, automation, tape lib (Tier 3)

Foundation: standardized, automated tape backup (Tier 2, 1)

Disk VTL/De-DupDisk VTL/De-Dup VTL/De-Dup

•IBM AIX LVM•IBM FlashCopy, SnapShot•IBM XIV, SVC, DS, SONAS•IBM Tivoli Storage Productivity Center 5.1•Tivoli FlashCopy Mgr

•IBM ProtecTier•IBM Virtual Tape Library•IBM Tivoli Storage Manager Suite, CDP, Fastback, etc.

•VTL, de-dup, remote replication at tape level•Tivoli Storage Manager, etc at remote site



2121


Co

st

SAN SAN

Add: Point-in-time Copy, disk to disk for backup/restore (Tier 4)Foundation: electronic vaulting, automation, tape lib (Tier 3)

Foundation: standardized, automated tape backup (Tier 2, 1)

Disk VTL/De-DupDisk VTL/De-Dup VTL/De-Dup

Applicationintegration

Applicationintegration

Automate applications, database for replication and automation (Tier 5)Consolidate and implement real time data availability (Tier 6)

Datareplication

Data replication

End to end automated site failover servers, storage, applications (Tier 7)

End to endAutomatedFailover:Server

StorageApplications

Server + Storage Solutions HA / BC / DR in stages, from bottom up

Metro Mirror, Global Mirror•DS8000, XIV, SVC, V7000, etc•TPC 5.1 with Replication Mgmt

•GDPS•PowerHA System Mirror•VMWare

•IBM Tivoli FlashCopy Manager additional modules

•Application integration



22

IBM Power Active-Active Solution Portfolio (BC Tiers 6 and 7)

Active-Query or Asymmetric Workload

Active-Active for Symmetric Workload

Primary Site(Production)

Secondary Site(Warm Standby)

Primary Site(Production)

Secondary Site(Query Workload)

Production Site 1 Production Site 2

Active-Query or Asymmetric Workload

Infrastructure Base Solution• AIX HyperSwap

Virtualized Storage Solution• SVC Stretched Cluster VDM

Software Base Solution• DB2 HA-DR / Replication• PowerHA Global LVM

Infrastructure Base Solution• AIX HyperSwap + Flashcopy

Virtualized Storage Solution• SVC Stretched Cluster VDM

Software Base Solution• DB2 HA-DR / Replication• PowerHA Global LVM

Infrastructure Base Solution• AIX HyperSwap + Parallel DB*

Virtualized Storage Solution• SVC Stretched Cluster VDM + Parallel DB

Software Base Solution• DB2 Geographically Dispersed PureScale

Clusters (GDPC)• Geographically Dispersed GPFS Cluster +

Parallel DB• PowerHA-AIX LVM Mirroring

Active-Standby for Fast Takeover

2222



2323



Co

st

/ Va

lue




BC Tier 7 – Add Server, Storage, Software replication end-to-end automated recovery



Summary: Replication, High Availability, Business Continuity Step by Step virtualization, management software journey

Balancing recovery time objective with cost / value



Enhanced STG Server, Storage capabilities

Consolidation,Virtualization



24

Summary – STG step by step Selling Solutions

Production

Backup/Restore Tier 1, 2 Foundation:

Storage, server virtualization and consolidation

Understand my dataDefine scope of recovery Implement remote

sites (Tier 1, 2)

Backup/Restore Tier 1, 2 replicated foundation:

SAN and server virtualization and consolidation

Implement Tier 3 – Further Consolidate and standardize Backup/Restore/virtualization. Implement tape VTL, data de-dup, Server / Storage Virtualization / Mgmt tools, automation

Backup /Restore

Implement Tier 4 – Standardize use of disk to disk and Point in Time copy using server, storage

Implement Tier 5 - Standardize database / Application integration tools

Implement Tier 6 – Standardize high volume data replication method on storage or servers

RapidData

Recovery

Implement BC Tier 7 – Standardize use of Continuous Availability automated Failover

ContinuousAvailability

Step-by-step

Consolidation, Virtualization

Recovery



25



Co

st

/ Va

lue








Step by Step Virtualization, High Availability, Business Continuity data strategy

Balancing recovery time objective with cost / value


Continuous AvailabilityContinuous Availability

Rapid Data RecoveryRapid Data Recovery

Backup/RestoreBackup/Restore

Incremental enhancements

VirtualizationConsolidation



2626

Summary

Consolidation, virtualization

DR = intended

byproduct

IBM STG methodology provides end to end approach for today’s HA/DR/BC best practices

– IBM STG Servers and Storage products positioned according to BC Tiers

– Step by step, 3 phase implementation

IT Efficiency

DataProtection

Application Servers


Database

End Users

ProtocolsSANCIFSNFSHTTPFTP

ManagementCentralAdministrationMonitoringFile Mgmt

Availabilit

yData MigrationReplicatio

nBackup

Sell Disaster Recovery as intended by-product of IBM STG IT efficiency / consolidation / virtualization



27

Accounts identified for disaster recovery message

All TOR accounts in Florida, including– Miami, Fort Lauderdale, West Palm Beach– Key West and the Florida keys– Fort Myers, Naples– Tampa, St. Petersburg, Sarasota, Clearwater– Melbourne, Cocoa Beach– Pensacola, Panama City

– Texas– Galveston– Corpus Christi– Brownsville

– North Carolina– Cape Hatteras

– Central Gulf coast– New Orleans, LA– Biloxi, MS– Mobile, AL

254 accounts targeted with contact info

Tactic code 102JH32W



2828



2929

Thank You

Merci

Grazie

ObrigadoDanke

Japanese

Hebrew

English

French

Russian

German

Italian

Brazilian PortugueseArabic

Traditional Chinese

Simplified

Chinese

Hindi

Tamil Korean

Thai

TesekkurlerTurkish



3030

IBM Redbook documents fundamental methodologies discussed today

SG24-6547-03

IBM System Storage Business Continuity: Part 1 Planning Guide

See chapters 3, 6, and 7

John Sing is architect and co-author of this book

http://www.redbooks.ibm.com/abstracts/sg246547.html



31

PowerHA Reference Material

Ravi Shankar, PowerHA Architect, IBM Austin, US Chiahong Chen, DS8K Development, IBM Tucson, US Carol Mellgren, DS8K Development, IBM Tucson, US Suriyan Ramasami, IBM Oracle ISV Software Engineer, US Wayne Martin, IBM Oracle ISV Technology Manager, US Jayen Shah, PowerHA Testing Manager, IBM Hyderbad, India Jes Kiran, PowerHA Testing Leader, IBM Hyderbad, India Octavian Lascu, ITSO Project Leader, IBM Romania Bao Jun QIN, ICBC Client Technical Advocate, IBM China Lam XU, Storage Technology Manager, IBM China Guo Dong ZHAO, ATS Storage Manager, IBM Chinaand many others who contributed to this initiative over past 1 year...Disclaimer:

Please check with the Release notes delivered with the product for latest details. All statements regarding IBM's future direction & intent are subject to change or withdrawal without notice. It represents goals & objectives only.

31

PowerHA HyperSwap Documentationhttp://pic.dhe.ibm.com/infocenter/aix/v6r1/topic/com.ibm.aix.powerha.pprc/hacmp_pprc_pdf.pdf

IBM PowerHA SystemMirror 7.1.2 Enterprise Edition for AIX (SG248106) ITSO Redbook http://www.redbooks.ibm.com/redpieces/abstracts/sg248106.html?Open

Deploying PowerHA Solution with AIX HyperSwap (REDP4954) ITSO Redpaper http://www.redbooks.ibm.com/redpieces/abstracts/sg248106.html?Open (Target Published in 2Q2013)

Special thanks to following experts who supported PowerHA HyperSwap initiative:



32

The optimum Business Resiliency sales approach for today’s IT world is:

– Up-level existing:• IT Data Center Strategy and IT Infrastructure

Simplification – To produce IT Business Resiliency as an

intended by-product

Learning Points

IT Efficiency

DataProtection

Application Servers


Database

End Users

ProtocolsSANCIFSNFSHTTPFTP

ManagementCentralAdministrationMonitoringFile Mgmt

AvailabilityData MigrationReplicationBackup



33

Recovery Time Objective (RTO) is:– How long can I afford to be without my

systems and business-critical applications?

– Elapsed time between outage and IT is available again

Recovery Point Objective (RPO) is: – How much data can I afford to recreate

(or lose)?• Amount of time between outage

and when last good copy of data was made

• i.e. how current is my data?• Applications may be down until

some/all of data recreated at application level

Learning Points

Sync.Replication

Async.Replication

Tape Backup

Tape Restore

Clustering

OnlineRestore

Remote Replication



RTO:

A function of automation

RPO:

A function of technology

outage

How currentis my recovered

data?

How long takes me to recoverafter outage?



34

Learning Points

Divide IT Disaster Recovery project into typically three implementation phases, using the Business Continuity tiers as a guide

– Do not try to solve all vulnerabilities at once– This builds the solution step by step– Shows value in every phase– Matches expenditure with increasing probability

of an outage over time

Three ranges of customer recovery / budget – (Near) Continuous Availability, end to end

automation• Priority = uptime, with high value

justification– Rapid Data Recovery

• Balanced priorities = Uptime and cost/value– Backup/Restore

• Priority = cost

Recovery Time Objective15 Min.

1-4 Hr..4 -8 Hr..

8-12 Hr..

12-16 Hr..

24 Hr.. Days

Co

st /

Val

ue








Continuous AvailabilityContinuous Availability

Rapid Data RecoveryRapid Data Recovery

Backup/RestoreBackup/Restore

Step by step Consolidation,virtualization



35

Learning Points

Build the solution Step by Step: – The Backup/Restore tier is a foundation for all that follows – Step by step approach provides ability to deliver tangible IT Business Resiliency

value immediately, and at every step of the project– Provides a end user expectation and a roadmap that is easily understood

SAN SAN

Storage mirroring

Storage mirroring

Disk Low-cost Automated

ApplicationMirroring

ApplicationMirroring

End to endAutomatedFailover:Server

StorageApplications

Storage mirroring

Storage mirroring Backup/Restore/Available

Rapid Recovery

Continuous Availability

Disk AutomatedDisk Automated



3636

Appendix: Traditional IT vs. Internet Scale IT unstructured data workloads



3737

Today, there are two major, different types of HA/DR/BC approaches depending on workload type:

Traditional IT Internet Scale Workloads

HA, Business Continuity, Disaster Recovery Characteristics

HA/DR/BC can be done “Agnostic / after the fact” using replication

Data Strategy Use traditional tools/concepts to understand / know data

Storage/server virtualization and pooling

Automation End to end automation of server / storage virtualization

Commonality Apply master vision and lessons learned from internet scale data centers



38

Two different IT architecture types

Source: http://it20.info/2012/02/the-cloud-magic-rectangle-tm/

Internet scale wkloads

Transactional IT



39

Today’s two major IT workload types

Source: http://it20.info/2012/02/the-cloud-magic-rectangle-tm/ Transactional IT Internet scale wkloads



40

How You (Provider) Build These Clouds

Source: http://it20.info/2012/02/the-cloud-magic-rectangle-tm/

Transactional ITInternet scale, new-gen

wkloads



4141

Internet Scale Workload Characteristics - 1

Embarrassingly parallel Internet workload– Immense data sets, but relatively independent records being processed

• Example: billions of web pages, billions of log / cookie / click entries– Web requests from different users essentially independent of each over

• Creating natural units of data partitioning and concurrency• Lends itself well to cluster-level scheduling / load-balancing

– Independence = peak server performance not important– What’s important is aggregate throughput of 100,000s of servers

i.e. Very low inter-process

communication

Workload Churn– Well-defined, stable high level API’s (i.e. simple URLs)– Software release cycles on the order of every couple of weeks

• Means Google’s entire core of search services rewritten in 2 years– Great for rapid innovation

• Expect significant software re-writes to fix problems ongoing basis– New products hyper-frequently emerge

• Often with workload-altering characteristics, example = YouTube

*The Data Center as a Computer: Introduction to Warehouse Scale Computing, p.81 Barroso, Holzlehttp://www.morganclaypool.com/doi/pdf/10.2200/S00193ED1V01Y200905CAC006

Internet scale Workload presentation by John Sing: http://www.slideshare.net/johnsing1/s-bd03-infinitybeyond2internetscaleworkloadsdatacenterdesignv6speaker

Return to “traditional IT vs. Internet scale wkload”



4242

Internet Scale Workload Characteristics - 2

Platform Homogeneity– Single company owns, has technical capability, runs entire platform

end-to-end including an ecosystem– Most Web applications more homogeneous than traditional IT– With immense number of independent worldwide users

1% - 2% of all Internet requests

fail*

Users can’t tell difference between Internet down and

your system down

Hence 99% good enough

Fault-free operation via application middleware– Some type of failure every few hours, including software bugs– All hidden from users by fault-tolerant middleware– Means hardware, software doesn’t have to be perfect

Immense scale: – Workload can’t be held within 1 server, or within max size tightly-clustered

memory-shared SMP– Requires clusters of 1000s, 10000s of servers with corresponding PBs

storage, network, power, cooling, software– Scale of compute power also makes possible apps such as Google Maps,

Google Translate, Amazon Web Services EC2, Facebook, etc.

*The Data Center as a Computer: Introduction to Warehouse Scale Computing, p.81 Barroso, Holzlehttp://www.morganclaypool.com/doi/pdf/10.2200/S00193ED1V01Y200905CAC006

Internet scale Workload presentation by John Sing: http://www.slideshare.net/johnsing1/s-bd03-infinitybeyond2internetscaleworkloadsdatacenterdesignv6speaker

Return to “traditional IT vs. Internet scale wkload”



4343

Two major types of HA/DR/BC approaches depending on workload type:

Traditional IT Internet Scale Workloads

HA, Business Continuity, Disaster Recovery Characteristics

HA/DR/BC can be done “Agnostic / after the fact” using replication

HA/DR/BC is “designed into application software stack from the beginning”

Data Strategy Use traditional tools/concepts to understand / know data

Storage/server virtualization and pooling

Uses proven Open Source toolset to implement failure tolerance and redundancy in the application stack

Automation End to end automation of server / storage virtualization

End to end automation of the application software stack providing failure tolerance

Commonality Apply master vision and lessons learned from internet scale data centers

Apply master vision and lessons learned from internet scale data centers

Documents

© 2013 IBM Corporation IBM STG Servers and Storage within IBM's High Availability and Data Protection portfolio IBM STG Server and Storage Solutions John