Managing LDAP Workloads via Tivoli Directory Services and z/os WLM IBM. Kathy Walsh IBM. Version Date: July 18, 2012

Transcription

1 Managing LDAP Workloads via Tivoli Directory Services and z/os WLM IBM Kathy Walsh IBM Version Date: July 18, 2012 This document can be found on the web, Under the category of White Papers.

2 Overview of LDAP Support As of z/os 1.11 the LDAP server part of the Tivoli Directory Server can be configured to identify LDAP transaction names which can be used in Workload Manager (WLM) classification rules. The transaction names can be used to specify different performance goals for LDAP operations based upon the client's IP address and/or the bound user's distinguished name (DN). In conjunction with this support, WLM has reserved LDAP as an IBM defined subsystem type called LDAP. With the introduction of this support it is required for an installation using LDAP on z/os to update their WLM policy to define either an LDAP classification rule for the LDAP workload or to specify a default WLM service class for the LDAP subsystem. Failure to do this customization would result in the LDAP workloads running in WLM service class SYSOTHER with a discretionary goal. Such a goal definition would be incorrect as it can lead to sever performance problems and should be corrected as soon as possible. The new LDAP WLM support was intended to provide increased availability by allowing segregation of LDAP request to WLM service classes with different goals and importance. For instance, one possible use may be if a client application is spamming the LDAP server with numerous LDAP requests, a different service class with less aggressive goals than normal LDAP operations could be assigned to those requests. The support was intended to prevent the LPAR resources running LDAP from being consumed by the spamming LDAP client applications. This control is done by either updating the LDAP configuration options or by issuing an LDAP operator command. The wlmexcept configuration option can be used to specify the client's IP address, the bound user's distinguished name (DN), or both to route those requests to an LDAP defined transaction name which can be specified in the WLM classification rules using the transaction name (TN) attribute. An example of this configuration option is: wlmexcept name [IP_address] [Distinguished Name] The wlmexcept configuration option can be specified multiple times within the LDAP server configuration file to allow multiple client IP addresses or bound users' DNS to be associated with the same or different WLM transaction names. The order of the wlmexcept configuration options in the LDAP server configuration file determines the order the LDAP server uses to match incoming client requests and assign the appropriate transaction name. By default, the transaction name, GENERAL, is defined by the LDAP server for client requests originating from IP addresses or bind distinguished names not specified on wlmexcept configuration options or operator commands. z/os Performance: LDAP and WLM Page 2

3 Implementation Concerns z/os Enclaves Support There are implementation concerns when using the LDAP WLM support. When a wlmexcept configuration option or operator command is issued LDAP will respond by creating a z/os enclave. This enclave is an independent enclave, and as such it will cause LDAP to make a call to WLM using the LDAP classification rules. This enclave though is a never ending enclave. It exists for as long as the wlmexcept option is in effect. There is also an independent enclave created for the default transaction name called GENERAL which is always present when LDAP is started. Since the enclave never ends there is no transaction count associated with the enclave though many incoming requests can be running under the enclave. In such a case these enclaves must be classified using a velocity goal. Response time goals can not be used. Below is an example of how this work would look in an RMF Workload Activity Report. REPORT BY: POLICY=WSCDEF WORKLOAD=ONL_WKL REPORT CLASS=DNSATACK CRITICAL =NONE -TRANSACTIONS- TRANS-TIME HHH.MM.SS.TTT --DASD I/O-- ---SERVICE--- AVG 1.00 ACTUAL 0 SSCHRT 0.0 IOC 0 MPL 1.00 EXECUTION 0 RESP 0.0 CPU 3329 ENDED 0 QUEUED 0 CONN 0.0 MSO 0 END/S 0.00 R/S AFFIN 0 DISC 0.0 SRB 0 #SWAPS 0 INELIGIBLE 0 Q+PEND 0.0 TOT 3329 EXCTD 0 CONVERSION 0 IOSQ 0.0 /SEC 28 AVG ENC 1.00 STD DEV 0 REM ENC 0.00 ABSRPTN 28 MS ENC 0.00 TRX SERV 28 It is possible to use online monitors, such as SDSF, to look at currently running enclaves. By using these monitors you can identify how many independent enclaves have been created to support the LDAP workload. Below is an example taken from the SDSF ENC panel to show the type of information available. The field SSType indicates which WLM defined subsystem owns the enclave. The display indicates there are 3 LDAP enclaves, with the ACTIVE one being used to service the GENERAL requests. The other two enclaves exist because wlmexcept configuration options or commands were used to create them. As stated the default service class for LDAP requests is GENERAL. All incoming requests will run under the GENERAL enclave until it can be determine the request needs to run under a different enclave based on its IP address and/or distinguished name. At this point the request leaves the GENERAL enclave and is then joined via WLM services to the appropriate enclave. After the LDAP operation is completed the request leaves the enclave and re- z/os Performance: LDAP and WLM Page 3

