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
IBM TGVL: System z Foundation
2 IBM Systems1Q2008 System z Hardware – Capacity on Demand
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
IBM TGVL: System z Foundation
3 IBM Systems1Q2008 System z Hardware – Capacity on Demand
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
IBM TGVL: System z Foundation
4 IBM Systems1Q2008 System z Hardware – Capacity on Demand
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
IBM TGVL: System z Foundation
5 IBM Systems1Q2008 System z Hardware – Capacity on Demand
Capacity Provisioning - ESP Customer Feedback
IBM TGVL: System z Foundation
6 IBM Systems1Q2008 System z Hardware – Capacity on Demand
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
IBM TGVL: System z Foundation
7 IBM Systems1Q2008 System z Hardware – Capacity on Demand
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
IBM TGVL: System z Foundation
8 IBM Systems1Q2008 System z Hardware – Capacity on Demand
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
IBM TGVL: System z Foundation
9 IBM Systems1Q2008 System z Hardware – Capacity on Demand
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
IBM TGVL: System z Foundation
10 IBM Systems1Q2008 System z Hardware – Capacity on Demand
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
IBM TGVL: System z Foundation
11 IBM Systems1Q2008 System z Hardware – Capacity on Demand
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*
IBM TGVL: System z Foundation
12 IBM Systems1Q2008 System z Hardware – Capacity on Demand
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
IBM TGVL: System z Foundation
13 IBM Systems1Q2008 System z Hardware – Capacity on Demand
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
IBM TGVL: System z Foundation
14 IBM Systems1Q2008 System z Hardware – Capacity on Demand
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
IBM TGVL: System z Foundation
15 IBM Systems1Q2008 System z Hardware – Capacity on Demand
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
IBM TGVL: System z Foundation
16 IBM Systems1Q2008 System z Hardware – Capacity on Demand
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
IBM TGVL: System z Foundation
17 IBM Systems1Q2008 System z Hardware – Capacity on Demand
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
IBM TGVL: System z Foundation
18 IBM Systems1Q2008 System z Hardware – Capacity on Demand
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
IBM TGVL: System z Foundation
19 IBM Systems1Q2008 System z Hardware – Capacity on Demand
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
IBM TGVL: System z Foundation
20 IBM Systems1Q2008 System z Hardware – Capacity on Demand
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 !!
IBM TGVL: System z Foundation
21 IBM Systems1Q2008 System z Hardware – Capacity on Demand
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
IBM TGVL: System z Foundation
22 IBM Systems1Q2008 System z Hardware – Capacity on Demand
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
IBM TGVL: System z Foundation
23 IBM Systems1Q2008 System z Hardware – Capacity on Demand
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
IBM TGVL: System z Foundation
24 IBM Systems1Q2008 System z Hardware – Capacity on Demand
zEND
Thank you !
Bob Neidig
Top Related