Planning for an IBM zAware implementation
This chapter provides high-level information that will help you identify the hardware, system setup, and personnel resources required for a successful IBM zAware implementation so you can plan your implementation in advance. When you are ready to start the installation, such preparation will help you avoid unforeseen issues or delays and enable you to derive value from IBM zAware as quickly as possible.
Refer to IBM System z Advanced Workload Analysis Reporter (IBM zAware) Guide, SC27-2623, to obtain the latest and most detailed information about planning an IBM zAware implementation. The guide is available on IBM ResourceLink
3.1 Planning overview
This chapter summarizes the items to consider to plan for the resources that are needed to complete a successful and timely install of IBM zAware. Each consideration is addressed in more detail in IBM System z Advanced Workload Analysis Reporter (IBM zAware) Guide, SC27-2623.
3.2 Selecting which systems to monitor with IBM zAware
When selecting systems that are to be monitored with IBM zAware, it is important to bear in mind the capabilities and objectives of IBM zAware, and the importance to your business of the monitored clients.
To maximize the value of the information that it provides to you, IBM zAware attempts to build a model that is as close as possible to an actual representation of the “normal” behavior of that system. Looking at the message activity for simply a few hours or days will not include all the messages that you are likely to see on that system over a month or many months.
Therefore, IBM zAware has a set of criteria that must be met before it will build a model of a system. The requirements at the time of writing are:
•The set of messages that are used to train an LPAR must contain somewhere between 300 and 400 unique message IDs.
•Each of those messages must occur at least once in three different intervals during the period that is being analyzed.
•Production systems tend to show a high degree of message clustering. A message set that results in a large number of single-message clusters means that most messages are appearing individually and not in repeating patterns. This is an indication that IBM zAware could have difficulty identifying anomalous messages and therefore it will not create a model.
For example, a production z/OS system is an obvious candidate for monitoring with IBM zAware. The messages that are produced by those systems are typically many and varied. They also tend to be consistent and are more likely to occur in repeating patterns, and the availability of those systems is vital to the enterprise. These attributes mean that production systems are typically well suited to monitoring by IBM zAware.
Another system type is Quality Assurance (QA). One of the objectives of QA systems is to identify changes between the current release of a software product or an application and a new release. The ability of IBM zAware to identify anomalous messages is ideally suited to that role, so those are also good candidates for monitoring with IBM zAware.
Test and Development systems might be good candidates, depending on how you use them. If they are in the same sysplex as production systems, they might generate messages that are of interest from the perspective of the production systems. Also, if your applications tend to issue console messages, anomalous messages that might be issued due to application changes might be valuable, particularly if those messages identify a situation that can cause a problem in a production environment.
Alternatively, system programmer sandbox systems might seem ideal for initial testing of IBM zAware and getting familiar with it. However, they might not be good candidates for monitoring with IBM zAware because the workload characteristics of those systems are too variable for a model of what is “normal” to be built. Also, the availability of those systems is not as critical to the enterprise. If you plan to use a system programmer system to drive initial testing of IBM zAware you might find that you need to load more than three months of syslog data to have sufficient message variety to be able to successfully create a model. Even that, however, is not a guarantee that IBM zAware will be able to build a model for that system.
|
Model creation consideration: If a system does not have enough message diversity or consistent patterns to be able to successfully create a model, you could “cheat” by writing a simple program to generate large numbers of messages. However, although this might be successful from the perspective of getting IBM zAware to create a model of that system, you need to consider whether this is a worthwhile exercise. If the day-to-day message traffic on a system is such that IBM zAware cannot determine what a “normal” day looks like, you will probably find that it will end up reporting many “anomalies” for that system that are in fact simply normal messages.
|
If you encounter problems trying to get a system to train successfully, refer to 5.5.2, “Creating and updating the system model” on page 168 for further guidance.
Another point to remember is that the monitored clients must have TCP/IP network connectivity to the IBM zAware LPAR. Similarly, any system that will communicate with IBM zAware’s Application Programming Interface (API) will also require TCP/IP access (using secure sockets) to the IBM zAware LPAR.
The monitored clients can be in the same CPC as IBM zAware or in a different CPC. They can also be running under IBM z/VM®. They can be running on any CPC that is supported by z/OS 1.13 or later, and they must be running z/OS 1.13 or later with the enabling PTFs for IBM zAware. Both JES2 and JES3 systems are supported (although the Bulk Data Load utility does not support archive data sets created from a JES3 DLOG).
|
IBM zAware prerequisites for monitored clients: All monitored clients must meet the following prerequisites:
•They must be running z/OS 1.13 or later.
•They must be running on any CPC that is supported by z/OS 1.13.
•The LOGR CDS must be formatted at the HBB7705 or later level.
•The APARs to enable System Logger IBM zAware support must be applied.
•The monitored client must have a TCP/IP connection to the IBM zAware LPAR.
|
Figure 3-1 Sample IBM zAware configuration
Figure 3-1 contains a sample IBM zAware configuration. You can see that the monitored clients can be in the same CPC as IBM zAware or in different CPCs. They also can be in the same site or in multiple sites. The planning information provided here can help you configure a simple configuration or a more complex configuration such as the one shown.
3.3 Hardware resources
For a smooth and timely implementation of IBM zAware, ensure that the hardware configuration required to support and connect to IBM zAware is available.
3.3.1 CPU capacity
IBM zAware runs in an LPAR on a zEC12 or later CPC. Just like any System z LPAR, IBM zAware requires processing capacity, memory, disk storage, and connectivity.
IBM zAware is able to use either general purpose CPs or IFLs, and they can be shared or dedicated. If your configuration contains both types of PUs, and both have sufficient capacity to support IBM zAware, it is generally more cost effective to configure the IBM zAware LPAR to use IFLs. It is useful to start with shared PUs until you gain experience with IBM zAware and have a more accurate indication of how much capacity it will require to handle your message rates.
IBM zAware LPARs support up to 101 PUs, although it is not expected than anywhere near that much capacity will be required.
LPARs
Each IBM zAware LPAR is able to analyze the message stream from a large number of monitored clients. It is expected that most installations will only require a single IBM zAware LPAR. If you have business reasons for requiring multiple IBM zAware LPARs, it is possible to have multiple IBM zAware LPARs on the same CPC, but each will require its own disks and network connections. The CPU capacity required for each IBM zAware LPAR will depend on the volume of messages that IBM zAware has to process and the number of clients it is monitoring.
It is possible to have both test and production IBM zAware LPARs. Whether you deem this to be necessary depends on your philosophy about separation of test and production systems and why you want to have a test IBM zAware. There are several points to consider when making a decision about whether you will benefit from a test IBM zAware LPAR:
•Consider why you want to have a test IBM zAware LPAR. If your objective is to test the analytics function when you move to a new release of IBM zAware, then bear in mind that the message profile from your test systems is probably different than the message profile from your production ones. This means that any changes that you see with the new release in the test IBM zAware might or might not apply to your production IBM zAware.
•When you activate IBM zAware firmware updates on a CPC, all IBM zAware LPARs on that CPC will automatically re-IPL themselves. This means that it is not possible to run two IBM zAware LPARs with different code levels on the same CPC. So if your intent is to investigate the effect of IBM zAware firmware updates, you will need to run the test and production IBM zAware LPARs on different CPCs.
•You could use the bulk load utility to load several months’ worth of messages from your production systems into the upgraded test IBM zAware. However, the results shown on the analysis window only relate to messages received in real time. No analysis results are shown for the time frame that is covered in the bulk load.
Thus, unless you are willing to bulk load production messages and then move your production systems over to the test IBM zAware, you will not be able to see the effect of the new IBM zAware release on your production messages.
|
Messaging consideration: A monitored client can only connect to one IBM zAware LPAR at a time. This means that you cannot have a z/OS system feeding messages in real time to both test and production IBM zAware LPARs.
|
•There is no capability to delete all data for just one system or just one sysplex from IBM zAware. The controls for how long data is kept in IBM zAware apply to all systems and all sysplexes.
This means that if you start with one IBM zAware LPAR and then decide that you want to move a subset of systems to a new IBM zAware LPAR, the data from those systems will remain in the first IBM zAware until it expires.
CPU capacity for IBM zAware LPAR
The amount of CPU capacity required by IBM zAware depends mainly on the volume of message data that is sent to IBM zAware and the number of monitored clients. There are two usage profiles for a IBM zAware LPAR:
•During normal operation, when IBM zAware is processing messages in real time as they arrive from the monitored clients.
•Performing a bulk load or updating the model. Additional CPU will be used by IBM zAware at these times. Because the LPAR will require more capacity during this activity, if the LPAR is constrained, the update of the model or the bulk load will take more time to complete.
Chapter 5, “Maintaining and managing IBM zAware” on page 153 discusses how to identify the most appropriate frequency with which to update the IBM zAware model. Note that the frequency that you specify applies to all monitored clients, that is, it is not specified on a system-by-system basis.
To give you an indication of how much processing capacity is required, Table 3-1 shows the percent of a zEC12 IFL that was consumed for two different message rates and assuming a maximum of ten connected clients.
Table 3-1 CPU consumption of IBM zAware LPAR
|
Total Message rate per second
|
Utilization % of 1 zEC12 IFL during normal operation
|
Utilization % of 1 zEC12 IFL during bulk load and training
|
|
500
|
20
|
25
|
|
1500
|
40
|
80
|
IBM advises attaching no more than 10 monitored images when the maximum message rate in a 15-minute interval is approximately 1500. Otherwise, there is the potential to overrun the capacity of a single zEC12 IFL during initial bulk load and training. You can configure a second IFL to avoid this condition.
Note that these numbers are only rules of thumb for planning purposes. Actual IBM zAware LPAR CPU consumption can vary based on many variables such as the number of monitored clients, the number of unique message IDs, the amount of data in the model database, the amount of storage in the IBM zAware LPAR, the message rate, and so on.
If you start with a single shared engine and use IBM RMF™ to monitor the CPU usage of the IBM zAware LPAR, you should be able to determine the required capacity if you plan to add more monitored clients to the configuration. Note that if you need to increase the number of engines in the LPAR, it is necessary to deactivate and reactivate the IBM zAware LPAR. Even though it is possible to define both INITIAL and RESERVED CPs or IFLs in the LPAR profile, the IBM zAware GUI does not provide a mechanism for dynamically bringing additional engines online.
You can calculate your maximum message rate by selecting a peak workload interval and storing the OPERLOG messages. Then, choose a precise 10-minute interval from the stored peak message traffic and count the messages in the interval. Divide that message count by 600 to obtain the message rate per second. As a general rule of thumb, the upper bound on sustained message rates on z/OS systems averages about .1 message per second per MIPS. This is based on systems running batch, TSO, IBM CICS®, DB2, and IBM IMS™. Systems running WebSphere Application Server might be a little higher. And systems dedicated to IMS or DB2 tend to be a bit lower.
Alternatively, the IBM provided Message Analysis Program helps you identify the average and peak message rates for a system based on an analysis of the file you would use as input to a bulk load. This is discussed in “Capacity planning” on page 208.
CP capacity for z/OS LPARs
The additional z/OS CPU consumption for the monitored clients depends on a number of factors:
•Was that system already using OPERLOG?
•The average and peak number of messages that will be sent to IBM zAware from the monitored client.
IBM ran a number of measurements of systems that were sending data to IBM zAware. The total utilization of the z/OS systems varied from about 25 percent of 1 CP up to more than 20 CPs’ worth of capacity. The total capacity used by the System Logger address space (which included its normal processing of OPERLOG plus its work to send the messages to IBM zAware) varied from .1 percent of 1 CP up to a maximum of 2 percent of 1 CP. Even when a bulk data load was running, System Logger utilization did not exceed 2 percent of 1 CP.
Using a System Logger that was only handling OPERLOG requests as the base, connecting System Logger to the IBM zAware LPAR resulted in roughly doubling the amount of CPU being used by System Logger. If System Logger was handling requests for other log streams, those requests would be unaffected by connecting to IBM zAware. Also, connecting System Logger to IBM zAware had no impact on CPU usage by the Console Address space if the system was already using OPERLOG.
OPERLOG uses Message Data Blocks (MDBs) that the CONSOLE address space is already creating for its own use, so there is no additional overhead involved in creating MDBs for the OPERLOG. The only additional CPU cost associated with the use of OPERLOG (which will be reduced if you are no longer writing to SYSLOG) is the use of System Logger services to write to OPERLOG. The writing to either log is charged to the CONSOLE address space, so you can monitor the CPU usage of that address space before and after turning on OPERLOG if you need to identify the additional cost associated with enabling OPERLOG.
Based on these experiences, we believe that it is fair to say that the impact on z/OS CPU utilization of sending that system’s messages to IBM zAware will be negligible.
Memory
IBM zAware requires a base amount of memory for IBM zAware itself. In addition, each monitored client requires an additional amount of memory in the IBM zAware LPAR. At the time of writing, the recommended values are 4 GB for IBM zAware, plus about 256 MB extra for each monitored client. However, always check the level of IBM System z Advanced Workload Analysis Reporter (IBM zAware) Guide, SC27-2623, that corresponds to your level of IBM zAware to obtain the latest IBM guidance regarding the required amount of memory. IBM zAware supports up to the maximum amount of memory that the CPC supports in a single LPAR.
At the time of writing, IBM zAware does not create any SMF-like information about its own resource utilization. The CPU consumption of the IBM zAware LPAR can be monitored using an RMF CPU report, but there is no mechanism to monitor memory use of the IBM zAware LPAR.
Lack of sufficient CPU capacity or memory is likely to show as poor response times when using the IBM zAware GUI. Adding memory to the IBM zAware LPAR will require the LPAR to be deactivated and reactivated.
|
Tip: After you have completed the initial setup, adding more monitored clients to IBM zAware is simple. However, it is easy to forget to add memory to the IBM zAware LPAR when you add monitored clients. So it is useful to create a small checklist of the steps needed to add a monitored client and include adding memory to the IBM zAware LPAR in that list. A sample checklist is contained in 5.9, “Checklist for adding a monitored client” on page 179.
|
3.3.2 Network connectivity
IBM zAware uses TCP/IP to communicate with the systems it monitors. Hipersockets can be used for communication if the monitored clients are in the same CPC as the IBM zAware LPAR.
Communication over an Open Systems Adapter (OSA) can be used if the monitored clients are in the same or a different CPC. IBM zAware supports multiple OSAs, and multiple IP addresses on a given OSA. The OSAs can be on the same or different subnets.
An Intra-Ensemble Data Network (IEDN) can be used to connect to the IBM zAware LPAR if the IBM zAware LPAR resides in a CPC that is part of a IBM zEnterprise® ensemble, and the monitored clients are also part of the ensemble. For more information about IEDNs, refer to the IBM Redbooks publication Building an Ensemble Using IBM zEnterprise Unified Resource Manager, SG24-7921.
The network bandwidth that will be required to connect the monitored clients to IBM zAware is based on the peak message rate of the systems. The message rate can be determined by analyzing a representative interval of syslog or OPERLOG data using the Message Analysis Program as described in Appendix A, “Syslog Message Analysis Program” on page 207.
Note that System Logger supports up to 99 GB of buffers for times when the rate of message production exceeds the available network bandwidth. So if the available network capacity is insufficient to handle intermittent message peaks, the only impact might be that it will take a little longer for messages to reach the IBM zAware LPAR. It is not desirable to be in a situation where there is constantly a backlog of messages queuing in the Logger buffers1.
Regardless of the type of connection you use between the monitored clients and IBM zAware, remember that you will need at least one OSA adapter (preferably two, for availability) for access to the IBM zAware GUI. IBM zAware supports a maximum of 24 OSA adapters.
3.3.3 DASD storage
The IBM zAware LPAR requires CKD disk space2 to store the following information about each monitored client:
•A model of the normal message activity for the system
This model information includes not only information about which messages are issued, but also how they are clustered (which messages tend to be issued around the same time). You control how many days of model information are kept in the database using the Training models retention time parameter in the IBM zAware GUI, as shown in Figure 3-2 on page 103. The default is 365 days.
•Information about messages that have been received since the model was last updated
This information will be used as input to the next time the model is updated. You can control how many days of this information is kept in the database using the Instrumentation data retention time parameter in the IBM zAware GUI. The default is 365 days.
•The information that is presented on the Analysis window of the IBM zAware GUI.
An XML file is created for each 10-minute interval for each monitored client. The amount of time that these XML files are retained in the database is controlled by the Analysis results retention time parameter in the IBM zAware GUI. The default is 365 days.
Figure 3-2 Configuring IBM zAware data retention periods
Note that the actual incoming messages are not stored in the IBM zAware disk pool. Each message is summarized and analyzed by IBM zAware when it arrives and the instrumentation data database is updated.
Because the amount of disk space that IBM zAware requires is based on the number of unique messages, and not the total number of messages, it can be challenging to accurately predict the amount of disk space that is required. Also, there is a relationship (although not a linear one) between the number of unique messages, the number of systems, and the amount of space that is required to hold that information.
Currently, the IBM guideline is to provide 500 GB for the use of IBM zAware, plus an additional 4 to 5 GB per monitored client. However, this value might vary from one system to another; it depends on how many months of information you want IBM zAware to keep. The IBM zAware GUI tells you how full the disk pool is, and you can easily add and remove devices dynamically, so you can fine-tune your configuration based on your own experiences. IBM zAware supports up to 256 CHPIDs, and there is effectively no limit on the amount of disk space that can be connected to it.
When the IBM zAware LPAR is activated, it can see any DASD device that has been defined as accessible to the IBM zAware LPAR in the active IOCDS. You then use the IBM zAware GUI to tell it which of those volumes it should use. IBM zAware supports dynamic I/O reconfiguration, so you can add DASD devices to the IBM zAware LPAR dynamically (assuming there is a z/OS or a z/VM LPAR on the IBM zAware CPC to dynamically activate the new configuration). Pressing the Refresh button on the Data Storage Devices panel (as shown in Figure 3-3) results in the updated list of devices being displayed.
Figure 3-3 IBM zAware Data storage panel
|
Critical IBM zAware access considerations: When defining the IBM zAware LPAR in HCD, it is critical that you ensure the following points:
•Use a device candidate list to ensure that the IBM zAware LPAR can only access its own disks.
•Use a device candidate list to ensure that only the IBM zAware LPAR has access to the IBM zAware disks.
– The one exception is if you want to back up the IBM zAware disks. In that case, the IBM zAware disks must be accessible to the z/OS system, but should be defined to that system as being offline at IPL. For more information about backing up the IBM zAware data, refer to “Backing up the IBM zAware file system” on page 161.
•If you have more than one IBM zAware LPAR, each IBM zAware LPAR should only have access to its own set of disks.
If an IBM zAware LPAR can access disks other than its own, it is possible that an IBM zAware user with admin authority could accidentally initialize one of those disks.
Note that using an OS CONFIG (a method frequently used to limit the devices that a z/OS LPAR can access) will not work for IBM zAware.
|
IBM zAware DASD backup considerations
When planning your IBM zAware environment, it is important to bear in mind that the information that resides in IBM zAware is not transactional data. This means that the data in IBM zAware does not have to be managed with the same degree of care that your typical z/OS data receives.
For example, if a system loses connectivity to IBM zAware and some number of console messages are not sent to IBM zAware, the impact of that is likely to be minimal in relation to the volume of messages that do reach the IBM zAware LPAR.
Furthermore, it is likely that all the information in IBM zAware can be recovered relatively easily (if necessary) by simply loading historical message information from your syslog archives for all monitored clients. This means that backing up or mirroring your IBM zAware data, as you typically do with all your z/OS data, might not be necessary. The subject of backing up your IBM zAware disks is discussed in more detail in 5.3.4, “Backing up the IBM zAware file system” on page 161.
3.3.4 z/OS requirements
The detailed z/OS requirements for IBM zAware are provided in IBM System z Advanced Workload Analysis Reporter (IBM zAware) Guide, SC27-2623. This section simply summarizes the z/OS considerations.
Providing message history
To provide IBM zAware with a representative view of the normal message traffic for a system, it is ideal to have about 90 days of syslog or OPERLOG data that will be bulk-loaded into the IBM zAware LPAR as part of the setup process. The likelihood of IBM zAware considering a “normal” message is an anomaly increases inversely with the number of days of messages you provide. A small number of days’ worth of data is more likely to result in IBM zAware considering a message to be an anomaly because it has not seen it before.
At the time of writing, the Bulk Data Load Utility does not support the use of a JES3 DLOG archive file. That means that you have two options for getting JES3 message data into IBM zAware to create the model database:
•If you are using OPERLOG, you can create an archive file using the IEAMDBLG program. The message format in OPERLOG is the same, regardless of whether the system is using JES2 or JES3.
•You can send message data in real time and wait until you have sent over enough data to be able to build a representative model.
|
Provide a representative view: Aim to keep at least 90 days of syslog or OPERLOG data to use to prime the IBM zAware database. This will result in more accurate anomaly detection when you start using IBM zAware immediately after installing it.
|
OPERLOG
The mechanism to move messages from z/OS to the IBM zAware LPAR is provided by System Logger. Therefore, to have messages sent to IBM zAware in real time, OPERLOG must be running on every system that you want to monitor with IBM zAware. In a multisystem sysplex, that means that the OPERLOG log stream must be defined as a CF log stream.
You can also use OPERLOG as a DASD-only log stream. However, this method is only suitable for a single system sysplex, because a DASD-only log stream is single system in scope and you can only have one OPERLOG log stream per sysplex. This means that if you make OPERLOG a DASD-only log stream, only one system can access it and therefore only that system can be an IBM zAware monitored client. See z/OS MVS Setting Up a Sysplex, SA22-7625, for information about DASD-only log streams.
|
Message capture: Even though OPERLOG is a sysplex-wide log stream, System Logger IBM zAware support captures the messages when they are written by each z/OS image. Therefore, every system that will be monitored by IBM zAware sends its own messages to the IBM zAware LPAR.
|
If you have systems that do not use OPERLOG or System Logger (a GDPS/PPRC Control System, for example), IBM zAware is unable to analyze the message activity on those systems.
Any messages that were suppressed by your MPFLST or Message Flood Automation or similar facilities will be passed to IBM zAware. However any messages that were deleted by those facilities will not be sent to OPERLOG, and therefore will not be visible to IBM zAware.
z/OS release requirements
To benefit from the IBM zAware monitoring capability, a system must be running z/OS 1.13 or later with the required enabling PTFs. Systems that are running z/OS 1.11 or 1.12, or systems running z/OS 1.13 without the enabling PTFs, can coexist in the same sysplex with a system that is connected to IBM zAware. However, they cannot use the IBM zAware functions. The changes that must be made to the OPERLOG log stream definition to support IBM zAware will be ignored by those systems.
z/OS systems that will be monitored by IBM zAware must be members of a monoplex or a multisystem sysplex.
System Logger planning
System Logger uses log streams for two aspects of working with IBM zAware:
•It captures messages that are bound for the OPERLOG log stream and sends them to IBM zAware in real time.
•When you use the bulk load utility to load historical data into IBM zAware, you define both a model log stream and a temporary log stream. When the utility copies the messages from the input data set to the temporary log stream, System Logger captures those messages and forwards them to IBM zAware.
You will need SAF access the IXGZAWARE_CLIENT resource in the FACILITY class to be able to update the OPERLOG log stream definition to indicate that it is to be sent to IBM zAware.
For the bulk load utility, if you use RACF or similar security products to protect access to log streams, ensure that both System Logger and the person that submits the bulk load job have access to the log streams used by the job.
The LOGR CDS should be formatted at level HBB77053. However, this was delivered by z/OS 1.2, so there should be no considerations related to sharing the CDS with pre-z/OS 1.13 systems. Remember that the bulk load utility will require a model log stream and a real log stream, so ensure that the LOGR CDS has sufficient unused LSR records.
|
Tip: The provided sample bulk load job (member AIZBLK in SYS1.SAMPLIB) defines a model log stream in the first step. To execute with the optimum efficiency, ensure the following points:
•The LS_SIZE and STG_SIZE parameters are reasonable, based on the amount of data that you will be loading. The default values result in offload and staging data sets that are only 225 tracks. Using these values, in our case we were getting a new offload data set every 3 seconds, which is possibly more frequently than you might want.
•AUTODELETE(YES) is specified. This specifies that each offload data set should be deleted as soon as it is no longer required. If you do not specify this, all the offload data sets will be kept, potentially consuming a large amount of disk space.
|
3.4 Technical resources
In addition to the hardware and software that is required to run IBM zAware, some setup must be performed to enable it. This section helps you identify the technical skills that are required to complete the installation of IBM zAware.
3.4.1 Hardware Management Console
Because IBM zAware runs as an LPAR, you must create the definitions for the LPAR on the HMC. And because IBM zAware is a new type of LPAR, there is additional information that must be entered on the HMC that does not apply to other types of LPARs.
All of these tasks can be most efficiently completed by someone that is familiar with managing the HMC. It is also useful to have access to whomever is responsible for setting up the network definitions for the IBM zAware LPAR.
Update CPC Reset profile
Before you can create an Image Profile for the IBM zAware LPAR, the CPC Reset profile must be updated to specify the activation order for the newly defined IBM zAware LPAR.
Define Image Profile
The IBM zAware Image Profile is similar to the profiles for most other LPARs. However, in addition to the normal Processor, Memory, and other tabs, there will also be a Firmware tab for any LPAR defined to run in zAware mode. The firmware tab asks for the following information, so ensure that you have this available when defining the IBM zAware Image Profile:
•The CHPID, VLAN, IP address, and mask (in 2-digit format4) for each LAN adapter
•The default gateway IP address
•The IP address of the Domain Name Servers, if any, that the IBM zAware LPAR is to use
3.4.2 z/OS MVS
There are a number of tasks that must be completed to prepare for IBM zAware that are likely to fall under the jurisdiction of the z/OS technical support group.
Hardware Configuration Definition
Hardware Configuration Definition (HCD) should be used to define the IBM zAware LPAR and its devices and network adapters. Therefore, whoever is responsible for maintaining the hardware definitions needs to update HCD. If the disks that IBM zAware will use are already defined to other LPARs, creating explicit device candidate lists to limit the LPARs that can access those disks will require additional time.
It might also take an amount of time to roll out the hardware configuration changes to all affected CPCs. Plan to create the hardware definitions and roll out the changes in advance of the start of the IBM zAware installation to avoid unnecessary delays.
IXGCNFxx member in Parmlib
The information that System Logger requires to be able to communicate with IBM zAware is provided in the IXGCNFxx member of Parmlib. This member was initially delivered by z/OS 1.13, so you might not be using it yet. A sample member is provided in the IXGCNFXX member of SYS1.SAMPLIB. You can copy that to Parmlib and use it as a base for the changes you will make for IBM zAware.
The IXGCNFxx member can be activated either by adding the IXGCNF=xx keyword to your IEASYS member and performing an IPL, or dynamically, by issuing the SET IXGCNF=xx system command. Note that by default, the IXGCNF00 member (if it exists) is not used. To have an IXGCNFxx member used at the next IPL, you must explicitly specify it in the IEASYS member.
If implementing changes such as this can take a long time in your environment, plan to make this change in advance of starting the IBM zAware installation. The new functions enabled by updating that member will not have any effect until you explicitly start the connection to IBM zAware using a System Logger command.
3.4.3 Network
All communication with IBM zAware, whether to send messages to IBM zAware, to logon and use its GUI, or to use the IBM zAware API, is through TCP/IP connections. Because network configurations vary so widely from one installation to another, it is difficult to provide information that is applicable in all cases. However, the network requirements are not complex and can be easily understood by anyone familiar with managing your IT network.
z/OS port for IBM zAware
System Logger uses TCP/IP to send data to the IBM zAware LPAR. This means that it requires an available port on the z/OS system. The UNIX System Services that System Logger uses to establish a connection to IBM zAware automatically selects an available port. You do not need to define a port number to System Logger, and there is no way to influence which port it will use.
Connectivity
The IBM zAware LPAR can be connected using Hipersockets, OSA adapters, or IEDN. You need to allocate a number of IP addresses for use by the IBM zAware LPAR, so plan them in advance. To avoid single points of failure, configure the IBM zAware LPAR with at least two OSA CHPIDs.
Firewall
Nearly all communication with the IBM zAware LPAR is initiated from outside the LPAR. IBM zAware uses the following ports:
80 For HTTP access
443 For HTTPS access
2001 For access from monitored clients
Any firewall rules that might be required will be based on enabling outside systems to come in through those ports.
If you plan to use an LDAP server, the IBM zAware LPAR will initiate a session with the LDAP server. If there is a firewall between the IBM zAware LPAR and the LDAP server, you must permit the IBM zAware LPAR to use the port that is used by your LDAP server. As part of the installation process, you will be required to provide the IP address or host name and port number to IBM zAware (if you plan to use LDAP). Additionally, if a domain name is used instead of an explicit IP address for the LDAP server, then the IBM zAware LPAR must be able to reach a DNS server for host name-to-IP resolution.
3.4.4 Security
There are two aspects to security when planning for a IBM zAware implementation. One aspect is the SAF resources that System Logger will need access to send the message data to IBM zAware. The other aspect is that you will need to define user IDs that can be used to logon to the IBM zAware LPAR. You will also need to specify the level of authority of IBM zAware users to make changes to the IBM zAware LPAR.
z/OS resources
Because System Logger is the task that is sending all the data to the IBM zAware LPARs, the z/OS access considerations are centered on the ability of IBM zAware to access the resources that are required for this process.
For detailed information about the access requirements for the IBM zAware-related SAF resources, refer to “Define authorization to System Logger resources” in z/OS MVS Setting Up a Sysplex, SA22-7625, and IBM System z Advanced Workload Analysis Reporter (IBM zAware) Guide, SC27-2623.
z/OS security considerations for the IBM zAware API
The IBM zAware API currently requires communication using Secure Sockets Layer (SSL). If you are going to communicate with the API from a z/OS system, that system must be enabled for Application Transparent - Transport Layer Security (AT-TLS).
Describing the setup of AT-TLS is beyond the scope of this book. However, we provide information explaining the changes we made to enable AT-TLS for IBM zAware in our environment in Appendix B, “Activating TCP/IP AT-TLS” on page 213. Additionally, you can find more information about setting up AT-TLS in the Redbooks publication IBM z/OS V1R13 Communications Server TCP/IP Implementation: Volume 4 Security and Policy-Based Networking, SG24-7999.
IBM zAware security
To access the IBM zAware GUI, users must have a IBM zAware user ID and a password. The user IDs can be defined in a local repository, in an LDAP server, or in both places. To keep things simple, we strongly advise that you use just one of these methods rather than having some IDs defined in LDAP, and some in the local repository.
After you have defined the IDs and passwords (either in the local repository or in the LDAP server), you use the IBM zAware GUI to assign a role to each ID. Roles can be either “user” or “admin.” There is also the master user ID that is defined on the Firmware tab in the IBM zAware LPAR’s image profile. That user ID automatically has admin authority. For information about the differences between the user and admin roles, refer to IBM System z Advanced Workload Analysis Reporter (IBM zAware) Guide, SC27-2623.
If you use LDAP to define your users, also use a high availability LDAP configuration. If the LDAP server is down, it will not be possible to logon to IBM zAware using any ID that is defined in LDAP. You might also want to define just one or two user IDs in the local repository that can be used if the LDAP server is unavailable. Additionally, we suggest that if you use LDAP as the repository for your IBM zAware IDs, then none of those IDs have Administrator authority on the LDAP server.
For more information about the local repository and the use of the IBM zAware GUI, refer to 4.4.2, “User authentication to use the IBM zAware GUI” on page 131.
|
Tip: Do not use LDAP IDs that have administrator authority on the LDAP server. Doing so can lead to confusion if you accidentally define the same user ID on both the IBM zAware GUI panels and on the LDAP server.
Also, avoid defining the same user ID on both the LDAP server and the IBM zAware GUI. If you define a few user IDs on the GUI as a fallback in case LDAP is unavailable, ensure that you use user IDs that do not exist on the LDAP server.
|
3.5 Using IBM zAware
The perspective of system message traffic that is provided by IBM zAware is quite different than anything you are familiar with the System z systems management sphere. Fully appreciating the information that is presented by IBM zAware will require time to get familiar with it.
Thought needs to be given to which of your staff will be the primary users of IBM zAware. That is, will it be operators, system management personnel, system programmers, or possibly all three groups? Regardless of who it will be, you need to plan for time for education to allow IBM zAware users to efficiently navigate around the IBM zAware GUI and understand both the information they are presented with and why IBM zAware considers that information to be an anomaly. All of this will take time.
Additionally, someone must be responsible for monitoring and managing IBM zAware, and asking questions such as: is it still working as expected, and does it have sufficient disk space? If there are days when the activity on one system was not representative of a “normal” day, you might want to exclude that day from the next IBM zAware training cycle.
These are just some of the tasks required to effectively manage IBM zAware, so identify who will have that responsibility, and allow time for them to become familiar with their responsibilities. The management of IBM zAware is discussed at length in Chapter 5, “Maintaining and managing IBM zAware” on page 153.
3.6 Monitoring IBM zAware availability
The expected usage of IBM zAware is that you will use it if you detect something unusual happening in your environment. More than likely, you will not have someone watching IBM zAware on a constant basis. This means that there is a risk that IBM zAware has stopped processing the message traffic for one or more systems but no one has noticed, or not noticed until they need to use IBM zAware, at which point it is too late.
For this reason, we advise that you consider using the IBM zAware API to monitor IBM zAware on an ongoing basis, to ensure that it is still working, and that it is still receiving message data from every monitored client. 6.3, “IBM Tivoli NetView for z/OS” on page 196 contains information about sample NetView execs that perform this checking.
The most likely cause of a “problem” is that the monitored clients disconnected for some reason and failed to reconnect successfully. The following list includes several of the events that cause the connection between IBM zAware and monitored clients to be dropped:
•When you IPL a z/OS system, the connections from that system will be stopped. After the IPL, System Logger will automatically try to reestablish the connections, regardless of whether the connection was active at the time the system was IPLed.
•When you assign bulk loaded data to a sysplex, the connections to all monitored clients will be terminated by IBM zAware. Normally, the links should be automatically restarted by System Logger. However, problems can be encountered during this process.
•When you apply firmware maintenance to IBM zAware, IBM zAware will reIPL itself and the connections to the monitored clients will be dropped. Again, the links should be automatically restarted by System Logger, but problems can be encountered during this process.
Presumably you will have automation in place on each monitored client that will query the state of the IBM zAware connections, and take corrective action if a connection is down. Nevertheless, it is still advisable to perform some automatic monitoring of IBM zAware itself to ensure that it is still running and analyzing the message data.
3.7 Accessing the IBM zAware GUI
We realize that some enterprises lock down their workstations so that no additional software can be installed on them. The only workstation software that is required by IBM zAware is a supported browser (Internet Explorer or Firefox). It is not necessary to install any client software or make any other changes that are likely to not be allowed.
1 The System Logger IBM zAware buffers are pageable and reside in above-the-bar private storage. You control the amount of storage for the buffers using the LOGBUFMAX keyword in the IXGCNFxx member of Parmlib.
2 IBM zAware requires CKD disk. FBA is not supported.
3 To determine the format level of the LOGR CDS, use the D XCF,C,TYPE=LOGR command. If the format level is older than HBB7705, format a new set of LOGR CDSs using the ITEM NAME(SMDUPLEX) NUMBER(1) keywords.
4 If your network staff provides you with a 4-byte subnet mask (255.255.240.0, for example), there are a variety of subnet mask converters on the Internet to help you convert that mask to the 2-digit number that is required by IBM zAware (20, for example).
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.