Any User. Any Data. Any Deployment.
Clustering in Actuate 9
High Availability and Scalability
High availability is a requirement for business web sites that cannot afford down
time. At the same time, the ability to scale up an initial deployment to handle
ten times or more users is frequently desired. As a result, web sites are now
commonly designed using multiple tiers of systems that feature clusters of
computers.
This paper describes features of Actuate 9 that support this model of
computing.
Technical
White Paper
Technical White Paper: Clustering in Actuate 9
Notice
The information in this white paper is proprietary to
Actuate Corporation (“Actuate”) and may not be used
in any form without the prior consent of Actuate.
© 2002-2007 by Actuate Corporation. All rights
reserved.
Actuate Corporation trademarks and registered
trademarks:
Actuate, e.Analysis, e.Report, e.Reporting,
e.Spreadsheet, Formula One, Internet Spreadsheet,
Live Report Extension, ReportCast, Report
Encyclopedia, SmartReports, Spreadsheets
Everywhere, Tidestone, and XML reports.
All other trademarks are property of their respective
owners.
Version 1.7 – July 5, 2007 © Actuate Corporation
2
Technical White Paper: Clustering in Actuate 9
Contents
Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Highly Available Scalable Web Site Principles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Actuate iServer Architecture Goals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Scalability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
High Availability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Manageability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Scalability and High Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Architecture Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Encyclopedia Storage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Multi-Volume Encyclopedia. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Manageability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Browser-Based Administration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
System Management and Monitoring. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Application Scenario — MyInsurance.com. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Initial Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Expanded Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3
Technical White Paper: Clustering in Actuate 9
Introduction
More than ever, companies rely on getting the right
information at the right time to their employees,
customers, suppliers, and partners. To meet these
every-increasing needs, many Global 9000 companies
are developing mission-critical Enterprise Reporting
Applications, such as Business Process Management
(BPM) dashboards, information portals, business
analytic applications, and interactive reporting
applications. The Actuate iServer makes it easy for
companies to cost-effectively build and centrally
manage web-based Enterprise Reporting Applications
that serve the needs of 100% of the users.
High availability is a requirement for Enterprise
Reporting Applications that cannot afford down
time. At the same time, the ability to scale up an
initial deployment to handle ten times or more
users is frequently desired. Deploying an Enterprise
Reporting Application in a cluster configuration
allows a business to achieve high availability with the
ability to grow its capacity by incrementally adding
servers.
This paper describes features of Actuate 9 that
support this model of computing. The first section
outlines the general environment such a solution
must fit into, while the following sections present the
architectural goals and the Actuate solution.
Highly Available Scalable Web Site Principles
The technical details of a highly-available, scalable
web-based Enterprise Reporting Application can be
quite complex, but it is useful to review the basic
principles. A simplified logical diagram of such an
application is presented in Figure 1.
Multiple Internet Service Providers (ISPs) provide
independent access points from the Internet into the
web site. If one of the ISPs goes down, the others will
continue to make the site available.
User requests are presented to the first security
and load-balancing layer. This layer is typically
implemented as a combination of specialized
hardware and general-purpose systems, but there
must be at least two of each kind of system to avoid
having a single point of failure.
…
ISP 1
ISP N
Security / Load Balancing
Firewall
Web /
Application
Server Tier
Security / Load Balancing
Firewall
Data
Resource Tier
SAP
Oracle
Actuate
LDAP
Storage
RAID Subsystems
Figure 1. Highly available, scalable, web-based information application
The first load-balancing layer is usually stateless,
routing requests to the least busy web or application
server. Stateless load balancing is made possible by
not storing persistent long-term application data on
any of the systems in this tier. This has the advantage
of scaling easily by adding additional identical
systems (“clones”), as well as enhancing security by
locating sensitive data behind a second firewall on a
secure network.
The second load balancing / security layer is located
in front of the data resource tier, where persistent
data is managed. This load-balancing layer may
contain application logic that routes requests to the
server in the data resource tier which is capable of
processing the request. Usually this logic is executed
in the application server.
The data resource tier in Figure 1 shows a number
of specialized servers responsible for managing
different parts of a company’s business operations:
SAP for manufacturing, Oracle for general database
services, Actuate for information delivery, and an
4
Technical White Paper: Clustering in Actuate 9
LDAP system for providing consistent security across
all applications. These servers must all be clustered
to provide scalability and high availability. Clustering
of data resource servers is more challenging than
clustering front-end servers because of the persistent
data (state) they maintain.
The data resource servers access information stored
on redundant disks in the storage tier, either directly
connected to the servers or indirectly over a network.
Each disk subsystem must be a RAID device, which
provides high availability for the persistent data.
While there are at least three possible technologies
for the storage tier—storage area network (SAN),
network attached storage (NAS), or system attached
storage—RAID is required in all of them so there is no
single point of failure in the storage system.
Actuate iServer
Architecture Goals
The goals for Actuate iServer include major
improvements in four key areas: scalability,
availability, security, and manageability.
Scalability
Scalability is the property that allows a system
to grow incrementally by adding resources to
meet increasing business demands. There are
two aspects to scalability: processing scalability
and storage scalability. Processing scalability is
the ability to handle increasing user requests for
content generation and viewing while maintaining
acceptable response time. Effective load balancing
and partitioning techniques are required to achieve
scalability in a clustered environment. The Actuate
iServer provides these capabilities automatically.
Storage scalability is the ability to handle increasing
numbers of persistent documents and associated
objects as the number of users increases. The Actuate
Encyclopedia can be expanded practically indefinitely
by adding logical volumes and physical disk partitions
for additional storage capacity.
High Availability
Highly available systems remain on-line continuously,
using redundant components to continue processing
in the event of a single component failure. The most
fundamental principle of highly available systems is
no single point of failure. Every part of the system
needs a backup that can either continuously share or
quickly take over processing in the event of a failure.
In addition, it must be possible to change and
expand the configuration of the system without
taking it offline. Thus the goals of scalability and high
availability must be achieved at the same time.
The Actuate iServer can be configured on a single
machine, or in a cluster with no single point of failure.
Every machine in the cluster is working all the time
(no passive nodes), with automatic fail-over when
needed.
Security
The security system must protect sensitive data
from unauthorized access. To start, firewalls block
certain kinds of requests from getting through,
such as requests from unknown sources, requests
from sources known to be malicious, or requests
for operations that have been disallowed. Thus
information delivery servers must work smoothly with
firewalls.
Once past the firewall, requests must be
authenticated to ensure that a valid user is making
the request, and authorized to see that the user is
allowed to perform the requested operation. All
applications need to perform authentication and
authorization. Ideally there would be a single place to
store user information so the security policy would be
consistent across applications. Achieving this requires
applications that integrate with a global security
manager, such as an LDAP server, to perform these
functions.
Actuate can be configured easily to work in multiple
firewall environments. Millions of users can be
managed internally with good performance, or an
external security service such as an LDAP server may
be used, depending on customer preference.
Manageability
Management refers to the activities needed
to monitor and maintain the availability and
performance of a system. Managing a cluster
efficiently requires a single console where an
administrator can initiate, monitor, and terminate
5
Technical White Paper: Clustering in Actuate 9
system functions. Often it is desirable to perform
these functions remotely (i.e. over the Internet)
because the cluster under management is in another
location.
The Actuate iServer includes the Management
Console, a browser-based administration console
for managing clusters and individual machines. The
Management Console can handle millions of users
and objects without overloading the network or
exceeding browser display limits. In addition, there
are APIs for integrating with 3rd party management
and monitoring tools.
Internet
Firewall
Web / App Server
+ ReportCast
iPortal
6
Firewall
Data Resource
Tier
Scalability
and High Availability
Actuate achieves scalability and high availability using
an iServer cluster, a group of multiple active machines
with a single virtual IP address. Requests arrive at
the cluster and are routed to the most appropriate
machine based on the available services and load on
each machine. Machines may be added and services
reconfigured to provide processing scalability while
the cluster remains on-line.
To provide storage scalability, Actuate offers a
multi-volume Encyclopedia. Each volume is an
independent unit which may be added, dropped,
backed up, and restored while the rest of the system
remains on-line. In addition, disk partitions can be
dynamically added and dropped for each volume.
Fault tolerance for high availability is provided by
two mechanisms: “cloning” of Message Distribution,
Factory, and Viewing services (which are stateless)
and partitioning of Encyclopedia services (which
are stateful) with automatic recovery and fail over.
These mechanisms are described in more detail in the
following sections.
Architecture Overview
The architecture diagram in Figure 2 shows a highly
available Actuate iServer cluster with six nodes. For
simplicity, the redundant ISPs are assumed to be
inside the cloud, though of course they are required
for high availability. For storage, this example shows
network attached storage (NAS) with RAID assumed.
VIP
VIP
e.Reporting
Server cluster
F V EE
M G
R
R F
M
G V
V E
E
F V
V E
R G
M
e.Reporting
Server nodes
F V E3
R G
M
LAN
E1
G V E1
R F
M
Storage Tier
F V
V E2
E2
R G
M
S1
F1
S2
F2
S3
F3
M = Message Distribution
R = Request
service
serviceF =
G Factory
= Generation/print
service V service
= ViewingVservice
= Viewingservice
E = Encyclopedia
E =service
Encyclopedia
S = Encyclopedia
service F =volume
Encyclopedia
on file/storage
volume server
on file/stora
ge server
Figure 2. Actuate iServer architecture
Internet requests passed by the front firewall are
sent to the virtual IP address of the front-end web/
application server cluster. Stateless load balancing
techniques such as Windows Load Balancing Service
(WLBS), Cisco Local Director, and so on are used to
route the request to the least busy machine in the
cluster. Some requests, such as for a static web page,
may be handled entirely by a front-end server. For
other requests, application logic decides whether
to route a request to Actuate or some other backend service such as Siebel or SAP (not shown in this
diagram).
Applications communicate with the iServer cluster
by sending URLs to iPortal, which is an application
running in the web/application server that provides
access to reporting content to end users. iPortal then
makes the appropriate calls to the iServer. iPortal
maintains a list of iServer nodes and therefore can
perform the load balancing of requests among the
6
Technical White Paper: Clustering in Actuate 9
iServer nodes running the Message Distribution
Service. Alternatively, the customer can use a virtual
IP (VIP) with stateless load balancing (such as such as
Windows Load Balancing Service, Cisco LocalDirector,
and Resonate Central Dispatch) as the entry point to
the Actuate cluster. Clusters can be heterogeneous if
desired—some nodes can run Windows, while others
run Unix. Each node of the cluster runs one or more
iServer services:
• Message Distribution services accept messages
from applications and load balance them across the
other Actuate services in the cluster. Load balancing
is based on machine state, availability of the service,
availability of the data, and machine load. Message
Distribution can services run on machines configured
to be part of the VIP layer. If desired, every machine
in the cluster can be configured to run the Message
Distribution Service (for example, two node clusters
are always configured like this). Message Distribution
services are stateless and can be handled by any
machine.
Message Distribution services are also responsible
for monitoring the health of the cluster, periodically
checking the heartbeat of all services. If a service
does not respond, it is removed from the cluster
configuration and receives no further requests. If
the failed service was responsible for managing a
Encyclopedia volume, Message Distribution services
reassign another node to that volume.
to a node that has already cached the document—as
long as the machine is not saturated. The Message
Distribution service’s load balancing algorithm takes
these factors into account.
• Factory services generate new content from data
sources and, if the content is persistent, request it to be
stored in the Encyclopedia. Server-side printing is also
handled by this service. Generation is the most CPUintensive activity of the iServer cluster.
Report generation requests are either synchronous
(interactive) or asynchronous (scheduled). If a
synchronous request fails for any reason, the
application will receive an error code and must
resubmit the request. Asynchronous requests that
fail are automatically rescheduled. Either kind of
resubmitted request can run on any Factory service
available at that time.
• Encyclopedia services manage Encyclopedia
volumes, adding, deleting, updating, and listing
various kinds of objects (users, privileges, folders,
content, disk partitions, etc.). Each Encyclopedia
service manages one or more volumes; and each
volume is managed by one Encyclopedia service.
If an Encyclopedia service fails, another node in the
cluster must recover the volume and take over volume
management. Message Distribution services are
responsible for detecting this condition and assigning
a new owner for the volume.
Note that while the Message Distribution Service
(MDS) performs load balancing and failure detection
within the Actuate cluster, a highly available
configuration requires that more than one cluster
node run the MDS, and therefore requests must also
be load balanced among multiple MDS instances.
iPortal can be configured to perform MDS load
balancing and failure detection.
To provide high availability, at least two instances
of each service must be running, each on a separate
machine. If one of the machines fails, the other one(s)
will continue running the service. In the case of
Message Distribution, Factory, and Viewing services,
requests are stateless so no recovery is needed. The
user or application merely resubmits the request (for
example by clicking the reload button in the browser).
• Viewing services render content in various formats
(DHTML, PDF, XML, XLS, CSV) for use in browsers and
other applications; handle requests to search content;
enforce page security; and demand page large
documents for high performance. Viewing is a very
CPU-intensive activity.
Encyclopedia services maintain persistent state in
Encyclopedia volumes. If an Encyclopedia service
fails, a new one must be assigned to recover
the volume and take over processing. Message
Distribution services are responsible for detecting the
failure, removing the failed service from the cluster
configuration, and reassigning a new Encyclopedia
service to the volume.
Viewing requests are stateless, though performance
may be better if viewing requests for a document go
7
Technical White Paper: Clustering in Actuate 9
Every node in the cluster has the same software
installed. As a result, the administrator can configure
services as required on any node. In Figure 2,
Message Distribution services are shown running
on the top two nodes. Factory services run on all
four remaining nodes, while Viewing services run on
three nodes. Encyclopedia volumes S1, S2, and S3
are managed by Encyclopedia services E1, E2, and E3
respectively.
http://maui:8080/iportal/getfolderitems.do?volume=DATE&folder=/sales/west
Folder path name
Volume name
iPortal action
iPortal application root
Cluster DNS name
Figure 3. Volume and folder naming
Encyclopedia Storage
In a highly available Actuate cluster, the Encyclopedia
can be deployed on a variety of storage devices and
accessed by a variety of file sharing methods. The
choice of storage solution is largely transparent to
Actuate, so customers can chose the solution that fits
in best with their existing infrastructure.
To deploy Actuate in a highly available cluster, the
only requirements of the storage are:
1.Every iServer cluster node that runs any of the Factory,
Viewing, or Encyclopedia Services must be able to read
and write to the encyclopedia directly. This means
that every cluster node must be able to access the
storage devices that store the encyclopedia.
2.Both the storage and the file system must be deployed
in a highly available fashion, with either failover
capabilities or built-in redundancy.
A highly-available NAS (Network Attached Storage)
is specifically designed to share storage resources
among several computers, and is ideally suited to the
requirements of an Actuate cluster.
Storage Area Networks provide excellent availability
and important administration benefits; however the
storage is typically only visible to a single machine.
Thus, in order to provide encyclopedia storage
for an Actuate cluster, the SAN must be specially
configured to allow all the cluster nodes access to the
encyclopedia. This can be accomplished via a SAN
with a “NAS-head” or by using SAN sharing software,
such as Veritas Storage Foundation or Tivoli SANergy.
Multi-Volume Encyclopedia
An Actuate iServer cluster is able to manage multiple
volumes, which can each store content for different
applications. As a result, multiple applications can
cost-effectively share a common server infrastructure
yet be separately controlled and administered. A
volume can be added, dropped, backed up, and
restored while other volumes remain on line and
accessible. Within a volume, new disk partitions can
be added while the system remains on line. The result
is that the Encyclopedia can grow unconstrained by
the limits of a single physical disk system.
To support large Encyclopedias, performance has
been improved dramatically when there are large
numbers of objects. All object types benefit from
the performance gains: users, folders, roles, groups,
notifications, privileges, dependencies, files, and so
on.
Continuing the theme of support for large objects,
limitations on document size has been increased to 8
gigabytes. In addition, the Encyclopedia format has
been made portable so complete Encyclopedias or
volumes may be moved between machines with no
conversion.
To support failover, recovery of the Encyclopedia after
a crash must be fast and predictable. Actuate always
completes recovery in under 5 minutes, no matter the
size of the Encyclopedia or the transaction rate. This
ensures a minimum of down-time when fail over is
needed.
Finally, in support of the high availability goal, there
is no need to perform periodic maintenance such as
defragmentation on an Encyclopedia volume. The
Encyclopedia automatically manages, recovers and
optimizes deleted space. This removes the need to
take the Encyclopedia off line on a regular basis for
routine maintenance and hence increases availability.
8
Technical White Paper: Clustering in Actuate 9
Security
For integration with security perimeters, the iServer
cluster works transparently with firewalls and SSL.
Only a single port must be opened, and the port itself
is configurable. SSL can be used to encrypt all iServer
message traffic if desired.
The Actuate internal security model handles clusters
and the multi-volume Encyclopedia. There are two
kinds of administrators: cluster administrators and
volume administrators. Cluster administrators start
and stop the cluster and nodes within the cluster; add
and drop nodes; add and drop Encyclopedia volumes
and disk partitions; and configure services to run on
each node.
Volume administrators work within a single
Encyclopedia volume, maintaining users, roles,
groups, and privileges; and initiating backup and
recovery operations for the volume. By default, each
volume has its own independent user list. Thus users
log into a specific volume. This model supports
independent applications within a single cluster
environment.
If it is desired to support a single application and
single user list across the cluster, or if it is desired
to integrate with an external security service for
consistent security across multiple applications, use
Open Security.
Several integration points are provided for flexibility.
The iPortal Security Extension can be used to
implement single sign-on, while the Report Server
Security Extension (RSSE) implements various
levels of user, privilege, and property integration.
At the highest level of integration, all user names,
passwords, privileges, and properties can be retrieved
from an external store. A reference implementation is
provided for the Sun Java System Directory Server (an
LDAP server), but the interface is extensible so other
servers can be supported as well.
Manageability
Browser-Based Administration
Actuate includes Management Console, a scalable,
high performance browser-based administration tool
Figure 4. User Administration page
for managing clusters and Encyclopedia volumes.
The tool is written using standard web technologies,
so administration can be performed remotely with
no software installation required. Both cluster
management and volume management can be
performed using only a browser, even over slow
networks with large Encyclopedias. Figure 4 shows
the user administration page that illustrates key
concepts that apply in many administration scenarios.
A large Encyclopedia may contain millions of
registered users. Listing them all on a single browser
page is impractical for at least three reasons: a slow
network would take too long to send the data; the
browser would exceed available client memory to
display them; and users find scrolling extremely long
lists tedious.
To solve these problems, the administration tools
provide three strategies for list management—
paging, filtering, and searching. Long lists are broken
up into moderate sized “page X of Y” segments, with
buttons for navigating the pages. This mechanism
is familiar to web users, is capable of handling
9
Technical White Paper: Clustering in Actuate 9
any size list with good performance, and will not
overload the browser. But such lists may be too long
for convenient use. To reduce list size, filtering and
searching are provided.
Filters are simple search criteria, such as all users or
files whose names begin with “A”, that are applied
during folder navigation. This can reduce the number
of items displayed to a manageable number. The UI
for specifying filter criteria appears directly on iPortal
and Management Console pages.
Searches are specified outside folder navigation
on specialized search pages, so the UI can provide
much more expressive power. Also, the result set
for searches can be sorted in different ways. Normal
update operations such as moving or deleting the
files in a search result set can be done as well.
Internet
Firewall
VIP
Web / App Servers
+ ReportCast
iPortal
6
VIP
Firewall
Data Resource
Tier
V E
E
R GF V
M
V E
R GF V
M
System Management and Monitoring
Actuate is usually installed as one part of a highly
diverse system within an organization. As more and
more systems become a part of such an architecture,
customers begin to require a single management
console for all applications.
In support of this objective, Actuate includes APIs so
3rd party system management products based on
standards like SNMP can perform basic management
functions on the iServer cluster. These functions
include the ability to start and stop servers, get and
set configuration parameters, and monitor the current
state of the iServer cluster.
Example statistics include the total number of reports
executed in the last 24 hours; the total amount of
memory used by any iServer node; available disk
space; number of requests currently being executed;
number of requests in the queue etc. This type of
information can be presented with system monitoring
tools such as the Microsoft Windows Performance
Monitor.
Application Scenario—
MyInsurance.com †
To illustrate some of the concepts discussed in the
preceding sections, two sample configurations are
presented in the context of an application.
e.Reporting
iServer cluster
Server
cluster
Report
Encyclopedia
on shared device
Storage
Figure 5. Two-node iServer cluster
MyInsurance.com, the e-commerce division of
an established insurance company, plans to sell
insurance over the Internet. Marketing estimates
there could be 5,000 customers fairly quickly. If the
business is successful, the user population could grow
to half a million customers within 24 months.
The cluster must be highly available from the
start, and be able to scale to handle the increasing
workload while remaining on-line. Interactive quotes,
quarterly and annual customer statements, and
monthly commission reports for agents are some
of the information delivery requirements for the
application.
Initial Configuration
For the starting configuration, a two-node iServer
cluster can be constructed fairly easily using a
packaged Windows solution such as the Compaq®
ProLiant DL cluster or a Dell® PowerEdge cluster.
These systems provide redundant power supplies, a
10
† MyInsurance.com is not a real company
Technical White Paper: Clustering in Actuate 9
single virtual IP address, two dual processor nodes,
and a shared RAID disk subsystem all in a single box.
While simple to install initially, the tradeoff for this
kind of system is that expansion into a larger cluster
can be more difficult later.
Dual ISPs must be connected to the front end to
provide a highly available Internet connection.
Similarly, dual web application servers are also
required. Two firewalls with a DMZ in between
protect the secure back end network from direct
access over the Internet. Because there is a firewall
between the iPortal and the iServer, iPortal does not
perform load balancing among the iServer nodes; a
Virtual IP is used instead.
The iServer cluster configures Message Distribution,
Factory, and Viewing services on both nodes, with the
Encyclopedia service running on node 2. Node 1 is
configured as the fail-over node for the Encyclopedia
service.
As the system needs to support more users, additional
Windows machines can be added to the iServer
cluster without stopping the system.
Expanded Configuration
The expanded configuration presented in Figure 7 for
supporting 500,000 registered users takes advantage
of the ability to have different kinds of machines in a
cluster. The front-end setup is similar to the smaller
system, but with more hardware. Instead of dual ISPs,
three or four may be desired. Similarly, the number
of nodes in the web application server cluster is
increased.
In the iServer cluster, there are four nodes dedicated
to Message Distribution services. These are
represented as Microsoft Windows machines, which
together present a single virtual IP address to the
front-end applications. The general purpose loadbalancing layer in front of these nodes is not aware
of all the factors that load an iServer node, so it is
best in larger clusters like this one to run Message
Distribution services only on a few smaller machines
and place the harder-to-balance services on other
nodes. The more sophisticated Message Distribution
services load balancing algorithms can better direct
requests to these other nodes.
Internet
Firewall
VIP
Web / App Servers
+ ReportCast
iPortal
6
Firewall
VIP
R GF V
M
VE
E
R GF V
M
VE
E
R GF V
M
VE
E
R GF V
M
VE
E
V E
R GF V
M
iServer
e.Reporting
cluster
Server cluster
R G V E3
LAN
Data Resource
Tier
F VV E
R G
M
R G V E
M
E1
F VV E1
R G
M
Storage Tier
E2
F VV E2
R G
M
S1
F1
S2
F2
S3
F3
Figure 6. Ten-node iServer cluster
The larger nodes in the cluster can be more robust
multi-processing systems. Factory and Viewing
services are configured to run on each of these nodes.
Encyclopedia services are configured as well, one
for each volume. These nodes can all act as failover
nodes to take over volume management in case one
of the services goes down. All services scale well as
more CPUs are added to a node.
The Encyclopedia is shown as being located on
network attached storage (NAS) devices. These
are machines connected to the same LAN as the
cluster nodes. Network attached storage is much
more flexible than system attached storage, and
less expensive than a storage area network. Other
strategies for accessing large pools of storage can be
used as well.
11
Technical White Paper: Clustering in Actuate 9
The configuration shown here is but one approach to
supporting large user populations. It is equally valid
to use a larger number of smaller machines to achieve
the same overall capacity and reliability.
Actuate iServer’s flexible cluster configuration options
allow any combination of scalability strategies to be
applied. For example, many small-scale systems with
1 to 8 CPUs, or fewer large-scale UNIX systems with 32
or more CPUs per machine.
Summary
Actuate achieves its design goals of high availability,
scalability, security, and manageability with a flexible,
clustered architecture. Two or more machines may
be combined into a single virtual resource with
no single point of failure, allowing processing to
continue with very high uptime percentages. Clusters
may be expanded to handle millions of users and
tens of millions of objects while delivering excellent
performance. To keep response time consistent,
sophisticated load balancing algorithms route
requests to the most appropriate node.
The security model for the Encyclopedia allows
for either separate volumes each supporting an
independent application, or a single integrated
resource for one large application. Security
information can be managed internally in the
Encyclopedia or externally in a customer-specified
security service.
A browser-based management console and utilities
allow system and volume management from
anywhere there is Internet access, significantly
improving administrators’ ability to manage and
maintain the system. Common system operations
including adding, dropping and configuring nodes,
maintaining Encyclopedia volumes, and backup and
recovery can all be done while the cluster remains
on-line. APIs to integrate with 3rd party management
tools provide further flexibility.
These capabilities define the next generation in
Enterprise Reporting Application Platforms, available
only from Actuate Corporation.
Actuate Corporation
2207 Bridgepointe Parkway
Suite 500
San Mateo, CA 94404
Tel: (888) 422-8828
Web: http://www.actuate.com
12