maximo architectural decisions

Document: EAM_Toolkit_Architectural_Decisions_V2.2.doc Date: 02-11-2014 Path: Owner: IBM Version: 2.2 Status: Final Subject: Maximo Architectural Decisions of 19

Maximo Architectural Decisions

Author: Bill Cary

Owner: IBM


Contents

Legal disclaimer ................................................................................................................................................................. 2

Introduction ........................................................................................................................................................................ 4

Document Description ....................................................................................................................................................... 4

Platform and Reliant Technology Selection ..................................................................................................................... 4 Database Platform Selection.......................................................................................................................................... 4 Application Server Platform Selection ......................................................................................................................... 5

Application Security Methodology ................................................................................................................................... 6

Application Customizations and Configurations............................................................................................................. 8

External Data Integrations ................................................................................................................................................ 9

Administrative Console Deployment .............................................................................................................................. 10

Load / Scalability and Fault Tolerance/Availability ..................................................................................................... 11 Enterprise Asset Management Architecture Overview for 1 to 35 Users ....................................................................... 13 Enterprise Asset Management Architecture Overview for 36 to n Users ....................................................................... 14

Data Search Functionality ............................................................................................................................................... 18

Legal disclaimer

This document is provided pursuant to the terms of the IBM developerWorks Agreement. It is provided for your internal use only and may not be republished in whole or in part or distributed outside your business enterprise. Its use is subject to those terms as well as the following terms.

The information provided in this document was designed and developed from the existing know-how and experience of IBM. Information provided has been developed as a collection of the experiences of technical services professionals over a wide variety of IBM Client and internal IBM environments, and may be limited in application to those specific hardware and software products and levels.

The information contained in this document has not been submitted to any formal IBM test. The use of this information or the implementation of any of these techniques is your responsibility and depends on your ability to evaluate and integrate them into your operational environment or that of your customers. While each item may have been reviewed by IBM for accuracy in a specific situation, there is no guarantee that the same or similar results will be obtained elsewhere. Your attempt to adapt these techniques to your own environments or those of your customers is at your own risk, and in some environments you may not achieve all the benefits described. IBM does not warrant or guarantee that any results or performance described in the document will be achieved by you. You are solely responsible for the results obtained from the use of the information contained within the document.

This document is provided “as is” subject to any statutory warranties which cannot be excluded, IBM makes no warranties or conditions, express or implied regarding the document and its content, including but not limited to any implied warranties or conditions of merchantability, satisfactory quality, fitness for a particular purpose, title and any warranty or condition of non-infringement.


This information could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions of this publication. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time without notice.

IBM may not offer the products, services, or feature discussed in this document in all countries. Consult your local IBM representative for information on the products and services currently available in your area. Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, program, or service may be used. Any functionally equivalent product, program, or service that does not infringe any IBM intellectual property right may be used instead. However, it is the user’s responsibility to evaluate and verify the operation of any non-IBM product, program, or service.

IBM may have patents or pending patent applications covering subject matter described in this document. The furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing, to:

IBM Director of Licensing IBM Corporation North Castle Drive Armonk, NY 10504-1785 U.S.A.

Any references in this information to non-IBM Web sites are provided for convenience only and do not in any manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the materials of this IBM product and use of those Web sites is at your own risk.

Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products. All statements regarding IBM's future direction and intent are subject to change or withdrawal without notice and represent goals and objectives only.

Any performance date contained in this document was determined in a controlled environment. Therefore the results obtained in other operating environments may vary significantly. Some measurements quoted in this document may have been made on development-level systems. There is no guarantee that these measurements will be the same on generally available systems. Some measurements quoted in the document may have been estimated through extrapolation. Actual results may vary. Users of this document should verify the applicable for their specific environment.


Introduction

The purpose of this document is to help the implementer understand the architecture and the decisions that must be made during implementation to maximize the functionality and performance of the system.

Document Description