4 joins the GENERAL enclave. This is another reason why the GENERAL enclave created for incoming LDAP work must be appropriately classified to a WLM service class. In the table below you can see an enclave owned by TCPIP which has not been classified by WLM and is running in the default service class of SYSOTHER. Though not directly related to this topic this is what you would see for the LDAP enclaves if no WLM classification rules were specified. SDSF ENCLAVE DISPLAY SYSD ALL LINE 1-12 COMMAND INPUT ===> SC NP NAME SSType Status SrvClass Per PGN RptClass 3C000F54BE LDAP INACTIVE OPS_HIGH 1 RLDAPPRB 5C000F54C0 LDAP INACTIVE OPS_HIGH 1 RLDAPDEF 60000F54BD LDAP ACTIVE OPS_HIGH 1 RLDAPGEN STC INACTIVE SYSTEM STC INACTIVE SYSSTC STC INACTIVE SYSSTC 1 RTCPIP 2C TCP INACTIVE SYSOTHER 1 It is recommended for the LDAP enclave workload to be classified to an existing user defined service class and not to a new service class specially created for the LDAP work. Generally this work should run in a service class with a high velocity goal and a high importance. The best place for this workload in an existing WLM policy would be where high importance started tasks are defined. This workload does not typically use much CPU but it does require good service. Before this support, the LDAP function since it is a started task, would have often been classified to SYSSTC. With the migration to enclaves and classification to a user defined service class the LDAP work can no longer be defined into SYSSTC. Below is an example of a recommended set of WLM classification rules to handle the LDAP workloads. This shows a case where a wlmexcept was defined with a transaction name called IPWEBPRB (IP Web Problem). Then an associated WLM rule is created with the transaction name (TN) rule specifying IPWEBPRB. In this case the work is assigned to the service class OPS_HIGH. The default transaction name of GENERAL is also classified to OPS_HIGH. One benefit of specifying the wlmexcept configuration statement is to have the work go into the same service class but specify different report classes. This then allows the ability to report on the CPU used by the different communities of LDAP requests. In this example work which has a transaction name of IPWEBPRB will be reported in report class RLDAPPRB and all other incoming client requests which match the transaction name of GENERAL will go to service class OPSHIGH with a report class of RLDAPGEN. Any other incoming work for which a wlmexcept configuration option or command has been entered will not match either the GENERAL or IPWEBPRB transaction names and will be controlled by the default service class specification of OPSHIGH but this work will also be in report class LDAPDEF. z/os Performance: LDAP and WLM Page 4

5 Subsystem Type. : LDAP Fold qualifier names? Y (Y or N) Description... LDAP Tivoli Directory Support Action codes: A=After C=Copy M=Move I=Insert rule B=Before D=Delete row R=Repeat IS=Insert Sub-rule More ===> Qualifier Class Action Type Name Start Service Report DEFAULTS: OPS_HIGH RLDAPDEF 1 TN GENERAL OPS_HIGH RLDAPGEN 1 TN IPWEBPRB OPS_HIGH RLDAPPRB Availability Concerns with wlmexcept Support There are significant performance concerns with using the LDAP support as provided in z/os By using the example of separating an application spamming the LDAP server discussed earlier it will be possible to highlight the potential performance concerns with the support. If an incoming client application is spamming the LDAP server and a wlmexcept statement is created to place this workload in a service class with less access to CPU (in WLM terms a less aggressive goal or lower importance) this modification has the real possibility of impacting the entire LDAP environment not just the spamming application. The reason is the LDAP thread pool is not segregated by the wlmexcept definitions, a single thread pool handles all of the requests. The spamming client application is most likely sending a large volume of requests. If these requests are in a service class which struggles to get to CPU what will happen is, in a relatively short amount of time, the LDAP thread pool will be filled with slow performing threads. Requests which are not originating from the spamming client application will then have to wait behind the spamming requests increasing overall delay to the entire LDAP environment. In short the overall LDAP environment will tend to run at the performance level of the work with the least aggressive service class. This is not what was originally intended with this support. It is strongly recommended to not use the wlmexcept LDAP support to define different classes of service for LDAP workloads. As shown above it would be possible to segregate the workloads for reporting purposes. But even this has limited value since the enclaves don t generate ended transaction counts. It would be possible via WLM reporting on an RMF Workload Activity Report to understand how much CPU the different workloads in the different report service classes were using. It should also be understood WLM is not an availability manager and attempting to use WLM to control spamming applications is not really an appropriate use of WLM controls. WLM can run workloads at different dispatch priorities but this does not protect the LPAR s CPU resource. Higher importance work may be better protected but the overall capacity being caused by the misbehaving application is still going to be used. Therefore lower importance work which is still valuable to the installation is still going to z/os Performance: LDAP and WLM Page 5

