IBM® DB2® Content Manager for OS/390® (CM/390) is a content management product that provides a solution for the large enterprise for Web content management as well as image, document and rich media management. Whenever you begin to plan for a CM/390 solution, it is essential that you have a strategy for capacity planning and sizing. In this article I will summarize a strategy for capacity planning and sizing for Content Manager for OS/390 V2.3 based on my experiences with customers.
First, a little bit about CM/390. CM/390 V2.3 has been available since 1998. It was introduced as IBM EDMSuite ImagePlus VisualInfo Version 2.3 for MVS/ESA, and was renamed to CM/390 V2.3 in March of 2000. CM/390 was a port of the CM Multiplatform Windows® servers (that is, the Library Server and the Object Server). CM/390 uses the same CM V7.1 Sysadmin client and the same end user clients as the CM V7.1 Multiplatform (CM/MP) servers.
The CM/390 Library Server was implemented as a CICS®/DB2 application that can take advantage of CICS Terminal Owning Region (TOR) and Application Owning Region (AOR) technologies. It can have multiple CICS instances accessing a single CM/390 Library Server database.
The CM/390 Object Server was implemented as a CICS application that can take advantage of CICS TOR/AOR technologies as well. The CM/390 Object Server differs from the CM/MP Object Server in that the CM/390 Object Server utilizes the Object Access Method (OAM) feature of Data Facilities Systems Management Storage. OAM is a DB2/390 application used to manage the CM captured objects on DASD, tape or optical storage. OAM has directory tables to track object control information, which is similar to the CM/MP object server implementation. When the CM/390 object server stores an object on DASD, it is being stored as one or more rows in a DB2 table, unlike the CM/MP Object Server, which stores its objects as linear files. Figure 1 illustrates the components of CM/390.
Implementing a capacity and sizing strategy is important to meet or exceed service level agreements with end users. The approaches I will discuss below resulted from a study I performed for a major CM/390 customer.
For each of the following components, the characteristics are listed from greater to lesser impact on performance. The characteristic you would want to consider include:
- network traffic
- metadata usage
- folder usage
- workflow usage
- amount of storage input/output
The Library Server is a CPU-intensive application since it is a search engine. Activity is characterized by bursty network traffic made up of search criteria and search results. The objects metadata, including Object Server location, relationships (that is, documents in folders), and workflow are stored in DB2 tables.
The Object Server, on the other hand, is I/O intensive, since it must acquire or store the physical object from or to DASD, tape or optical storage.
Document conversions (such as conversion of TIFF files to GIF files) cause the greatest impact on Enterprise Information Portal (EIP) browser support CPU usage. If a document conversion is required, only one page at a time is sent to the browser. If there no document conversion, the entire object is passed to the browser, where a plug-in will handle the rendering.
In order to be able to estimate the resources you will require, you must first document your business needs and assumptions. Then, you must understanding key questions and their impact on resources is next. Collect input requirements for CM Sizer and the EIP Sizer from your end users, their application support group and their data center.
Below are some examples of business needs and assumtions that need to be documented:
- Need to integrate unstructured content with business applications, for example:
- Integration with popular applications like Siebel, SAP and Peoplesoft
- Ability to archive and easily access mail
- Workflows to streamline work processes
- Need for consistent reusable information to be available to disparate authorized sets of users over public or private networks
- Requirement for Web distribution of information, for example:
- Ability to support entire distributed ECM system on public network (as well as private
- Support of XML and HTML structured documents
- Need for full-functioned Web clients out of the box to reduce training and support costs
- Single sign-on for access to unstructured data via the Web
Some of the key questions for the CM document model are:
- How is it best to represent your content in terms of documents and folders?
- How many different types of documents and folders should there be? Should there be a different index class for each type, or fewer classes with distinguishing attributes?
- What attributes are needed to search for and distinguish the items within an index class? This affects the Library Server database size and access.
- How many folders will be created? This affects Library Server database size.
Some of the key questions for CM storage and retrieval:
- How man documents will be created in the system per day?
- How many documents will reside in the system at any one time? This is a most important question affecting all aspects of planning for the system
- What is the average size of the document? This affects Object Server storage.
- How many total documents will be retrieved each day?
- How many workstations are needed for scanning, workflow processing, and ad hoc search?
- For how many days will the documents be frequently retrieved? This affects the migrations schedule.
- How long do the documents remain in the system?
Some of the key questions for CM usage:
- When, and for how many hours, are people going to be doing their processing?
- Is the supplied client application sufficiently powerful to process the documents? If not, can user exits handle the difference?
- Should a custom application be written that would perform better than the Client Application for some processes?
- Could there be a defined workflow for the documents?
- How tightly does the CM system need to be integrated with an existing system?
- Will there be multi-platform Object Servers?
- Will there be centralized or decentralized Object Servers?
- If decentralized, what levels of availability are needed and will documents be archived to a central Object Server?
- Who is going to retrieve the documents and from where (i.e., LAN, WAN, and/or Web Access)?
Some of the key questions for CM EIP retrieval:
- If no document conversion is required (such as TIFF-amp;gt;GIF) then:
- What is the average size of the document?
- How many hours per day will documents be viewed?
- How many workstations are needed for scanning, workflow processing, and ad hoc search?
- If document conversion is required, then, in addition to above, what is the:
- Number of pages per document?
- Number of pages viewed per document?
- Number of times annotation is turned off rather than on per document?
- Number of page rotations per document?
- Number of zooms per document?
- Number of documents viewed per day?
- Number of hours per day documents will be viewed?
Note, the EIP Sizer is calibrated to EIP benchmarks where CM and EIP were running on a Windows NT workstation. There were measurements for documents that had to be converted (for example, MO:DCA toGIF) and documents that were not converted. There is no 'out of the box' document conversion when running EIP Browser support on AIXamp;reg;.
Follow these steps to perform the sizing:
- Have the CM and EIP sizers run for the scenarios you have decided upon based on the answers to the above key questions. Review the CM Sizer outputs for the scenarios.
- Evaluate workload requirements with CM/390 benchmarks (such as MIPS, throughput (LSFRs)).
- Estimate the number of CM worksets for the scenarios (such as number of CICS regions, number of LPARs and/or zSeries, number of Windows 2000 Object Servers).
- Evaluate the storage (DASD/optical/tape) requirements for the CM/390 Library Server, the CM W2K/AIX Object Server (destage if non-DASD) and OAM (holds object for CM/390).
- Review the EIP Sizer output for the appropriate scenario and evaluate the workload requirements with EIP benchmarks (such as page views per hour) to estimate the number of EIP Browser Support Windows 2000 workstations.
CM/390 MIPS are influenced by client implementation. The CM 'out of the box' client searches one CM/390 Library Server at a time. To search multiple CM Library Servers, you can use EIP 'out of the box' thin or thick client, or you can use the CM workstation or EIP APIs and develop a custom client. When you search multiple CM Library Servers in parallel, the result will be a multiplier effect on the total MIPS needed.
Consider the following examples:
- CM Client (search one CM/390 at a time)
1 * Total solution MIPS - CM APIs with custom app (search x CM/390s at a time)
x * Total solution MIPS
i.e., 3 CM/390 * 500 MIPS = 1500 - EIP federated search (search x CM/390s at a time)
x * Total solution MIPS
i.e., 3 CM/390 * 500 MIPS = 1500 - EIP APIs with custom app (search x CM/390s at a time)
x * Total solution MIPS = 1500
i.e., 3 CM/390 * 500 MIPS = 1500
If you develop a custom CM client using CM or EIP APIs, you could design a filtering approach to designate which CM/390 worksets to send display store requests to. This would eliminate the parallel search request and thus reduce the MIPs required.
The CM/390 MIPs required are also affected by the Object Server platform. If the Object Server is not z/OSamp;reg;, than the MIPs required will be cut approximately in half since you are off-loading the Object Server function to another platform.
In a distributed scenario, where the primary copy of the object is on CM Windows 2000 or AIX for a period of time before being migrated to the CM/390 Object Server (Archive), the MIPs will be reduced as compared to centralized scenario. If replication is implemented, the MIPs will increase since a copy of the object is delivered to the CM/390 Object Server shortly after the primary copy is stored in the CM Windows 2000 or AIX Object Server. If LAN cache on the CM Windows 2000 orAIX is used, MIPs could be reduced, since a copy is located on the distributed CM machine and a display request would retrieve the LAN cache copy.
CICS TOR/AOR technology was used in the CM/390 V2.3 benchmarks performed by IBM CM development. Which configuration you choose from the three I list here will determines the number of LSFRs (units of work that the CM benchmarks used) you will require:
- One TOR w/ One AOR (1.00 x #LSFR/hour)
- One TOR w/ Two AOR (1.85 x #LSFR/hour)
- One TOR w/ Three AOR (2.14 x #LSFR/hour)
As part of your planning process, you should size each CM/390 workset's database for the CM/390 Library Server and OAM. For sizing the library server database see:
- IBM CM for Multiplatforms Planning and Installing Content Manager V7.1, GC27-0864-00, Chapter 1, Planning your Content Manager system, Planning for DB2 tables in OS/390.
For sizing the OAM database see the appropriate DFSMS publication for release of OS/390, z/OS that you are currently on. Below is a list of of the DFSMS publications.
- DFSMS Storage Administration Reference
- OAM Planning, Install and Storage Administration Guide for Object Support
- OAM Planning, Intall and Storage Administration Guide for Tape Libraries
A CM workset is made up of:
- One or more CM/390 Library Server CICS regions
- One or more CM/390 Object Server CICS regions
- One OAM
- One or more CM/Windows 2000 Object Servers
The hardest part of capacity sizing is getting your end users, their application support group and their data center to make assumptions without having the assumptions change on a daily basis. You must document your business needs and assumptions in order to plan capacity. Make sure you understand the key questions listed in this article and apply a consistent methodolgy for successful capacity planning and sizing.
Michael Heyl is a certified Sr IT Specialist with the Image Content Management Center (ICC) within the America's Advanced Technical support. Michael has been with the ICC for the past 14 years, providing presales technical support for Content Manager for OS/390, Enterprise Information Portal and ImagePlus® for OS/390. Michael has had held system engineering jobs over an 8-year period in various organizations within IBM as well as 7 years as an IBM customer in application/systems programming.
Comments (Undergoing maintenance)
Table of contents
Local resources
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
