system z hardware – capacity on demand

IBM TGVL: System z Foundation

1 IBM Systems1Q2008 System z Hardware – Capacity on Demand

System z Hardware – Capacity on Demand

IBM System z

z10 EC z10 BC

Bob NeidigSystem z Executive Technology ConsultantzAtlas Team Member RACE Core Team MemberAG zChampions Technical [email protected] 1-914-766-2853



Evolution► Scalability and virtualization to

reduce cost and complexity► Improved efficiency to further

reduce energy consumption► Improved security and resiliency

to reduce risk► New heights in storage scalability

and data protection

Revolution► 4.4 GHz chip to deliver improved

performance for CPU intensive workloads

► ‘Just in time’ deployment of capacity resources

► Vision to expand System z capabilities with Cell Broadband Engine™ technology

Introducing the IBM System z10™ Enterprise Class (z10™ EC) … A marriage of evolution and revolution



z10 CoD Offerings On-line Permanent Upgrade

► Permanent upgrade performed by customer (previously referred to Customer Initiated Upgrade - CIU) Capacity Backup (CBU)

► For disaster recovery► Concurrently add CPs, IFLs, ICFs, zAAPs, zIIPs, SAPs► Pre-paid

Capacity for Planned Event (CPE)► To replace capacity for short term lost within the enterprise due to a planned event such as a facility

upgrade or system relocation► Predefined capacity for a fixed period of time (3 days)► Pre-paid

On/Off Capacity on Demand (On/Off CoD) ► Production Capacity► Supported through software offering – Capacity Provisioning Manager (CPM)► Payment:

● Post-paid or Pre-paid by purchase of capacity tokens● Post-paid with unlimited capacity usage● On/Off CoD records and capacity tokens configured on Resource Link

Customer Initiated Upgrade (CIU)► Process/tool for ordering temporary and permanent upgrades via Resource Link► Permanent upgrade support:

● Un-assignment of currently active capacity● Reactivation of unassigned capacity● Purchase of all PU types physically available but not already characterized ● Purchase of installed but not owned memory



Customer defined policy or manual operations

HMC

APIquery, activate, deactivate

Authorization Layer

R1 R2 R3 R4

Dormant Capacity

CIU - CBU – On/Off CoD – CPE

PermanentCapacity* Capacity Provisioning available with

z/OS v1.9

Enforce terms and conditions

Enforce physical model limitations

Up to 4 temporary capacity offerings Each record represents an individual

offering Customer assigns in any combination

Base model

Change permanent capacity via MES order

SEHard Drive

Orders downloadedfrom System Support electronically or by IBM Service

Capacity Provisioning

Manager *

On demand simplifiedNew architectural approach for capacity



Capacity Provisioning - ESP Customer Feedback



z10 – Basics of CoD

On/Off CoD with tokensNo expirationCapacity - MSU % - # EnginesTokens - MSU days - Engine days

Permanent Upgrade

Pre-paidCBU CPE

On/Off CoD with tokens180 days expirationCapacity - MSU % - # EnginesTokens - MSU days - Engine days

On/Off CoD 180 days expirationCapacity - MSU % - # Engines

Using pre-paid unassigned capacity up to the limit of the HWMNo expirationCapacity - MSU % - # Engines

Capacity on Demand

Temporary Upgrade

Replacement Capacity Billable Capacity(On/Off CoD)

Post-paid



z10 CoD – Removal of limitations A permanent upgrade cannot occur while CBU or On/Off CoD is active Only one solution can be active at a time

► Either CBU or On/Off Capacity on Demand● A disaster (CBU) could occur while On/Off CoD is active

Limited to the permanent capacity► After a permanent capacity upgrade, the old temporary contract may become

useless Cannot add temporary capacity while a Concurrent Book Add is in progress (z10

EC) Need for a CBU-like offering where a disaster is not involved When On/Off CoD or CBU records were activated/deactivated, all processors

defined in those records must be activated/deactivated The HMC requires connectivity to the IBM Support System to obtain temporary

records or verify passwords at the time of activation► HMC connectivity or response time is a potential inhibitor► The process to activate/deactivate On/Off CoD can take too long

Software Billing needs to be able to determine which capacity is permanent versus temporary



z10 CoD – New architecture Resources can be activated in any

amount up to defined limit

► Customer can customize activation real-time, based on circumstances

► Eliminates unique record to be managed for all possible permutations

► Dynamic changes in activation level without reloading records

As records expire or are consumed, the resources will be deactivated

► System will not reduce to sub capacity when records expire

► Will not deactivate if removing dedicated engines or last of that engine type

Various record limits can be dynamically updated / replenished

► Changes possible even if record is currently active

Ability to perform permanent upgrades while temporary capacity is active

