Description of the SUT used with Part 1

The system under test (SUT) was a single ECM node with the applications IBM® FNP8 CPE and ICN for Linux™ on z Systems™ installed. Both applications ran via a WAS environment.

The SUT also included front-end and back-end server components, such as:
  • IBM IHS as Web server
  • IBM ITDS as Directory Service Provider
  • IBM DB2® database server
The SUT followed a 3-tier architecture model, enabling client components to interact with data resources and legacy applications, with logical tiers distributed across independent systems:
  • Client components on external machines (tier one)
  • ECM server components on the z Systems server (tier two)
  • Back-end components (for example database server) on the z Systems server (tier three)
Tier one components are typically responsible for the presentation and user interaction of second-tier processes. These components never access any third-tier services for example on database servers directly. Tier one would either be:
  • A Web browser displaying the Content Navigators user interface.
  • A custom application based on the Content Navigator APIs for the SUT.

For this case study, the virtual ICN users were simulated with a workload that was implemented via the IBM Rational® Performance Tester (RPT) and that called various functions from ICN user interface.

Tier two components, also known as the application logic layer, manage the business logic of the applications and provide access to third-tier services. Usually it is the layer where most of the data processing occurs. The application logic layer for the SUT is represented by:
  • The Web server IHS
  • The ECM components ICN
  • FNP8 CPE

Tier three components are protected from direct access by any tier one components. Usually they reside in a secure network (for example inside the z Systems server). Interaction is only possible through the second-tier services. The DB2 ECM database server and Directory Service Provider are considered as third-tier services for the SUT.

Figure 1. How the SUT was configured for the XFS FNP8 CPE File Storage Area

This graphic provides an overview of how the SUT was configured for the XFS FNP8 CPE File Storage Area.
The SUT was implemented in an IBM z Systems™ server LPAR that runs a z/VM® hypervisor for a virtualized environment.
  • The ECM components were installed in single node WAS clusters.
  • ICN and FNP8 CPE were each deployed in their own single node WAS cluster.
  • The FNP8 CPE Advanced File Storage Area was 600 GiB large and resided either on an XFS highly scalable filesystem or on a Spectrum Scale parallel filesystem for the first part of the case study.
The performance of both filesystems as FileNet® Advanced File Storage Area is considered in the results section.

Components of the ICN application were mapped to the Web server IHS. IHS was used to manage the HTTP traffic for ICN and to do the request balancing for the multiple ECM node setup (is described in the follow-on Part 2 white paper).

The WAS clusters, the WebSphere® Deployment Manager (Dmgr) and IHS together form a WebSphere Deployment Cell.

The IBM DB2 ECM database server maintained three different databases:
  • FNP8 CPE Object Store database
  • FNP8 Global Configuration Data (GCD) database
  • ICN database

The ITDS Directory Service Provider provided authentication methods for usernames and passwords for the ECM system.

For guest-to-guest communication, a z/VM Virtual Switch (VSWITCH) was used that also provided LAN access via a 10GbE OSA-Express® network card.

The load generator for ICN was a x86_64 machine running the IBM Rational Performance Tester (RPT) application with a custom workload. The x86_64 machine was connected over a 10GbE network to the IBM z Systems server.

Note: The WAS cluster was scaled-out to a multi ECM node cluster in the Part 2 follow-on case study. The performance test results for the multi node study are described in the Part 2 white paper.

The next figure basically shows the same layout of the SUT. The only difference is that the FNP8 Advanced File Storage Area is now on a 600 GiB Spectrum Scale filesystem.

Figure 2. How the system under test (SUT) was configured for the Spectrum FileNet File Storage Area

This graphic provides an overview of how the system under test (SOT) was configured for the Spectrum FileNet File Storage Area.

The single ECM node used the Spectrum Scale cluster configuration Shared Disk, which means that the FCP/SCSI disks were directly attached to the node. A single node Spectrum Scale cluster is the most basic cluster setup with no high availability. This simple Spectrum Scale cluster was used for the comparison to the XFS filesystem.