The Architectural Decisions work product is a roadmap guiding the user on best practices in making critical planning and technical design decisions for Enterprise Asset Management (EAM) implementations. It provides an overview of the main IT elements and their relationships in the architecture, which frequently include candidate subsystems, components, nodes, connections, data stores, users and external systems. Although the focus of this Architectural Decisions document is Asset Management, the underlying architecture of many related Integrated Service Management (ISM) products is the same and may benefit from this same decision making process. The Architectural Decisions Document can be introduced at any time over the life of a product when assessing application scalability, health, performance, and status or planning for growth; however, the most valuable use of the Architectural Decisions document is during the planning stages of any new implementation. This document provides the implementation team the opportunity to correctly cost and size the environment for the immediate requirements while planning for future growth, and high availability requirements. This document describes the critical Architectural Decision points for the system .

Platform and Reliant Technology Selection

Database Platform Selection

IBM supports the use of three (3) core database platforms with the EAM product suite (see the published compatibility matrix - https://www.ibm.com/support/docview.wss?uid=swg27014419 - for specific version support of these platforms). The EAM architecture uses a close variant of ANSI SQL through Java Database Connectivity (JDBC) to store and retrieve data in databases. This design provides flexibility in supporting multiple database platforms but limitations in leveraging database platform specific functionality such as server side stored procedures. For this reason, all database platforms used with this technology are not created equal. A detailed understanding of a clients existing platform knowledge, the projected load expected, and the best support model for this implementation must be considered in the selection of the database platform. IBM DB2 is one of the most commonly selected platforms. Because IBM can provide a single vendor option for the software stack, it is common for clients to select IBM AIX as the operating system, IBM WebSphere as the application server, IBM DB2 as the database and IBM Maximo as the Asset Management software. This single provider approach often reduces the cost of the solution through bundling, improves the supportability of the software stack, and eliminates communication barriers between vendors. Oracle Database Server is a powerful platform option with over twenty (20) years of support in the IBM Maximo environment. Oracle is a leading producer of database software with high transaction rates and many capabilities for fault tolerance, mirroring and scalability.

https://www.ibm.com/support/docview.wss?uid=swg27014419

https://www.ibm.com/support/docview.wss?uid=swg27014419%20


Microsoft SQL Server is often a cost effective database platform with extensive capabilities. Due to the architecture of SQL Server, much of its power comes from the execution of server side procedures called stored procedures. This functionality cannot be leveraged through the use of ANSI SQL employed by the TPAE architecture so that load capabilities have been demonstrated to be considerably lower than the other database platforms. IBM testing and experience has shown that while transaction rates keep pace across all three (3) database platforms up to two hundred fifty (250) concurrent users (1250 application transactions per minute), transaction processing begins to slow on SQL Server while the other two platforms maintain steady results up through thousands of concurrent users. SQL Server can be an excellent choice for a client with lower projected concurrent users, an established client knowledge of the platform, and or cost analysis that can improve cost of ownership. The limitations should be noted with the client when selecting SQL Server and maximum concurrent EAM users should be limited to 250 on this platform. IBM DB2 is typically the recommended Database Server.

Subject Area Database Platform Selection Topic Architecture

Design

Architectural Decision

Determine the most cost effective and appropriate database platform to support the application.

ID AD-001

Issue or Problem Statement

At a high level, databases perform similar functionality but deciding which platform to use may depend on the scaled size of the user base, the client environment, the existing skill set, and the detailed functionality requirements.

Assumptions A database is required to support the application. Typically IBM recommends DB2 but there may be cases where other databases may be more appropriate.

Motivation Determines the specific requirements of the database platform and provides a solution to the application.

Alternatives DB2

Oracle

SQL Server

Implementation Decision

Justification

Implications

Application Server Platform Selection

IBM supports the use of two (2) core J2EE Application Server platforms with the Maximo EAM and SmartCloud Control Desk product suites (see the published compatibility matrix - https://www.ibm.com/support/docview.wss?uid=swg27014419 - for specific version support of these platforms). The EAM architecture uses Java as the code base for development of the EAM product suite. These products are J2EE compliant and require a J2EE application server for deployment. IBM WebSphere is one of the most commonly selected platforms. Because IBM can provide a single vendor option for the software stack, it is common for clients to select IBM AIX as the operating system, IBM WebSphere as the application server, IBM DB2 as the database and IBM Maximo as the Asset Management software. IBM WebSphere is the more robust of the two supported J2EE servers and has demonstrated substantial superiority in the areas of directory server support and JMS Queue management. This single provider approach can often improve the cost of the solution through bundling, improves the supportability of the software stack, and eliminates communication barriers between vendors.

https://www.ibm.com/support/docview.wss?uid=swg27014419

https://www.ibm.com/support/docview.wss?uid=swg27014419%20


Oracle WebLogic is a powerful platform option. WebLogic provides an intuitive user interface (UI) and minimizes the learning curve associated with deploying J2EE applications. For environments that are not J2EE savvy, WebLogic may be a good choice for accelerated administrative training but it should be noted that extensive integration with external products may be impacted by WebLogic JMS queue limitations. An important distinction between WebLogic and WebSphere is that WebSphere can support Tivoli Directory Server (TDS) and Virtual Member Manager (VMM) when using Application Server Security (Lightweight Directory Access Protocol - LDAP) for authentication. WebLogic cannot support these options. IBM WebSphere is typically the recommended J2EE Application Server.

Subject Area Application Server Platform Selection Topic Architecture

Design


Determine the most cost effective and appropriate application server platform to support the application.

ID AD-002


At a high level, databases perform similar functionality but deciding which platform to use may depend on the scaled size of the user base, the client environment, the existing skill set, and the detailed functionality requirements.

Assumptions A database is required to support the application. Typically IBM recommends DB2 but there may be cases where other databases may be more appropriate.

Motivation Determines the specific requirements of the database platform and provides a solution to the application.

Alternatives DB2

Oracle

SQL Server


Justification

Implications

Application Security Methodology

To understand the security methodology, it is important to understand the distinction between authentication and authorization. Authentication is where the user is authenticated as themselves by some mechanism to prove they are who they say they are. Once a user is authenticated, they are then verified as a valid user of a given resource such as a software application. Authorization is the privileges a given authenticated user has within the resource. An authenticated user may be authorized to use Maximo but may not have the rights to use the administrative applications of the Maximo. IBM Maximo EAM and SmartCloud Control Desk supports two (2) types of authentication mechanisms: Native Authentication and Application Server Security.

If Application Server Security is selected as a method, there are two (2) supported directory server platforms: IBM Tivoli Directory Server (TDS) and Microsoft Active Directory (MSAD). Both the TDS and MSAD implementations leverage the WebSphere Virtual Member Manager (VMM) and the VMM synchronization (VMMSYNC) tool to enable the authentication. MSAD can also use a direct synchronization tool (LDAPSYNC) to enable authentication without using VMM. This may be valuable in MSAD shops where


there is existing knowledge of MSAD syntax and functionality. Both TDS and MSAD authentication mechanisms can integrate with existing user directories.

Note: Since a TDS implementation uses VMM which is not available in Oracle WebLogic, TDS cannot be used with Oracle WebLogic. Native Authentication is built into the IBM Maximo and SmartCloud Control Desk suite of products. When this form of authentication is enabled, tools for creating users and groups are also enabled. Users and their encrypted passwords are stored in the application database. When a user uses a browser to access the application, initially the user is directed to a login page where they enter their credentials. The entered credentials are compared against the stored values in the application database and, once authenticated; the user is passed to the authorization phase of the login where application privileges are assigned.

Application Server Security can be enabled in the J2EE Application Server and facilitated by settings in the application. When this form of authentication is enabled, a directory server (IBM Tivoli Directory Server [TDS] or Microsoft Active Directory [MSAD]) is used to store user information. A directory server is a centralized unified collection of user information that may be utilized by many network applications. The benefits of a directory server are centralized and simplified user management and for users, a single pairing of username/password credentials for multiple applications. When Application Server Security is enabled and a user uses a browser to access the application, the application server (WebSphere or WebLogic) intercepts the URL and checks for valid authentication against the directory server. Initially the user is directed to either a browser generated dialog box (basic authentication mode) or a login page (forms based authentication mode) where they enter their credentials. The entered credentials are compared against the stored values in the directory server and once authenticated; the username is passed through to the application and the authorization phase of the login where application privileges are assigned. Note: This is called Application Server Security because the application server controls whether the user is authenticated or not and only passes authenticated users to the application. IBM recommends deployment with WebSphere Application Server (WAS), Tivoli Directory Server (TDS) and the VMMSYNC task to synchronize users from the directory server to the application.

Native Authentication Process

Application Server Security Authentication Process


Subject Area Application Security Methodology Topic Architecture

Design


Determine the most appropriate authentication model.

ID AD-003


Authentication can be either Application Server Security (LDAP default) or native. Which model to use is dependent on the environment? The Tivoli Directory Server (TDS) is included with the default install of the application when installing with WebSphere Application Server (WAS).

Assumptions A user must be authenticated before application authorities can be assigned.

Motivation Determines which authorization mechanism will be used and if LDAP, which directory server will be used with it.

Alternatives Native

Application Server Security with WAS, TDS, VMMSYNC

Application Server Security with WAS, MSAD, VMMSYNC or LDAPSYNC

Application Server Security with WebLogic, MSAD, LDAPSYNC


Justification

Implications

Application Customizations and Configurations

The Maximo Enterprise Asset Management (EAM) family of applications, like any application built on the TPAE platform, are very flexible in meeting business needs. Through a simple user interface, modules called Application Designer and DBConfig can add data tables, add/modify columns, change data structures, link data, change the application UI, and develop conditional UI functions. In addition to these tools, scripting can be used to develop all forms of business logic within the application. All of this type of work done with provided tools can be considered application configuration. Another way to develop business logic within the application is by extending and writing Java classes to perform specialized function. This type of modification is called customization. IBM recommends that customization be minimized. Custom work is typically expensive to develop and document, difficult to test and support, and hard to maintain. Though every effort is made to build standardized approaches to customization so that it is upgradeable, a lengthy comparison is typically required during the upgrade process to determine compatible and new functionality. Most functionality can be obtained using configurations tools.


Subject Area Customizations and configurations Topic Customization and

Configuration


Define the business processes that deviate from the application default and determine if customization is required. Note: IBM recommends against customization if possible.

ID AD-004


At a high level, what changes to code / java extensions are required to meet business process requirements. What configurations including custom applications, additional tables and columns, screen modifications or other application supported configurations are required to support the client requirement. These types of changes should be avoided if possible. It is not only expensive to modify and support but upgrades can be substantially complicated by customizations. This will increase the time and expense of upgrading and may impact the enterprise ability to remain current on the product. ROI is nearly always impacted by these types of changes. Historically, customizations were the only way to address unique business process requirements but now scripting can address many if not all of these and this is a far better option.

Assumptions There is some requirement for modifying the applications out of the box functionality.

Motivation Determines the specific areas that have not been tested by IBM prior to shipping the product which may need additional focus for best practices.

Alternatives Use the product as shipped

Configure the product using the configuration tools provided with the product

Use scripting to address business process requirements

Combination of configuration and customization

Customize the product logic using Java class extensions


Justification

Implications

External Data Integrations

An important aspect of Enterprise Asset Management is its ability to co-exist and integrate with complimentary systems. Enterprise Resource Planning (ERP) systems, financials, inventory, condition monitoring systems, and meters are just a few of the many types of systems that might need to work in concert with EAM. Maximo applications are built on the Tivoli Process Automation Engine (TPAE) base services architecture. TPAE includes a robust collection of tools called the Maximo Integration Framework (MIF) to help build integrations. There are many decisions related to the configuration of integration. What will be integrated, what protocol will be used, how the JMS queues will be configures, how the records will be processed, how errors will be handled, and more. To be successful in building integrations, it is important that implementers attend MIF training


Subject Area Asset Management External Data Integrations Topic Data Integration


Define the integration points to be used in this project as well as the volume of data

ID AD-005


Determine the number, type, frequency, and volume or data integrations with external systems

Assumptions The majority of clients use some form of integration either to an ERP, some financial system, or some external data repository.

Motivation Identifies the integration points to be created as well as the volume of data and number of transactions that will be executed or sizing recommendations.

Alternatives N/A


Justification

Implications

Related Decisions

Administrative Console Deployment

The Administrative Console is where the Maximo application is built and where some of the application tooling is stored. The Maximo application suite is a J2EE application built as a collection of Java classes, xml files, properties files, jsp files and more. Once all of the base configurations including the database connect string and custom classes have been completed, the files are compressed into an Enterprise Archive (EAR). An EAR file is really just a specialized zip or archive file. The EAR file is then deployed to an application server where it can be run. Good architecture dictates that the Administrative Console be in a separate operating system from the application server where the EAR file will be deployed. There is only one Administration Console but there may be one or more Application Servers that the EAR file will be deployed to. This separated configuration can smooth upgrade and patching operations for the infrastructure. IBM Recommends using a dedicated computer/server/operating system as the Administrative Console.


Subject Area Asset Management Family Administration Topic Administration


What equipment will be used for the Administrative Console where the initial install will occur?

ID AD-006


It is possible for the Administrative Server to be in the same physical/virtual environment as the application server where the application is deployed but it is recommended that a dedicated environment be used for the admin server.

Assumptions There are no functional problems using the admin console on a standalone computer/operating system. Trying to combine the Administrative Console on the Application Server can lead to future maintenance problems.

Motivation Simplicity and maintainability. Patching, maintaining, and upgrading the administrative server could impact the application runtime. Since the application does not require the administrative server during runtime (only for deployment), separating this function minimizes the complexity of the architecture.

Integrated Administration and Server functions may be clumsy and difficult to manage during a failover.

Maintenance of integrated admin console during patching is untidy.

Alternatives Deploy Administrative Workstation on a separate server or workstation

Deploy Administrative workstation on the same server as the application server


Justification

Implications

Related Decisions

Load / Scalability and Fault Tolerance/Availability

Scalability and fault tolerant decisions can be challenging and require a good balance between the cost and the performance of the solution. The Maximo EAM architecture provides a wide variety of functionality including:

A User Interface (UI) for clients to use the system

An embedded reporting engine for report generation

A cron task engine for scheduled functions

An escalation process engine for escalation activities based on business rules

An Integration Framework (IF) to allow real time data integration with external products

In addition to the above functionality, the base services / TPAE common component can be used to support Integrated Service Management (ISM) applications such as SmartCloud Control Desk. Generally, with all of this functionality deployed in an “all-in-one” JVM, the most concurrent users that can run stably on any single JVM is 35, however; the load is dependent on many factors including the type of work and frequency of background tasks. Transaction analysis should be done to determine the workload that can be supported by any single JVM. Using the amount of work required (scalability) and the required reliability


of the system to remain running (fault tolerance), it is important to understand how to architect a system that can grow in relation to load and remain available when people need to use it. The multi-tier Java architecture lends itself to easy scalability and fault tolerance. How the architecture is built initially will impact the flexibility of the system as requirements change. The basic rules of Enterprise Asset Management (EAM) and any Base Services / TPAE consumer architecture are as follows: Production EAM systems should always be deployed on 64 bit Hardware/OS configurations. 32 bit Java Virtual Machines (JVMs) combined with 32 bit operating systems are not capable of taking advantage of system configurations for maximized efficiency. 32 bit configurations can generally only support a single JVM before memory swapping will occur due to the limitation on direct access memory required by 32 bit JVMs. Memory swapping will impact performance. Note: a development system with a single JVM and only a few users could be deployed on a 32 bit system using 1536 for maximum allocated memory (-Xmx=1536); however, this is not a supported production environment configuration. There should be 4GB memory for the 64 bit OS and 4GB memory for each deployed JVM. IBM performance testing has shown that maximum performance is attained when both the minimum and maximum memory settings are set to the maximum memory allocation value for the JVM (example 4096 for 4GB). Note: the 4096 setting has been tested and shown to provide the best performance for typical fully utilized JVMs. A 64 bit EAM JVM may start up and run in less memory but if heavily utilized, may suffer stability or performance issues. There may also be rare cases where more than 4GB of memory could improve performance or stability. Some testing has shown improved performance with 6GB of memory allocated but it should be noted that the compromise is additional memory to be cleared using Java Garbage Collection (GC) and the GC cycles may be longer. Production systems should always run at least 2 JVMs. This provides a level of fault tolerance so that in the event of a failure on one JVM, the second JVM will continue to run. In the discussion below, note the wide range of trade-offs in determining the level of fault tolerance vs cost of employment. The multi-tier Java architecture lends itself to easy scalability. How the architecture is built initially will impact the flexibility of the system. The basic rules of Enterprise Asset Management (EAM) and any Base Services / TPAE consumer architecture are as follows: These recommendations assume fully utilized JVMs and may be able to be modified in non production environments. All production environments or test environments where load testing will be done should follow these recommendations. Production EAM systems should always be deployed on 64 bit Hardware/OS configurations. 32 bit Java Virtual Machines (JVMs) combined with 32 bit operating systems are not capable of taking advantage of system configurations for maximized efficiency. 32 bit configurations can generally only support a single JVM before memory swapping will occur due to the limitation on direct access memory required by 32 bit JVMs. Memory swapping will impact performance. In addition to the 1.5GB allocated to the JVM, there is JVM overhead associated with each JVM so that 32 bit system memory is generally sized at 2GB per JVM plus 2GB for each operating system instance. Note: a development system with a single JVM and less than 36 users could be deployed on a 32 bit system using 1536 for maximum memory (-Xmx=1536). Also note that a 32 bit JVM has a maximum capacity of 50 concurrent users while 64 bit JVM can support up to 75 users if no functionality other than UI is executing in the JVM.

There should be 4GB memory for the 64 bit OS and 4GB memory for each deployed JVM. IBM performance testing has shown that maximum performance is attained when both the minimum and maximum memory settings are set to the same value between 3072 and 4096. Since a 64 bit JVM can support up to 75 concurrent users and 3.5GB of memory should support this configuration, the recommendation is to set the maximum memory to 3584 (-Xmx=3584) and allow for up to 512M for JVM overhead. The simplified calculation is 4GB for each OS instance and 4GB for each JVM instance. Note: These settings have been tested and shown to provide the best performance for typical fully utilized JVMs. A 64 bit EAM JVM may run


in less memory but if heavily utilized, may suffer stability or performance issues. There may also be rare cases where more than 3.5GB of JVM memory allocation could improve performance depending on the workload.

Figure one below depicts a small implementation for supporting 1 to 35 users using vertical scaling. Note: Some smaller environments with high volume users and/or high transaction background tasks may also benefit from a more robust approach to deployment shown in the 36 to n configuration following this section.

Enterprise Asset Management Architecture Overview for 1 to 35 Users

To provide a level of stability and fault tolerance in a production environment, the small configuration for up to 35 users should be deployed as 2 JVMs in a cluster so that if one JVM fails, there is another for functionality to continue. In this scenario, both running JVMs have the capability to run all functionality. No separation of function is configured. Note: An added level of fault tolerance can be attained by building the second JVM on a second physical application server with the two servers front ended by a hardware load balancer. In this scenario, even if an entire physical application server fails, there is a failover to the second server. Note: The Maximo EAM products also support Oracle WebLogic as an Application Server and Oracle Database or Microsoft SQL Server as a database but there is value in obtaining the entire software stack from a single vendor so it is recommended that WebSphere and DB2 be used as middleware.

Figure 1


Enterprise Asset Management Architecture Overview for 36 to n Users

To provide enough processing power and a level of stability / fault tolerance in a production environment, the medium to large configuration for 36 to n users should be deployed as a minimum of 6 JVMs in clusters to support User Interface (UI), Cron Task/Escalation/Integration support, and Report server support. These JVMs can be built on a single physical server or on multiple physical servers. For the highest availability and fault tolerance of 150 concurrent users it makes sense to build one each of a UI, a Cron, and a Report JVM on 2 physical servers front ended by a hardware load balancer (horizontal scaling). In this scenario, even if an entire physical application server fails, there is a failover to the second physical server and all functionality is preserved. In this configuration, each UI JVM can support up to 75 concurrent users because the background functionality has been separated into non UI JVMs. 2 UI JVMs supporting 75 users each = up to 150 concurrent users 2 Cron JVMs supporting cron jobs, escalations, and integration framework 2 Report JVMs supporting Birt report generation

Figure 2


There are two things to note here. First, in the event of a server failure the system will continue to run, however; the UI JVM on the failover server will be loaded with all users which could lead to performance and/or stability problems on that JVM. Second, this is a minimum configuration for the 36 to 150 concurrent user scenarios. Additional separation of functionality may be required if:

There are more than 150 users

There are a large number of or frequently scheduled cron tasks

A large number of and frequently scheduled escalations

High quantities of incoming interfaced data from external systems As users exceed 75 concurrent per JVM, JVMs must be added to the cluster to support their load. For 151 to 225 concurrent users there should be 3 JVMs to support the UI functionality. For 225 to 300 there should be 4 JVMs to support the UI functionality etc… At the same time, as the implementation evolves, the cron tasks, escalations, integration volume and reports will change. Sizing for these types of background tasks can be correlated with users by determining the number of transactions per minute for each of these types of functionality. As a general rule of thumb a user can execute 5 transactions per minute. By calculating 5 transactions * 75 users the result is approximately 375 transactions per minute for a fully loaded JVM. Using 375 as an upper limit of transactions per minute the transactions can now be calculated for each function in a JVM. If an escalation runs every 5 seconds and performs 2 application transactions per run the result is 2 transactions * 12 (number of runs per minute) or 24 transactions. That single escalation is equal to approximately 5 users on that JVM. If there are 15 such crons or escalations on a JVM then the JVM has the equivalent of 75 concurrent users (5 *15=75) and additional work must be moved to another JVM. The calculation for memory on 64 bit systems can be expressed as follows: (<Number of Operating Systems> * 4 )+ ((<number of users> / 75) * 4) + ((Number of Cron Servers+Number of Report Servers+Number of Any Other Servers) * 4 )= <Number of GB of memory> so 2 physical servers (2 operating systems) with 150 concurrent users (150/75=2 UI JVMs), 2 Cron JVMs, 2 Report JVMs = (2*4)+((150/75)*4)+((2+2)*4)=32GB of memory required. The JVM calculation is similar excluding the numbers required for operating systems so the number of JVMs required is: (<number of users> / 75 + (Number of Cron Servers+Number of Report Servers+Number of Any Other Servers) = <Number of JVMs> (150/75)+(2+2)=6 And another way to calculate memory is (total JVMs * 4) + (total operating systems * 4) In this case it is (6 * 4) + (2 * 4) = 32GB or two 16GB servers The figure below depicts a fully fault tolerant environment. In this example the system can support 150 concurrent users (75 per UI JVM). All systems have a backup system. There are two (2) physical load balancers mapped to two (2) virtual load balancers There are two (2) physical servers used to support application functionality


There are two (2) physical servers used to support database functionality Users access a URL to a virtual load balancer which in turn directs them to one of two UI JVMs on two different physical servers. In the event of a physical failure of one of the load balancers, the virtualized load balancer will continue to function using the backup physical load balancer. In the event of a software failure on one server or even a physical failure of the application server, the second server will continue to function. Both application servers (and all JVMs) access the database using JDBC through a virtual load balancer with affinity set to the primary database server. The database server is mirrored and should the primary database server fail, requests are routed to the secondary database server. In this way, all systems have an automated fail over process. The weakest link in this design is, in the event of a UI JVM failure, the second UI JVM could be loaded with twice the work load and it could impact performance. This risk could be reduced by using 2 UI JVMs on each physical server (for a total of 4) to support 150 concurrent users.

Figure 3

Additional fault tolerance could be added by locating environments in different physical locations. As shown, fault tolerance is more of an academic discussion than a simple solution. The pros and cons of each aspect of fail over should be discussed and decided on in the context of a cost/benefit analysis..


Subject Area Load / Concurrent Users / Application Transactions per Minute / Scalability

Topic Load Balancing


How many JVMs are required to support the work load – This will drive hardware selection and sizing.

ID AD-007


How many JVMs are required and how should they be scaled?

Assumptions Load Balancing / and Fault tolerance are closely related. Vertical and Horizontal scaling provide both.

Motivation Performance, reliability, reduced cost.

Alternatives Single server combined functionality JVMs (could also include vertical scaling)

Single Server separated functionality JVMs (vertical scaling)

Multiple servers separated functionality (horizontal scaling, may also include vertical scaling)

Decision

Justification

Implications Application performance and stability are impacted by improperly scaled environments

Derived requirements

Hardware selection

Related Decisions

High Availability / Fault Tolerance


Subject Area High Availability / Fault Tolerance Topic High Availability /

Fault Tolerance


What level of fault tolerance should be used? ID AD-008


Fault tolerance should be driven by a cost / benefit analysis of lost productivity during down time. The cost of maintaining a system should not exceed the value obtained for having it up. If periodic downtimes are acceptable, the cost of fault tolerance can be substantially lower.

Assumptions There is a requirement of some percentage of up time for the application

Motivation Cost analysis and client acceptance

Alternatives No fault tolerance – there is no failover capability in the event of a system failure

Limited fault tolerance – only those items that cannot easily be recovered are protected

Full fault tolerance – All aspects of the application and reliant technology are protected


Justification

Implications

Derived requirements

Additional hardware and software required to support the fault tolerant solution

Related Decisions

AD007 - Load / Concurrent Users / Application Transactions per Minute / Scalability

Data Search Functionality

The Maximo application uses a number of different search methodologies to simplify the user experience. All searching is based on the database platforms capability. The field search types include: None – The field is not searchable. Exact – Text entered must match exactly for records to be found Wildcard – A “fuzzy” search type that can substitute any number of characters. Uses wildcard characters to find values generally matching the search criteria. Text – An algorithmic search capability used for long text values. Requires more understanding of search functionality to use its powerful capabilities. Maximo applications are shipped with most text fields set to “Wildcard” searching. This can simplify finding data for the user but puts a heavier load on the database server as it bypasses indexes, one of the core benefits of the database. Wildcard searching is fine on a case by case and when there are fifty users but using it for every search when there are thousands of users doing thousands of searches will impact the database performance for all users. Although search methods can be changed at any time, it is easier to train users from the start how to use wildcards if they need them than it is to retrain them when they have gotten used to a capability. For any medium to large deployment, implementers should seriously consider the implications of the search methodologies used and consider switching to “Exact” as a default behavior.


Using “Exact” as a default search method does not negate the use of wildcards but requires that the user enter them if they are needed. This can prevent the saved queries, workflows, escalations, and other configurations that may run frequently from being saved with unnecessary wildcards. It will be important to consider search methods throughout the entire application when changing methods. Changing the search method from wildcard to exact in the Workorder application but not in the Inventory application will confuse users who will not know what type of search to use where. For more detailed information on search methodologies see online support document 1321289

Subject Area Search Methodology Topic Data Searching /

Performance


What search methodology should be used for which field types?

ID AD-009


Searching is an important function in any system that stores large amounts of data from various sources. Searching must be simple for the users but also not impact the infrastructure. For medium to large environments, too much wildcard searching can impact system wide performance.

Assumptions

Motivation Stabile initial architecture to support growth with maximized performance

Alternatives Search capabilities None, Wildcard, Exact, Text


Justification

Implications

http://www.ibm.com/support/docview.wss?uid=swg21321289

maximo architectural decisions

Documents