Rollbase Scalability – Part One

Progress-logo-Rollbase-whitebackground

 

 

Whilst true scaling really depends on where the load is in your environment – every application may differ in terms of resource requirements – there are some basic guidelines to follow when building a scalable Rollbase infrastructure.

Basic Server Recommendations

Progress offers the following recommendations for servers – from a single system to a multi-server environment.

  • Run database servers and PAS or Tomcat servers on different physical machines (not on virtual machines using the same physical server).
  • Hosts for databases should have high performance CPUs and at least 8GB of RAM.
  • Hosts for PAS or Tomcat should have a 64-bit OS and have at least 8GB of RAM each (the more the better; also make sure to allocate as much as possible to your Tomcat heap).
  • If you are using Tomcat, be sure to install 64-bit versions of Java and Tomcat on each server.
  • To provide load balancing, use an Apache server to perform the routing of requests to the Tomcat instances. You can have as many of these Apache servers as needed for load balancing.
  • Perform load tests with an initial version of your infrastructure. This can help you identify areas of slow performance and give you time to adjust before you have thousands of concurrent users using the system.

Scalable Installations

Rollbase consists of a number of multi-tenant components that can be spread across multiple physical or virtual servers for scaling purposes or consolidated on the same server for smaller loads. The following list briefly describes each type of Rollbase component that makes up a full Rollbase instance. Each component can be isolated on its own server or combined with any other group of components on a shared server:

Progress Rollbase Components

  • Master System (Type: MASTER) monitoring, tenant provisioning, subscriber management, published application management, etc.
  • Production (Type: PROD) 1-N production servers; tenants are dynamically loaded onto the production server with the least load.
  • Database 1-N database servers; MySQL, OpenEdge RDBMS, Oracle or SQL Server; each tenant’s data resides in a shared database.
  • Workflow (Type: WORKFLOW) Manages all scheduled workflow event processes and automation.
  • Router (Type: ROUTER) Manages all user authentication and routing of requests to the appropriate production server.
  • Search (Type: SEARCH) A Lucene-based search engine that manages all indexing and search activity.
  • Storage (Type: STORAGE) Manages all document and file storage either directly or via Amazon S3.
  • SOAP (Type: WEBAPI – for legacy reasons) Manages all SOAP API requests.
  • REST (Type: REST) Manages all REST API requests.
  • RSS (Type: RSS) Manages all RSS feeds.

Initial Scalable Installation

So let’s go through the process of setting up an initial useful and, above all, scalable installation.

We are going to focus here on an architecture that has:

  • One Apache Server acting as the web tier and using mod_jk. The mod_jk connector is an Apache HTTPD module that allows HTTPD to communicate with Apache Tomcat instances over the AJP protocol. The module is used in conjunction with Tomcat’s AJP Connector component. Apache Tomcat uses Connector components to allow communication between a Tomcat instance and another party, such as a browser, server, or another Tomcat instance that is part of the same network. For example, the HTTP connector listens for requests over the HTTP/1.1 protocol on various TCP ports, and forwards them to the Engine associated with processing the request. We will be using workers.properties files to handle the routing.
  • A Main Server with all the services listed above except the Database and Production services
  • Two servers to provide a  Production Server functionality – Prod1 and Prod2
  • A single Database Server

See the diagram below for what this architecture actually looks like:

Scalability-Architecture-One

Ok, it’s pretty obvious that the second Production Server is not really required for a basic scalable installation, but it’s good to put it in there as it provides a modicum of load balancing. If you choose for your own reasons not to add the second production server that is fine – I will note where things are optional for that second Production Server (Prod2).

Before I go into the details of setting this up in the next article, I will give you some homework so you are ready to go.

Homework

There’s always homework. More so than death or taxes combined I think.

You will need access to four (Option: 5 to include Prod2) servers. I got all this running on my MacBook Pro Retina with 16GB of RAM with the following VM Container specs:

  • 2 Virtual Processors
  • 2 GB RAM

Note that  these are not production quality specifications – it is about learning the process. This will be sufficient to demonstrate that this works.

In terms of software:

  • A 64 Bit OS (your choice, so long as it can run Tomcat7 for the Main and Production Servers – you can mix OSes if you have a specific requirement for the DB) installed and patched into each VM container
  • Apache2 installed on the server designated as the Apache Server
  • Tomcat7 installed (7.0.42 or later) on the servers designated as Main Server and Production Servers
  • Your database installed on the designated Database Server
  • Record the IP addresses for Apache Server (I will refer to this IP as $APACHEIP$), Main Server ($MAINIP$) the one or two Production Servers ($PROD1IP$ and, optionally, $PROD2IP$) and the Database Server ($DATABASEIP$).

I am not providing instructions for each OS platform here as it would blow out the size of the article and might get in the way of you learning something.

For the database setup, I will be providing instructions for OpenEdge and MySQL. Our documentation covers other supported databases.

See you next time…

Next Article

In the next article we will setup our Apache Server and our Database Server.

Articles in this Series

Rollbase Scalability – Part One

Rollbase Scalability – Part Two

Rollbase Scalability – Part Three

 

 

 

4 thoughts on “Rollbase Scalability – Part One”

Leave a Reply

Your email address will not be published. Required fields are marked *