► Allows quick conversion of temporary capacity to permanent

Pre-paid resource consumption and capacity liability capping done at the server

API enhancements to support use by Capacity Provisioning Manager

► Capacity Provisioning Manager provides policy based automation



z10 CoD – Key Enhancements All offering records are resident on machine

► No connection or passwords required at time of activation

► Records are changed only when customer places order for new / updated offering

Multiple records can be simultaneously active

► Each has independent controls and policy

► Each can be activated / deactivated in any sequence

Individual record can be used to temporarily reach multiple configurations

► Customer determines level of resources activation real time based on circumstances (i.e. multiple use for a single On/Off CoD record, even during a permanent upgrade)

► All movement between configurations is concurrent

More flexibility to configure offering limits

Ability to perform upgrades while temporary resources are active

► Modification of record entitlement performed dynamically and concurrently

“Capacity Provisioning Manager” provides policy based advice and automation



System z9 System z10

Resources CP, zIIP, zAAP, IFL, ICF CP, zIIP, zAAP, IFL, ICF, SAP

Offerings Requires access to IBM/RETAIN® to activate

No password required or access to IBM/RETAIN to activate

CBU, On/Off CoD CBU, On/Off CoD, CPE

One offering at a time Multiple offerings active

Permanent upgrades Requires de-provisioning of temporary capacity first

Concurrent with temporary offerings

Replenishment No Yes with CBU & On/Off CoD

CBU Tests 5 tests per record 5 (default), 10, or 15 tests per record

CBU expiration No expiration Specific term length

Capacity Provisioning Manager support

No Yes

Capacity on Demand Comparisons – z9 vs z10



Base Model

Dormant Capacity

Purchased Capacity

Change permanent capacity via CIU or MES order

Up to 8 records installed and active on the System and up to 200 records staged on the SE

Enforce Terms and Conditions and physical model limitations

Orders downloaded from Retain/media to SE hard driveCustomer defined policy

or user commands

CPM (z/OS 1.9 or higher)

APIHMC application

Query Activation

Authorization Layer

Manual operations

z10 CoD Provisioning Architecture

* Only one On/Off CoD record can be active

CBU – CPE – On/Off CoD

R1* R2* R3* R4* R5* R6* R7* R8*



Order process limitsOrder process limits

Machine limitsMachine limits

Contract terms and conditionsContract terms and conditions

Replenishments

z10 COD Elements of the Offerings

Resources Time Elements Tokens



Offering Parameters – 3 ways of handling1. Resources

► Limit the amount of a particular resource that can be activated

► Absolute number which represents maximum resource entitlement

► Activation to resource limits may not be achieved depending on current configuration

► e.g. #CPs, #IFLs, #Capacity levels

2. Time Elements

► Limit the length of time that the record can be active; full or partial (applies to all record types)

► All time limits are measured in days or calendar date

► Absolute number which represents maximum time entitlement

► e.g. Number of days in test, Number of days in real activation, calendar date

3. Tokens

► Means of controlling ‘spending’ limits for On/Off CoD

► Consumable – record updated each 24 hours to reflect consumption level

► Values are treated as incremental delta to the current token level

► e.g. number of tests, number of real activations

► MSU days (for CPUs) / processor days (for specialty engines)

NOTE: Negative updates to these limits are not allowed



Resources CBU CPE On/Off CoD Remarks

CP CP CPup to 100% more MSU CP capacity

Specialty zIIP, zAAP, ICF, IFL, SAP

Time Elements CBU CPE On/Off CoD Remarks

Test Duration 10 days NA NA

Real activations 90 days 3 days Post-paid – Unlimited

Prepaid – Limited

Grace Period 2 days N/A One hour

Auto deactivation upon end of grace period

Expiration Date 1-5 years No Expire 180 daysAuto deactivation upon expiration

Tokens CBU CPE On/Off CoD Remarks

Number of test 5,10 or 15 0 1 On/Off CoD tests are managed via a separate record

Number of real activation

1 1Post-paid – Unlimited

Prepaid – Limited

z10 Resources, Time elements and Tokens Summary



Contract terms and conditionsContract terms and conditionsTo be used only for replacement capacity within an enterprisePriced for H/W. No additional IBM S/W charges

Machine limitsMachine limits Can not decrement capacity level Can not remove permanent engines from configuration No Tests while in Real activation No Tests if number of Real activations equals zero Auto deactivation of activated resources upon time limit

‒If any resource can not be removed all resources stay active‒Ability to remove resources checked every 24 hours.

Order process limitsOrder process limits Total CP Capacity features = number of net new engines + number of permanent engines changing

capacity level‒No limit to the resources ordered

Number of zIIPs or zAAPs can not exceed total number of permanent + temporary CPs No more than 15 tests per record

