This is a discussion on how to configure the different TRIRIGA Platform Agents to start-up on N-Tiered systems.
Most of the agents are single-instance, and do not allow multiple instances to be run on multiple servers. The exception to this are the two multi-instance agents: Workflow Agent, Reserve SMTP Agent and Data Import Agent. Problems can occur if single-instance agents are attempted to be run simultaneously. The Agent Manager across the servers will prevent single-instance agents from being started multiple types.
The following outlines some different common n-tier server configurations.
Case 1 Two Servers: Application Server and Process Server
The first case we'll examine is where there is a Application Server, and a Process Server. The Application server is where the end users sign in to, and the Process Server is where the majority of agents are running.
These are where the agents should be running:
Application Server: DataImportAgent, ReportQueueAgent
Process Server: CleanupAgent, DataConnectAgent, DataImportAgent, ExtendedFormulaAgent, FormulaRecalcAgent, IncomingMailAgent, ObjectMigrationAgent, ObjectPublishAgent, ReserveSMTPAgent, SchedulerAgent, WFAgent, WFFutureAgent, WFNotificationAgent
Note, for Agents like the IncomingMailAgent or WFFutureAgent can be disabled if you don't have the license are not using those features.
Case 2 Three Servers: Two Application Servers and a Process Server
This case the Application Server is split into two servers, with some sort of "stick session" load balancing. We only need to run the ReportQueueAgent on one of those servers, that is where the users will be redirected once the report has completed running in the background:
Application Server 1: DataImportAgent, ReportQueueAgent
Application Server 2: DataImportAgent
Process Server: CleanupAgent, DataConnectAgent, DataImportAgent, ExtendedFormulaAgent, FormulaRecalcAgent, IncomingMailAgent, ObjectMigrationAgent, ObjectPublishAgent, ReserveSMTPAgent, SchedulerAgent, WFAgent, WFFutureAgent, WFNotificationAgent
Case 3 Four Servers: Two Application and Two Process Servers
When splitting up the process server, you could consider one process server the main Workflow server, and the other the main Extended Formula Agent server. While the Workflow Agent can run on both process servers, less threads should be allocated two the server running the Extended Queue agent. This is to allow more resources to be available to the Extended Queue Agent. For example, Process Server 1 can start out with 10 WF Agent Threads, while Process Server 2 could start with 5. When deciding on the other agents, you can spread the load across the two process servers. A tuning exercise should be done to best determine the number of threads is optimal for each server.
Application Server 1: DataImportAgent, ReportQueueAgent
Application Server 2: DataImportAgent
Process Server 1: CleanupAgent, DataImportAgent, FormulaRecalcAgent, IncomingMailAgent, ReserveSMTPAgent, WFAgent, WFFutureAgent, WFNotificationAgent
Process Server 2: DataConnectAgent, DataImportAgent, ExtendedFormulaAgent, FormulaRecalcAgent, ObjectMigrationAgent, ObjectPublishAgent, SchedulerAgent, WFAgent
Taken from https://www.ibm.com/developerworks/community/forums/html/topic?id=77777777-0000-0000-0000-000014916192
Friday, August 8, 2014
IBM TRIRIGA Application Platform Installation Information
Before
you install IBM TRIRIGA Application Platform
Installing
IBM TRIRIGA Application Platform
Verification
Checklist
Configuring
the Platform
IBM
TRIRIGA Application Platform Performance Wiki
System
Sizing
Capacity Planning and
Performance Overview
As with any web based platform, the application server and
database capacity needed to deploy a system built using IBM TRIRIGA Application
Platform largely depends on the number of anticipated users and user requests.
The limits of what is needed are determined by how users are
expected to use the system. At a minimum, enough server capacity to satisfy the
average load during a work day will be required, with response times that are
acceptable to the user base. If possible, strive to satisfy the volume of
requests anticipated during peak intervals of high user activity. Hardware
resources such as CPU, memory, I/O capacity, and network bandwidth are key to
reducing response times. Unless you install IBM TRIRIGA on a server or group of
servers that can handle a large number of transactions, users are probably
going to experience slow response times.
Adding more servers and
database capacity can sometimes improve IBM TRIRIGA's performance, but that is
not always the case. The application usage and system configuration can play a
significant role in the balance of system performance. Please see the IBM
TRIRIGA Application Platform Best Practices for System Performance
white paper for more information on tuning the environment.
Sizing &
Estimation Methodology
Estimating anything can be a complex and error-prone process.
That’s why it's called estimation, rather than a calculation.
There are two primary approaches to sizing a TRIRIGA
implementation:
- Size By Example Based
- Proof of Concept Based
Size-By-Example Based
A size-by-example (SBE) approach requires a set of known samples
to use as data points along the range of system size. The more examples
available for SBE, the more accurate the intended implementation will be.
Targeted SBE sizing solutions for prospective TRIRIGA customers
are provided in this wiki. These targeted solutions were compiled from our
internal deployments, performance benchmarks, and customer's external
deployments.
Proof of Concept Based
A proof of concept (POC), or pilot based approach, offers the
most accurate sizing data of all approaches.
POC Steps:
- Test your implementation design
- Test your chosen hardware
platform
- Simulate projected load
- Validate design assumptions
- Validate IBM TRIRIGA
- Provide iterative feedback for
your implementation team
- Adjust or validate the
implementation decisions made prior to the POC
There is, however, two downsides to a POC based approach, namely
time and money. Running a POC requires the customer to have manpower, hardware,
and the time available to implement the solution, validate the solution,
iterate changes, re-test, and finally analyze the POC findings. A POC is always
the best and recommended approach for any sizing exercise. It delivers results
that are accurate for the unique implementation of the specific customer that
are as close to deploying the real live solution as possible, without the
capital outlay on hardware and project resources.
Topic Categories
·
Hardware
Requirements
·
Software
Requirements
·
Hardware
Configuration
·
Development Environment
·
Basic (Small) Environment
·
Typical (Medium) Environment
·
Advanced (Large)
Environment – Coming Soon
Other Resources
·
IBM
TRIRIGA Release Notes
·
IBM
TRIRIGA Application Platform Compatibility Matrix
·
IBM TRIRIGA Application Platform Version 3 Installation and Implementation Guide
·
IBM
TRIRIGA Application Platform Version 3.3 Best Practices for System Performance
Servers
The
IBM® TRIRIGA® Application Platform uses many different types of servers. The
word "server" is often used to mean a physical piece of equipment,
but it can also represent a logical separation that is based on function. Each
of these logical servers can be collocated on physical servers, or separated so
that each logical tier is installed on their own physical server.
Alternatively,
each of these logical tiers can be installed on one or more virtual servers. In
turn, these virtual servers can be on a physical server, or a cluster of
physical servers in a virtual server cluster.
The
following logical function-based servers are used in the IBM TRIRIGA
Application Platform:
Web
server
Receives HTTP requests for web content. Also referred to as a front-end server.
Application
server Carries
out the user business logic with JBoss Application Server, Red Hat JBoss
Enterprise Application Platform, WebLogic Server, or WebSphere® Application
Server.
Process
server
Carries out the background processing and analytics with Red Hat JBoss Enterprise
Application Platform, WebLogic Server, or WebSphere Application Server.
Tools
server Carries
out the reporting. Holds other third-party tools such as Brava! Enterprise
Viewer for IBM TRIRIGA.
Database
server
Holds the relational database and supported database management system such as
Oracle Database or Microsoft SQL Server.
Web
server
The
web server is the tier with which each user web browser communicates. Examples
of web servers include IBM HTTP Server, Microsoft Internet Information Services
(IIS), and Apache HTTP Server. The web server handles HTTP requests only and
does not run business logic. The IBM TRIRIGA Application Platform also supports
Secure Sockets Layer (SSL) by using HTTPS. Typically, HTTP uses port 80
(non-secure connection) and 443 (secure connection), but it can be configured
to use other ports. Each time a user requests a JavaServer Page (JSP), the web
server passes the request to the application server for processing. The web
server is a physical manifestation of the web tier.
Application
server
The
application server is a Java virtual machine (JVM) with an instance of the
runtime application. This server runs most of the business logic. Application
server processes are CPU-intensive and require a great deal of memory. The
application tier consists of JavaServer Pages (JSP) and Java classes. The Java™
2 Platform, Enterprise Edition (J2EE) application server provides a JSP
container, a database connection pool, and transaction management services. The
application server is a physical manifestation of the application (middleware)
tier.
Process
server
The
process server is a JVM with an instance of the runtime application that is set
up as a dedicated processing or analytics engine. This server is configured
almost exactly like an application server, but no users sign on to this server.
It handles all workflow requests that are queued from users or by the IBM
TRIRIGA software. The process server is a physical manifestation of the
application (middleware) tier.
Tools
server
The
tools server houses the two major third-party extensions from IBM TRIRIGA. This
server can run the optional Brava! Enterprise Viewer for IBM TRIRIGA or
optional Business Intelligence and Reporting Tools (BIRT) process server or
both. You can designate a IBM TRIRIGA application server as a BIRT process
server. If you choose to run both BIRT and IBM TRIRIGA on the same server,
expect BIRT report handling operations to increase the load on the server. BIRT
is run in the same JVM as IBM TRIRIGA in all cases.
Brava
is a web-based client-server package that provides view, markup, and
collaboration functions. Viewers use a thin client to display documents that
are rendered by the server. This process eliminates many compatibility issues
and lowers the number of software applications that are needed by users.
Database
server
The
database server runs the database process. The database is where data is
stored. The major database servers use Structured Query Language (SQL) to store
and retrieve data. The Oracle Database server and Microsoft SQL Server use SQL.
But each server is a different database engine and each has its own extended
SQL for competitive differentiation. The application tier communicates with the
database tier by using JDBC connection pools. The database server is a physical
manifestation of the database tier.
Subscribe to:
Posts (Atom)