Download PDF - IBM Redbooks

Table B-3 Recovery objective
Type of outage Recovery time
objective (downtime)
Component failure (hardware, software,
and network
2 business hours 30 minutes
Total outage is more than 1 day 48 hours 8 hours
Recovery period
objective (data at risk)
Solution
By applying Quick Sizer results and the sizing estimate from IBM Techline, we determined
that we need a z196-702 with two central processors (CPs), one zIIP for the database server
load, and 11 IFLs for the SAP NetWeaver AS load.
Additional information: You can find the IBM Sizing and Planning Questionnaire for SAP
Solutions at:
http://www.ibm.com/support/techdocs/atsmastr.nsf/PubAllNum/PRS261
For more information about using the SAP Quick Sizer, see “Questions for users of the
SAP QuickSizer” at:
http://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/PRS2294
To size the LPARs, give the production instances more memory than the minimum
recommended by the Quick Sizer, because clients have experienced that memory proposed
by Quick Sizer is conservative. However, development and QA instances can use the Quick
Sizer recommendations.
Because this system is new, we cannot estimate how much the processor is being used
during production. Also the development systems might be more active during the SAP
application customization and introduction phase. Therefore, we decided to share the
processors between the production, development, and quality assurance instances for now.
We might have to adjust the LPAR resources after the system workload settles, which is a
good practice, because every client will have an individual SAP workload pattern. In
particular, if SAP transactions or jobs were created or changed by LOB consultants, they
often affect workload performance.
For system recovery, we implement SCS in the z/OS LPAR to decouple it from the application
server host. Also, this approach prepares the system if the client implements Parallel Sysplex
data sharing and HA later. For data loss protection, use Metro Mirror to back up the DB2 log
and data and to enable storage FlashCopy to use the DB2 BACKUP/RESTORE DATABASE utility,
point-in-time recovery, and federated synchpointing of the applications.
We designed four hosting LPARs: two for the database servers and two for the application
servers. One pair of database servers and application servers is dedicated to production. The
other pair hosts the development and QA instances. The database server partitions run each
DB2 subsystem and one database instance per SAP application instance. Also one SCS
instance is available per SAP database server instance in these LPARs. The application
server LPARS are managed by z/VM as the host operating system. We have two application
servers per production application, and one application per development and per QA
application and instance. The exception is the Solution Manager, which has one application
server central instance for production and one for QA and development, with no separate
SCS servers and no separate QA or development instances. Also the SAProuter is available
once per productions and QA or development.
Appendix B. Planning, preparing, and implementing the SAP landscape 159