z10 Capacity Back Up – CBU

Resources

CP Capacity FeaturesSpecialty engines:zIIP, zAAP, ICF, IFL, SAP

Time elements

Test duration = 10 daysReal activation = 90 days2 day grace periodExpiration date set to 1 through 5 years

Tokens

Number of Tests = 5 (default)Up to 15 can be orderedNumber of Real activations = 1



CBU Comparison – z9 versus z10

z9 z10

Granularity All on / All off Granular

Customer exceeds terms Reduce machine capacity Removed automatically, if possible

End of term CBU record does not expire CBU record expires

Number of CBU orders Buy one, apply one Buy many, apply many

Number of Tests 5 5-15

Terms Usually 5 years Variable, 1-5 years



Order process limitsOrder process limits No more than 1 real activation per record

Machine limitsMachine limits Can not decrement capacity level Can not remove permanent engines from configuration Auto deactivation of activated resources upon time limit

‒If any resource can not be removed all resources stay active‒Ability to remove resources checked every 24 hours

All dormant resources are available for use during the activation

Contract terms and conditionsContract terms and conditions To be used only for replacement capacity within an enterprise Priced for H/W use BUT like CBU, no additional IBM S/W charges

z10 Capacity for Planned Event

Resources

CP Capacity FeaturesSpecialty engines:zIIP, zAAP, ICF, IFL, SAP

Time elements

Test duration = NAReal activation = 3 daysNo grace periodNo Expiration date

Tokens

Number of Tests = 0Number of Real activations = 1



z10 Capacity for Planned Event (1)

Replacement Capacity

► Replaces lost capacity within a customer’s enterprise for planned down time events

● Push/Pull planned outages● Planned Data Center moves and relocations

CP capacity details are NOT managed by feature codes

► Any available and dormant resources may be used

Normal specialty engine rules are not managed/enforced for activation

► For example,

● One CP required for each zIIP and zAAP (1 zIIP + 1 zAAP per 1 CP permitted)

– Not enforced



Order process limitsOrder process limits Temporary CP capacity up to 100% or purchased capacity using MSU rating as metric Number of temporary zIIPs or zAAPs can not exceed total number of permanent + temporary CPs Number of temporary IFLs up to the total of purchased IFLs Number of temporary ICFs plus permanent ICFs not to exceed 16

Machine limitsMachine limits Can not decrement capacity level. Positive increase in speed steps (processor speed) required Can not remove permanent engines from configuration Positive increase in MSUs with temporary activations

Contract terms and conditionsContract terms and conditions H/W and S/W chargesAllows 1 x 24 Hour test record per machine registered

z10 On/Off Capacity on Demand

Resources

CP Capacity % MSUSpecialty engines:zIIP, zAAP, ICF, IFL, SAP

Time elements

Test duration = NAReal activation = Unlimited1 hr grace periodExpiration date set to 180 days

Tokens

Number of Tests = 0Number of Real activations = UnlimitedMSU days.Limit Tokens: MSU days, per type Specialty Engines day



z10 On/Off CoD Terms Definition

Billing Window► 24 hour billing period ► billing is done based on peak usage of resources within this period ► billing is done at the end of each billing window

Activation Period► Consists of one or more full billing windows► Time from first activation of any resource of a record until the end of the

billing window where the last resource of this record was deactivated

Grace Period ► Grace time at beginning and end of each billing window to protect customer

from being charged for an entire billing window if he increases the activation levels a little too early or deactivates his resources a little too late

► Default set to 60 minutes per order process – but could be any other number ● 1 hour after start of billing window: post-grace-period ● 1 hour prior end of billing window: pre-grace-period

► Attention! No grace period at start of first billing window in an activation period !!



Capacity Upgrade on Demand (CUoD)*

Capacity BackUp (CBU)*

Customer Initiated Upgrade (CIU)* -

for ordering

On/Off Capacity on Demand (On/Off CoD)*

Capacity for Planned Event

(CPE)*

Permanent capacity upgrade; a standard System z10 feature that allows you to order extra capacity resources such as processors, memory, and I/O

Reserve backup PU capacity (CP, ICF, IFL, zAAP or zIIP, SAP) for specified duration; original configuration must be restored after test or disaster recovery

Facility for ordering, configuring, pricing and installing capacity upgrades. It is a Web-based solution available through Resource Link

Temporary capacity upgrade (CP, ICF, IFL, zAAP, zIIP, SAP) of unlimited duration; orderable through CIU; customer activates and deactivates.

Replacement backup PU capacity (CP, ICF, IFL, zAAP,, zIIP, SAP) for a maximum of 3 days; original configuration must be restored after planned event recovery

Available on LIC enabled System z10

Available on System z10 Available on LIC enabled System z10

