IBM TGVL: System z Foundation System z Hardware – Capacity on Demand Bob Neidig System z Executive Technology Consultant z. Atlas Team Member RACE Core Team Member AG z. Champions Technical Lead neidig@us. ibm. com 1 -914 -766 -2853 IBM System z z 10 EC 1 1 Q 2008 System z Hardware – Capacity on Demand z 10 BC IBM Systems
IBM TGVL: System z Foundation Introducing the IBM System z 10™ Enterprise Class (z 10™ EC) … A marriage of evolution and revolution 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 ► 2 Revolution 1 Q 2008 System z Hardware – Capacity on Demand ► 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 IBM Systems
IBM TGVL: System z Foundation z 10 Co. D 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, z. AAPs, z. IIPs, 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 Co. D) ► 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 Co. D 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 ► 3 1 Q 2008 System z Hardware – Capacity on Demand IBM Systems
IBM TGVL: System z Foundation On demand simplified Orders downloaded from System Support electronically or by IBM Service New architectural approach for capacity Customer defined policy or manual operations Capacity Provisioning Manager * SE Hard Drive HMC API query, activate, deactivate § Enforce terms and conditions § Enforce physical model limitations Authorization Layer R 1 R 2 R 3 R 4 Dormant Capacity CIU - CBU – On/Off Co. D – CPE * Capacity Provisioning available with z/OS v 1. 9 4 1 Q 2008 System z Hardware – Capacity on Demand Permanent Capacity § 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 IBM Systems
IBM TGVL: System z Foundation Capacity Provisioning - ESP Customer Feedback 5 1 Q 2008 System z Hardware – Capacity on Demand IBM Systems
IBM TGVL: System z Foundation z 10 – Basics of Co. D Capacity on Demand Permanent Upgrade Temporary Upgrade Billable Capacity (On/Off Co. D) Replacement Capacity CBU Using pre-paid unassigned capacity up to the limit of the HWM No expiration Capacity - MSU % - # Engines 6 CPE On/Off Co. D with tokens No expiration Capacity - MSU % - # Engines Tokens - MSU days - Engine days Prepaid On/Off Co. D 180 days expiration Capacity - MSU % - # Engines 1 Q 2008 System z Hardware – Capacity on Demand Post-paid On/Off Co. D with tokens 180 days expiration Capacity - MSU % - # Engines Tokens - MSU days - Engine days IBM Systems
IBM TGVL: System z Foundation z 10 Co. D – Removal of limitations § A permanent upgrade cannot occur while CBU or On/Off Co. D 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 Co. D 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 (z 10 EC) Need for a CBU-like offering where a disaster is not involved When On/Off Co. D 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 Co. D can take too long Software Billing needs to be able to determine which capacity is permanent versus temporary ► § § § 7 1 Q 2008 System z Hardware – Capacity on Demand IBM Systems
IBM TGVL: System z Foundation z 10 Co. D – New architecture § Resources can be activated in any amount up to defined limit ► Eliminates unique record to be managed for all possible permutations dynamically updated / replenished Customer can customize activation real-time, based on circumstances ► § Various record limits can be ► Dynamic changes in activation level without reloading records § As records expire or are consumed, ► 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 the resources will be deactivated capacity liability capping done at the server System will not reduce to sub capacity when records expire § API enhancements to support use by ► ► 8 Capacity Provisioning Manager Will not deactivate if removing dedicated engines or last of that engine type 1 Q 2008 System z Hardware – Capacity on Demand ► Capacity Provisioning Manager provides policy based automation IBM Systems
IBM TGVL: System z Foundation z 10 Co. D – 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 Co. D 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 9 1 Q 2008 System z Hardware – Capacity on Demand IBM Systems
IBM TGVL: System z Foundation Capacity on Demand Comparisons – z 9 vs z 10 System z 9 System z 10 Resources CP, z. IIP, z. AAP, IFL, ICF, SAP Offerings Requires access to IBM/RETAIN® to activate No password required or access to IBM/RETAIN to activate CBU, On/Off Co. D, 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 Co. D 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 10 CP, z. IIP, z. AAP, IFL, ICF No Yes 1 Q 2008 System z Hardware – Capacity on Demand IBM Systems
IBM TGVL: System z Foundation z 10 Co. D Provisioning Architecture Customer defined policy or user commands Manual operations CPM (z/OS 1. 9 or higher) API HMC application Query * Only one On/Off Co. D record can be active Activation R 2* R 3* R 4* R 5* R 6* CBU – CPE – On/Off Co. D Base Model 11 Enforce Terms and Conditions and physical model limitations Authorization Layer R 1* Orders downloaded from Retain/media to SE hard drive R 7* R 8* Dormant Capacity Purchased Capacity 1 Q 2008 System z Hardware – Capacity on Demand Up to 8 records installed and active on the System and up to 200 records staged on the SE Change permanent capacity via CIU or MES order IBM Systems
IBM TGVL: System z Foundation z 10 COD Elements of the Offerings Replenishments Resources Time Elements Tokens Order process limits Machine limits Contract terms and conditions 12 1 Q 2008 System z Hardware – Capacity on Demand IBM Systems
IBM TGVL: System z Foundation Offering Parameters – 3 ways of handling 1. 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 Co. D ► 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 13 1 Q 2008 System z Hardware – Capacity on Demand IBM Systems
IBM TGVL: System z Foundation z 10 Resources, Time elements and Tokens Summary Resources CBU On/Off Co. D CP CP CPE CP up to 100% more MSU CP capacity Specialty Remarks z. IIP, z. AAP, ICF, IFL, SAP Time Elements CBU CPE On/Off Co. D Test Duration 10 days NA NA Real activations 90 days 3 days Remarks Post-paid – Unlimited Prepaid – Limited 2 days N/A One hour Auto deactivation upon end of grace period 1 -5 years No Expire 180 days Auto deactivation upon expiration CBU CPE On/Off Co. D Remarks Number of test 5, 10 or 15 0 1 On/Off Co. D tests are managed via a separate record Number of real activation 1 1 Post-paid – Unlimited Grace Period Expiration Date Tokens 14 Prepaid – Limited 1 Q 2008 System z Hardware – Capacity on Demand IBM Systems
IBM TGVL: System z Foundation z 10 Capacity Back Up – CBU Resources Time elements Tokens CP Capacity Features Specialty engines: z. IIP, z. AAP, ICF, IFL, SAP Test duration = 10 days Real activation = 90 days 2 day grace period Expiration date set to 1 through 5 years Number of Tests = 5 (default) Up to 15 can be ordered Number of Real activations = 1 Order 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 z. IIPs or z. AAPs can not exceed total number of permanent + temporary CPs § No more than 15 tests per record Machine 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. Contract terms and conditions §To be used only for replacement capacity within an enterprise §Priced for H/W. No additional IBM S/W charges 15 1 Q 2008 System z Hardware – Capacity on Demand IBM Systems
IBM TGVL: System z Foundation CBU Comparison – z 9 versus z 10 z 9 z 10 Granularity 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 16 All on / All off Usually 5 years Variable, 1 -5 years 1 Q 2008 System z Hardware – Capacity on Demand IBM Systems
IBM TGVL: System z Foundation z 10 Capacity for Planned Event Resources Time elements Tokens CP Capacity Features Specialty engines: z. IIP, z. AAP, ICF, IFL, SAP Test duration = NA Real activation = 3 days No grace period No Expiration date Number of Tests = 0 Number of Real activations = 1 Order process limits § No more than 1 real activation per record Machine 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 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 17 1 Q 2008 System z Hardware – Capacity on Demand IBM Systems
IBM TGVL: System z Foundation z 10 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 z. IIP and z. AAP (1 z. IIP + 1 z. AAP per 1 CP permitted) – Not enforced 18 1 Q 2008 System z Hardware – Capacity on Demand IBM Systems
IBM TGVL: System z Foundation z 10 On/Off Capacity on Demand Resources Time elements Tokens CP Capacity % MSU Specialty engines: z. IIP, z. AAP, ICF, IFL, SAP Test duration = NA Real activation = Unlimited 1 hr grace period Expiration date set to 180 days Number of Tests = 0 Number of Real activations = Unlimited MSU days. Limit Tokens: MSU days, per type Specialty Engines day Order process limits § Temporary CP capacity up to 100% or purchased capacity using MSU rating as metric § Number of temporary z. IIPs or z. AAPs 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 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 conditions § H/W and S/W charges §Allows 1 x 24 Hour test record per machine registered 19 1 Q 2008 System z Hardware – Capacity on Demand IBM Systems
IBM TGVL: System z Foundation z 10 On/Off Co. D 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 ► ► ► 20 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 !! 1 Q 2008 System z Hardware – Capacity on Demand IBM Systems
IBM TGVL: System z Foundation System z 10 Capacity on Demand Summary Capacity Upgrade on Demand (CUo. D)* Capacity Back. Up (CBU)* Customer Initiated Upgrade (CIU)* for ordering On/Off Capacity on Demand (On/Off Co. D)* Capacity for Planned Event (CPE)* Permanent capacity upgrade; a standard System z 10 feature that allows you to order extra capacity resources such as processors, memory, and I/O Reserve backup PU capacity (CP, ICF, IFL, z. AAP or z. IIP, 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 Webbased solution available through Resource Link Temporary capacity upgrade (CP, ICF, IFL, z. AAP, z. IIP, SAP) of unlimited duration; orderable through CIU; customer activates and deactivates. Replacement backup PU capacity (CP, ICF, IFL, z. AAP, , z. IIP, SAP) for a maximum of 3 days; original configuration must be restored after planned event recovery Available on LIC enabled System z 10 Available on System z 10 Inherent capability of System z 10 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 Co. D 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, z. AAP or z. IIP upgrade through CIU Capacity installed by customer Customer or IBM planning required Customer planning required With pre-planning, nondisruptive capacity activation on System z 10 Nondisruptive capacity activation on System z 10 Ordering facility available with the System z 10 Nondisruptive temporary CP, ICF, IFL, z. AAP or z. IIP upgrade; customer deactivates Nondisruptive capacity activation System z 10 Priced upgrades Priced offering for H/W Priced upgrades Both H/W and IBM S/W priced Priced offering for H/W Note: Upgrades are nondisruptive only where there is sufficient hardware resource available and provided pre-planning has been done * Additional terms and conditions apply 21 1 Q 2008 System z Hardware – Capacity on Demand IBM Systems
IBM TGVL: System z Foundation System z Capacity Resource Availability by Server Capacity on Demand Server Capacity Back. Up z 10 EC, z 9 BC, z 990, z 890, z 900, z 800 Capacity Upgrade on Demand z 10 EC, z 9 BC, z 990, z 890, z 900, z 800 Customer Initiated Upgrade z 10 EC, z 9 BC, z 990, z 890, z 900, z 800 On/Off Capacity on Demand z 10 EC, z 9 BC, z 990, z 890 Capacity for Planned Event z 10 EC, z 10 BC Capacity Upgrade Customer Initiated Back. Up on Demand Upgrade – for ordering On/Off Capacity on Demand Capacity for Planned Event Yes (CP only) Yes (CP, I/O, IFL, ICF, Memory) Yes (CP, IFL, ICF, Memory) No No z 800 Yes (CP only) Yes (CP, I/O, IFL, ICF) Yes (CP, IFL, ICF) No No z 890/z 990 Yes (CP only) Yes (CP, I/O, IFL, ICF, z. AAP, Memory*) Yes (CP, IFL, ICF, z. AAP) No Yes (CP, ICF, IFL z. AAP, z. IIP) Yes (CP, I/O, IFL, ICF, z. AAP, z. IIP, Memory*) Yes (CP, IFL, ICF, z. AAP, z. IIP) No z 900 z 9 Yes (CP, ICF, Yes (CP, I/O, IFL, ICF, Yes (CP, IFL z. AAP, z. IIP, SAP, ICF, z. AAP, z. IIP, * 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 z. IIP, SAP) Memory*) SAP) z 10 22 1 Q 2008 System z Hardware – Capacity on Demand Yes (CP, IFL, ICF, z. AAP, z. IIP SAP) IBM Systems
IBM TGVL: System z Foundation Learning Points – System z Capacity on Demand 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, z. AAPs, z. IIPs, 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 Co. D) 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 Co. D 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 23 1 Q 2008 System z Hardware – Capacity on Demand IBM Systems
IBM TGVL: System z Foundation z. END Thank you ! Bob Neidig neidig@us. ibm. com 24 1 Q 2008 System z Hardware – Capacity on Demand IBM Systems
Скачать презентацию IBM TGVL System z Foundation System z Hardware
0e6182bfa7cbd88059f189f224304fbd.ppt