Understanding the IBM FileNet P8 domain structure in a container environment

In a container environment, the physical resources remain similar to the ones in a traditional IBM WebSphere® Application Server managed environment with a few exceptions. These exceptions, if applicable, are discussed in the help topics that are related to each entity.

However, for the Content Platform Engine servers that provide access to those resources, the mapping of the conceptual FileNet P8 domain structure of site > virtual server > server instance is adapted to better fit in a container environment.

The section describes the configuration parameters for CP4BA containers.

Site

A domain can have one or more configured sites. Each site is identified by a unique name and has associated resources such as object stores, index areas, advanced storage areas, and virtual servers.

When a Content Platform Engine instance in a geographically dispersed environment processes a user request, it determines what resources it needs to process the request and uses the site information in these resources to determine how best to process the request. If the feature to forward requests is enabled and configured, information about the site includes which virtual servers can participate in the forwarding of Content Platform Engine requests. For more information on the request forwarding feature of the Content Platform Engine, see Request forwarding. For more information on the requirements to support request forwarding in a containerized deployment, see Understanding a geographically dispersed FileNet P8 domain.

A IBM Content Search Services instance is associated with a site and can be used by any object store in the same site to create and search indexes. Index areas that are managed by that Content Search Services instance must be locally accessible with read- and write-access from all Content Search Services instance at the same site.

As virtual servers, object stores, and other resources are added to the domain, they are assigned to the default site, unless a different site is explicitly specified. A user with system administrator privileges can change the site that is used as the default. A system administrator can also move resources between sites. For example, a virtual server instance can be moved from the initially assigned default site to a site that reflects its true geographic location.

Virtual server

A virtual server (VS) is the logical service point that Content Platform Engine clients interact with. Virtual server objects are created dynamically during system initialization and startup. A virtual server can contain one or more server instances. Applications accessing the virtual server are unaware of the number or type of server instances that reside behind the virtual server.

The name of the virtual server object is based on the metaname that is given when the Content custom resource (CR) defining the containerized environment is deployed. So, if multiple Content instances serve the same FileNet P8 domain, like in a multi-zone configuration, the custom resources must be named differently for each.

Server instance

A Content Platform Engine server instance (SI) is an individual Java™ Platform, Enterprise Edition (Java EE) application server instance. Multiple server instances, each running in their own Java virtual machine (JVM), can be hosted in a single Kubernetes cluster. (Multiple server instances are a common configuration especially when support for high-availability is required). Content Platform Engine clients do not interact directly with a server instance; logically, clients always go through a virtual server.

General

Virtual servers and server instances are created in the global configuration (GCD) database when the Content Platform Engine container (pod) is started. But the virtual servers and server instances are not removed from the global configuration database when:

• A particular Content Platform Engine container (pod) is stopped.
• The Content Platform Engine deployment is removed.
• Or, the entire Content instance is deleted.

Certain internal logic assumes the objects that represent the virtual servers and server instances are relatively stable.

To achieve stability for server instance objects in the global configuration database, server instances are named by using a predictable pattern. The pattern consists of a prefix that uses the Content custom resource instance name followed by ‘cpe’ and a number. Thus the server instance names take the form <CR name>-cpeNN, where, NN is 01, 02, and so on.

A registry scheme that is managed by logic in the startup of each Content Platform Engine container selectively reuses SI names. As a result, a new container that starts up is assigned the SI name of a previously terminated container if possible, or it is assigned a new name based on the predictable pattern. This achieves the following:

• Bounds the number of SI objects that are present in the GCD to approximately the high watermark of active pods.
• Bounds the number of <server-instance> directory trees created in the shared PV to which the FileNet logs directory refers.
• Satisfies the requirement for stability of SI and VS names that are needed by Content Platform Engine internal logic, which is mentioned earlier in this topic.
• Allows pod startup even if the GCD is temporarily unavailable because the pod can use the GCD backup file that is created in the <server-instance>/GCD directory by the previous pod executing under that name.
• Reduces by a small amount the time that is needed to start a pod because the OIT deployment step (into <server-instance>/INSO) is not required.
• Bounds the set of places from which Content Engine and Process Engine system and trace logs must be gathered (from the <server-instance> directories). (When a pod starts under a previously used SI name, it appends to the log files written by earlier incarnations).

If virtual server or server instance objects in the GCD are obsolete due to a high watermark that is not expected to be reached again, they can be deleted following the warnings and procedure that is found in the topic Deleting a virtual server or server instance.