System Recovery Boost
In this appendix, we introduce System Recovery Boost, which is a new function of the IBM z15. System Recovery Boost delivers substantially faster system shutdown and restart.
|
Note: System Recovery Boost is a new firmware feature and is available on z15 CPC. It is not available on older systems.
|
This appendix includes the following topics:
B.1 Overview
System Recovery Boost is a new feature that is implemented in z15 CPC firmware. It delivers improved overall system and application availability by minimizing the downtime that results from system shutdown and restart operations.
During a planned or unplanned system restart, System Recovery Boost realizes the following benefits:
•Shuts down the system substantially faster than any prior Z machine.
•Helps restart and recover the middleware environment and client workloads substantially faster than on any prior Z machine.
•Delivers higher processor capacity for a limited time following an IPL during a boost period so that the operating system can start faster and client workloads can catch up and work through a backlog after a downtime.
B.1.1 Use cases
System Recovery Boost provides value for many use cases, including the following examples:
•Single-system IPL (planned and unplanned):
– Planned or rolling IPLs (for example, to install software maintenance and disruptive system maintenance)
– Unplanned IPLs to recover after an operating system failure, crash or “sick but not dead” occurrence that required a system shutdown or restart
•Multi-system IPL (planned and unplanned)
– Restart all images on a CPC after planned CPC IML/POR (CPC non-concurrent upgrade)
– Restart all images on a CPC after unplanned CPC failure following a CPC IML/POR
– Bring back up sysplex after sysplex-wide (or sysplex multi-system) failure or crash or “sick but not dead” occurrence that required a sysplex shutdown or restart
•DR/Site Switch:
– Planned DR test, bringing up test systems at DR site
– Planned or unplanned site switch, bringing up systems at DR site
B.2 Functions
IBM Z Recovery boost is a new feature that was introduced with IBM z15 firmware (Driver 41), which is designed to provide higher temporary processing capacity to LPARs for speeding up shutdown, IPL, and stand-alone memory dump operations, without increasing IBM software costs.
By default, System Recovery Boost capacity is provided in the following ways:
•By converting subcapacity CPs to full-capacity CPs, also known as speed boost for the opted-in images1 during the boost period.
•By dispatching general-purpose workloads to zIIPs (for z/OS LPARs enabled for boost and with allocated zIIPs in the LPAR profile) during the boost period (zIIP boost).
•By way of firmware enhancements that support greater parallelism and performance improvements in the hardware API services. These enhancements are used by IBM GDPS to speed up the orchestration of shutdown and restart activities.
This support is available in GDPS V4.2 for workloads running on z15 CPCs.
The boost capacity does not contribute to other IBM software license charges.
Figure B-1 shows a typical System Recovery Boost timeline for z/OS.
|
Note: Timelines might differ for other operating systems.
|
Figure B-1 z/OS typical System Recovery Boost timeline
For z/OS, current implementation allows 60 minutes boost period for IPL and 30 minutes for shutdown events2. The 60 minutes boost period for IPL-ing the z/OS system also allow catching up with the backlog work.
For stand-alone memory dumps, the boost period extends to the duration of the event and it uses subcapacity CP speed boost only (no zIIPs).
B.3 Delivering extra capacity
This section describes the ways in which extra capacity is delivered for System Recovery Boost.
B.3.1 Subcapacity CPs speed boost
When the z15 is configured as a subcapacity model (4xx, 5xx and 6xx), LPARs that are running in a boost period can access the speed boost. This feature requires operating system opt-in and support.
At the time of this writing, IBM z/OS (2.3 and 2.4 with PTFs), IBM z/VM 7.1 with PTFs, and zTPF 1.1 with PTFs can use subcapacity boost.
|
Note: Speed boost applies to general-purpose processors (CPs) only. All other engines run at full capacity (IFLs, zIIPs, and ICFs).
|
Speed boost example
Figure B-2 shows an example of subcapacity CP speed boost.
Figure B-2 Subcapacity to full-capacity boost example
In this example, three LPARs are defined in the z15 model 403. In the normal operation, all work is dispatched on subcapacity CPs.
When LPARs enter a boost period, work that is dispatched from LPARz runs at CP7 (full capacity). Other LPARs continue to be dispatched at CP4 (subcapacity). One boost period started at LPARz shutdown and a new boost period started at IPL (of LPARz). At the end of the IPL boost period, LPARz returns to normal operation at CP4 (subcapacity).
B.3.2 zIIP processor capacity boost (zIIP boost)
Normally, only zIIP eligible work (such as DRDA and IBM Db2 Utilities) is dispatched to zIIPs. During System Recovery Boost period, both zIIP eligible and general CP work is dispatched to available zIIPs for the boost opt-in z/OS images (running in an LPAR).
|
Notes: Consider the following points:
•Currently, z/OS uses the zIIP boost feature.
•At least one zIIP entitlement must be available to use zIIP boost.
|
In this period, the system can use following processors to run CP workload:
•Entitled purchased CPs
•Entitled purchased zIIPs
•Extra zIIPs, which can be added by using the temporary boost capacity records (FC 9930 and FC 6802 on z15)
If more logical zIIPs are available and configured in the LPAR profile (whether added by way of the temporary boost capacity record or other temporary capacity activation) while in the boost period, images bring more logical zIIP processors online to use the extra physical zIIP capacity.
After the boost period ends, z/OS dispatching of work on CPs versus zIIPs returns to normal.
|
Important: These extra logical processors should be taken offline at the end of the boost period (either manually or by using automation), or they are taken offline automatically when the temporary boost record expires.
|
The start and end of the boost period is signaled by way of a console message, ENF signal (84), and cutting an SMF record. Also, the start and end of boost period starts new SMF interval. A system command or PROC (IEABE) is provided to allow for early opt-out of the boost, if wanted.
System Recovery Boost using zIIP boost example
Figure B-3 shows an example of recovery boost using zIIP capacity boost.
Figure B-3 Example of zIIP recovery boost (z/OS LPAR)
In this example, three LPARs are defined on the z15 model 703 with two zIIPs. Two zIIPs are shared between LPARy and LPARz.
During normal operation, only zIIP eligible work is dispatched to the zIIPs. When LPARz enters a boost period, general-purpose work and zIIP eligible work might be dispatched to the zIIPs.
When the boost period ends, only zIIPs-eligible work is dispatched to the zIIPs.
B.3.3 Optional System Recovery Boost Upgrade capacity record
You can temporarily increase the number of physical zIIPs to use for System Recovery Boost. This feature is the new System Recovery Boost Upgrade record that you can activate from the HMC/SE Perform Model Conversion menu, or by using automation that calls the hardware API services.
After it is activated, zIIPs are added to the zIIP pool and LPAR shares of the extra physical zIIP capacity follows normal LPAR weight rules. You can set up the LPAR image profiles in advance with extra logical zIIP processors to enable the effective use of the extra physical zIIP processor capacity.
Deactivate the temporary boost capacity record at the end of the IPL or shutdown actions or change windows for which they intend to provide a boost (the record auto-deactivates after 6 hours).
For systems that ordered the new System Recovery Boost Upgrade record, the zIIP:CP ratio of 2:1 can be exceeded during the boost periods for the boost opt-in images (LPARs). The boost record activates the zIIPs for up to 6 hours. The boost record has an expiration date of one year.
You must activate the boost record before a boost event.
Consider the following points regarding the optional System Recovery Boost Upgrade record:
•It is a priced feature.
•The subscription feature is valid for one year (must be renewed after one year).
•Each activation includes an entitled number of zIIPs, which can be up to 20 and might violate the 2:1 ratio rule between zIIPs and CPs.
•Activation of this record cannot cause the activation of the first or only zIIP on the machine; therefore, at least one entitled zIIP must be present.
Boost temporary capacity record example
Figure B-4 shows an example of the use the optional boost temporary capacity record.
Figure B-4 Example of boost using temporary capacity record
In this example, three LPARs are defined in the z15 model 703 with two zIIPs. Two zIIPs are assigned to both LPARy and LPARz. LPARy is in normal operation.
When LPARz is in a boost period; therefore, both general-purpose work and zIIP eligible work can be dispatched to the zIIPs. LPARz includes a reserved zIIP specified in its image profile.
By activating temporary boost capacity record, one zIIP is added to the zIIP pool and automatically allocated to the LPARz and brought online. In this boost period, general CP work for LPARz is dispatched to zIIPs and CPs.
B.3.4 Planned shutdown boost
A z/OS system can signal that it wants to enter a boost for a planned shutdown by starting the IEASDBS PROC. Consider the following points:
•In response to starting the PROC, which is driven manually or by way of automation, z/OS opts in to the allowed Boosts permitted by using parmlib.
•The start and end of the Boost period is signaled by way of a console message, ENF signal (84), and cutting an SMF record. The beginning and end of the boost period triggers new SMF interval.
In a sysplex, WLM sysplex routing starts to route work away from a system after the shutdown PROC is started to further accelerate shutdown.
All z/OS and middleware processing during the shutdown boost period benefits from higher capacity CP processors or extra parallelism that is provided by zIIPs and allows CP work to run on zIIPs.
Shutdown boost example
Figure B-5 shows an example of shutdown boost using subcapacity CP speed boost and zIIP capacity boost.
Figure B-5 Example of shutdown boost in a subcapacity model
In this example, three LPARs are defined in the z15 model 403 with two zIIPs. Two zIIPs are assigned to LPARy and LPARz. During normal operation, all CP work is dispatched at subcapacity (CP4). Only zIIP eligible work is dispatched to zIIPs.
|
Note: Stand-alone memory dump does not use zIIP for boost purposes.
|
Before the planned shutdown of LPARz, the IEASDBS proc is started by an operator or automation. This process starts the shutdown boost. CP work that is dispatched by LPARz is run at full-capacity (CP7) and also general-purpose workload is dispatched to zIIPs. LPARx and LPARy continue in the normal operation at subcapacity (CP4) and only zIIP-eligible workload is dispatched to zIIP.
B.3.5 IBM Geographically Dispersed Parallel Sysplex Actions Performance and Parallelism
IBM Geographically Dispersed Parallel Sysplex (GDPS) drives BCPii HW APIs for orchestrating CBU capacity activations, image activations, resets, and IPLs for multiple images in many planned and unplanned DR site-switch scenarios.3
Firmware changes on the z15 HMC and SEs support greater parallelism and performance improvements in the HW API services.
GDPS uses these changes to take advantage of available parallelism in the following underlying hardware services:
•GDPS usage that requires GDPS 4.2
•Firmware support that is delivered on the z15 machine
B.4 Setting up the System Recovery Boost
System Recovery Boost is a firmware feature of the z15 CPC for operating systems that are running in an LPAR, which requires operating system support.
|
Important: The base System Recovery Boost capability is built into z15 firmware and does not require ordering extra features. System Recovery Boost Upgrade (consisting of FC 9930 and FC 6802) is an optional, orderable feature that provides more temporary zIIP capacity for use during boost periods. Consider the following points:
•FC 9930 is not required to use the base System Recovery Boost capability.
•FC 9930 is only needed if more zIIP temporary capacity is required.
•By default, System Recovery Boost is enabled for z/OS (opt-in). z/OS must run on z15 CPC.
•For extra zIIP temporary boost capacity, FC 9930 and FC 6802 (System Recovery Boost Upgrade) must be ordered with the z15 CPC.
|
You can configure a z/OS system-level parameter (IEASYSxx) to control whether a specific z/OS image opts in for the zIIP processor Boost, as shown in the following example:
BOOST=SYSTEM | ZIIP | SPEED | NONE
No hardware configuration setup is required.
If you want to use offline zIIPs or extra zIIPs that are provided by the System Recovery Boost record, you must define reserved zIIPs in the image profile, as shown in Figure B-6 on page 499.
Figure B-6 Reserved zIIPs definition window in the image profile
You also should review LPAR weights and storage allocation to ensure that they meet your system requirements.
B.5 Monitoring System Recovery Boost
When an LPAR is in the Boost period, you can confirm the status of System Recovery Boost in the HMC/SE Partition Image Details window, as shown in Figure B-7. During the boost period, Processor Boost is shown as ON.
Figure B-7 HMC Partition Image Details window
Also, the processor boost status is shown in HMC Monitors Dashboard.
B.6 Automation
Your automation product can be used in the following ways to automate and control System Recovery Boost activities:
•To activate and deactivate the eBod temporary capacity record to provide extra physical zIIPs for an IPL or Shutdown Boost.
•To dynamically modify LPAR weights, as might be needed to modify or “skew” the sharing of physical zIIP capacity during a Boost period.
•To drive the invocation of the PROC that indicates the beginning of a shutdown process (and the start of the shutdown Boost).
•To take advantage of new composite hardware API reconfiguration actions.
•To control the level of parallelism present in the workload at start (for example, starting middleware regions) and shutdown (for example, perform an orderly shutdown of middleware).
Automation can pace or throttle these activities to varying degrees; with Boost, less pacing or more parallelism might be wanted.
•To automate on the new z/OS messages that are issued at start or end of boost periods to take whatever actions are needed.
B.7 Pricing
In this section, the available pricing options are described.
B.7.1 Base System Recovery Boost feature: No extra charge functions
The following standard, no-charge z15 hardware facilities are available:
•Subcapacity to full-capacity boost for CPs
•zIIP boost that uses a client’s entitled zIIPs
•GDPS scripting and firmware enhancements
B.7.2 Priced feature: System Recovery Boost Upgrade record
A charge function is a priced activation of extra zIIP capacity for boost usage. An annual subscription model for entitlement to renewals for zIIP Boost with activation of unassigned processor units (PUs) by way of temporary record also is available.
System Recovery Boost records on z15 require Boost Enablement contract (FC 9930) and temporary pre-paid zIIP boost records (FC 6802).
B.7.3 Software pricing
Boost should not increase a customers’ IBM software costs, regardless of whether the client is using 4HRA Pricing, Solution Pricing, or Consumption-based Pricing.
B.8 Software support
The following software is supported to use System Recovery Boost:
z/OS z/OS V2R4 with rollback to V2R3 with PTFs.
GDPS V4R2.
Stand-alone Dump Stand-alone memory dump (SADMP) uses subcapacity to full-capacity boost for CPs during memory dump processing (zIIP capacity boost is not used for SADMP).
z/VM When running on CP processors, z/VM LPAR uses subcapacity to full-capacity boost for CPs for startup and shutdown (IFLs always run at full capacity, no boost is available for IFLs).
Second-level guests of z/VM l “inherit” the subcapacity boost from VM during these periods, which accelerates the start and shutdown of hosted second-level guests (except for z/OS as a second-level guest).
z/TPF zTPF uses Speed Boost for CPs for start and shutdown boost. Existing support for a function (called TPF Dynamic CPU) can be used to provide more CP capacity when needed.
IBM z/VSE In the future4, IBM intends to deliver native z/VSE exploitation of System Recovery Boost, which is expected to enable restoration of service from, and catch up after, both planned and unplanned outages faster than on any prior Z machine.
1 Supported operating images are enabled for boost that is running in an LPAR.
2 Boost periods are operating system-specific. Different operating systems can feature different boost periods.
3 z/OS use requires z/OS 2.4 with rollback to 2.3 with PTFs (for subcapacity and zIIP boost, on z15 CPC).
4 Statements by IBM regarding its plans, directions, and intent are subject to change or withdrawal without notice at the sole discretion of IBM. Information regarding potential future products is intended to outline general product direction and should not be relied on in making a purchasing decision. The information mentioned regarding potential future products is not a commitment, promise, or legal obligation to deliver any material, code, or functionality. Information about potential future products may not be incorporated into any contract. The development, release, and timing of any future features or functionality described for IBM products remain at the sole discretion of IBM.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.