Available on System z10 Available on System z10

Inherent capability of System z10 servers; spare processors, memory and/or I/O slots must be available

A CBU contract must be in place prior to implementation and reserve PUs available for test or disaster recovery

A CIU contract must be in place prior to implementation

A CIU contract with special On/ Off CoD terms and conditions and right-to-use feature must be in place prior to implementation

A CPE contract must be in place prior to implementation and reserve PUs available for planned event

Capacity upgrade Installed by customer or IBM Service representative

Capacity reserve installed by customer for predetermined period of use

CIU contract and registration required to use CIU application to order capacity

Feature ordered through IBM Sales; once enacted, customer orders temporary CP, ICF, IFL, zAAP or zIIP upgrade through CIU

Capacity installed by customer

Customer or IBM planning required

Customer or IBM planning required

Customer planning required

Customer planning required Customer planning required

With pre-planning, nondisruptive capacity activation on System z10

Nondisruptive capacity activation on System z10

Ordering facility available with the System z10

Nondisruptive temporary CP, ICF, IFL, zAAP or zIIP upgrade; customer deactivates

Nondisruptive capacity activation System z10

Priced upgrades Priced offering for H/W Priced upgrades Both H/W and IBM S/W priced Priced offering for H/W

* Additional terms and conditions apply

Note: Upgrades are nondisruptive only where there is sufficient hardware resource available and provided pre-planning has been done

System z10 Capacity on Demand Summary



Capacity on Demand Server

Capacity BackUp z10 EC, z9 EC, z9 BC, z990, z890, z900, z800

Capacity Upgrade on Demand z10 EC, z9 EC, z9 BC, z990, z890, z900, z800

Customer Initiated Upgrade z10 EC, z9 EC, z9 BC, z990, z890, z900, z800

On/Off Capacity on Demand z10 EC, z9 EC, z9 BC, z990, z890

Capacity for Planned Event z10 EC, z10 BCCapacity BackUp

Capacity Upgrade on Demand

Customer Initiated Upgrade – for ordering

On/Off Capacity on Demand

Capacity for Planned Event

z900Yes (CP only) Yes (CP, I/O, IFL, ICF,

Memory)Yes (CP, IFL, ICF, Memory)

No No

z800 Yes (CP only) Yes (CP, I/O, IFL, ICF) Yes (CP, IFL, ICF) No No

z890/z990 Yes (CP only) Yes (CP, I/O, IFL, ICF, zAAP, Memory*)

Yes (CP, IFL, ICF, zAAP, Memory*)

Yes (CP, IFL, ICF, zAAP)

No

z9Yes (CP, ICF, IFL zAAP, zIIP)

Yes (CP, I/O, IFL, ICF, zAAP, zIIP, Memory*)

Yes (CP, IFL, ICF, zAAP, zIIP, Memory*)

Yes (CP, IFL, ICF, zAAP, zIIP)

No

z10 Yes (CP, ICF, IFL zAAP, zIIP, SAP)

Yes (CP, I/O, IFL, ICF, zAAP, zIIP, SAP, Memory*)

Yes (CP, IFL, ICF, zAAP, zIIP, SAP, Memory*)

Yes (CP, IFL, ICF, zAAP, zIIP, SAP)

Yes (CP, IFL, ICF, zAAP, zIIP SAP)* Not supported for some memory upgrades

Note: Upgrades are nondisruptive only where there is sufficient hardware resource available and provided pre-planning has been done

System z Capacity Resource Availability by Server



Learning Points – System z Capacity on DemandOn-line Permanent Upgrade

Permanent upgrade performed by customer (previously referred to Customer Initiated Upgrade - CIU)

Capacity Backup (CBU)

For disaster recovery

Concurrently add CPs, IFLs, ICFs, zAAPs, zIIPs, SAPs

Pre-paid

Capacity for Planned Event (CPE)

To replace capacity for short term lost within the enterprise due to a planned event such as a facility upgrade or system relocation

Predefined capacity for a fixed period of time (3 days)

Pre-paid

On/Off Capacity on Demand (On/Off CoD)

Production Capacity

Supported through software offering – Capacity Provisioning Manager (CPM)

Payment:

Post-paid or Pre-paid by purchase of capacity tokens

Post-paid with unlimited capacity usage

On/Off CoD records and capacity tokens configured on Resource Link

Customer Initiated Upgrade (CIU)

Process/tool for ordering temporary and permanent upgrades via Resource Link

Permanent upgrade support:

Un-assignment of currently active capacity

Reactivation of unassigned capacity

Purchase of all PU types physically available but not already characterized

Purchase of installed but not owned memory



zEND

Thank you !

Bob Neidig

[email protected]

system z hardware – capacity on demand

Documents