6 be impacted by the spamming client application. And for installations using sub capacity pricing models the overall amount of MSUs used by the LPAR still sets the overall software price for the software stack. The only true availability comes from identifying the misbehaving workload and stopping it, not from running it at lower dispatch priorities. From a WLM perspective what would have provided relief would have been to isolate the spamming workload to an enclave in a unique service class and then have the service class have a maximum resource group applied to it to prevent the workload from using up the CPU resource in the LPAR. It is exactly the use of this technique which led to the discovery of the issue with the LDAP support having just a single thread pool regardless of the number of enclaves created. By placing a resource group on the spamming workload and limiting its CPU consumption the entire LDAP environment saw significant throughput delays. Keep in mind the recommendations in this paper are for production LDAP servers. It is very viable to have test and production LDAP servers in the same system or sysplex. In such a case it is still acceptable to define the test LDAP server with less aggressive WLM goals. The recommendation for not creating multiple service classes within the test environment should still be followed. If wlmexcept functions need to be used or tested then WLM report classes should be used and not WLM service classes. Conclusion It is strongly recommended installations do not take advantage of the LDAP ability to separate workloads into different WLM service classes to improve availability. Instead the LDAP workloads should be defined to an existing service class with a high velocity and high importance. Typically the service class for high importance started tasks should be used. For additional information on this support please review the DOC APAR OA z/os Performance: LDAP and WLM Page 6

7 Copyright IBM Corporation 2012 IBM Corporation New Orchard Rd. Armonk, NY U.S.A Produced in the United States of America 03/12 All Rights Reserved IBM, the IBM logo, AIX, CICS, DB2, DFSMS/MVS, DFSORT, DS8000, ESCON, FICON, RACF, Rational, REXX, RMF, System p, System z, System z9, VTAM, WebSphere, xzeries, z9, and z/os are trademarks or registered trademarks of International Business Machines Corporation of the United States, other countries or both. Intel, Intel logo, Intel Inside, Intel Inside logo, Intel Centrino, Intel Centrino logo, Celeron, Intel Xeon, Intel SpeedStep, Itanium, and Pentium are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. ITIL is a registered trademark, and a registered community trademark of the Office of Government Commerce, and is registered in the U.S. Patent and Trademark Office IT Infrastructure Library is a registered trademark of the Central Computer and Telecommunications Agency which is now part of the Office of Government Commerce. Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both. Linux is a registered trademark of Linus Torvalds in the United States, other countries, or both. Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both. UNIX is a registered trademark of The Open Group in the United States and other countries. Other company, product, or service names may be trademarks or service marks of others. Information concerning non-ibm products was obtained from the suppliers of their products or their published announcements. Questions on the capabilities of the non-ibm products should be addressed with the suppliers. IBM hardware products are manufactured from new parts, or new and serviceable used parts. Regardless, our warranty terms apply. IBM may not offer the products, services or features discussed in this document in other countries, and the information may be subject to change without notice. Consult your local IBM business contact for information on the product or services available in your area. All statements regarding IBM s future direction and intent are subject to change or withdrawal without notice, and represent goals and objectives only. Performance is in Internal Throughput Rate (ITR) ratio based on measurements and projections using standard IBM benchmarks in a controlled environment. The actual throughput that any user will experience will vary depending upon considerations such as the amount of multiprogramming in the user s job stream, the I/O configuration, the storage configuration, and the workload processed. Therefore, no assurance can be given that an individual user will achieve throughput improvements equivalent to the performance ratios stated here. z/os Performance: LDAP and WLM Page 7