Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Note
titleThis is Work In Progress

This document is still being worked upon. Contributions: Welcome!


There are many ways to run a tiered application such that is is scalable (where "scalable" means that it can be set up to run more parallel sessions for users, digest more service calls

...

etc...).

...

 Scalability in tiered applications means,

...

e.g.

...

  • a

...

  • single

...

  • web

...

  • server

...

  • directing

...

  • traffic

...

  • to

...

  • multiple

...

  • application

...

  • servers

...

  • many

...

  • servers

...

  • talking

...

  • to

...

  • a

...

  • single

...

  • database

...

  • servers

...

  • talking

...

  • to

...

  • many

...

  • databases

...

  • etc.

...

 
The need for scalability is not only driven by sheer capacity demand (mostly going along with requests to use low cost hardware to run services). It is very much linked to other non-functional requirements such as (high-) availability and maintainability.

This is the reason why understanding the various architecture patterns which are supported by a given application stack is crucial to deliver the right solution for a given business demand aka. requirement. This HOWTO guide talks about various options to "lay out" the physical server landscape in order to achieve certain non-functional requirements.

Most of the examples are taken from various threads on the community mailing list and replicated here in an abstract way.

Single instance of OFBiz running with public IP

Wiki Markup
\[standard case, describe pros cons here\]

...

Apache

...

"in

...

front

...

of"

...

OFBiz

...

single

...

instance

...

(no

...

load

...

balancing)

...

Setup

Wiki Markup
\[describe pros and cons\]

...

Using

...

Apache

...

to

...

load

...

balance

...

across

...

multiple

...

instances

...

of

...

OFBiz

...

The

...

below

...

is

...

taken

...

from

...

mails

...

by

...

Brett

...

Palmer

...

on

...

user@ofbiz.apache.org

...

 ===

...

mail

...

1

...

===

...

Here

...

is

...

a

...

configuration

...

we

...

use

...

to

...

do

...

load

...

balancing

...

in

...

ofbiz.

...

 Others may do
something else.

1. One machine is running an Apache Web server with mod_jk setup to
communicate with different instances of ofbiz.  The mod_jk is setup to load
balance between the different ofbiz instances.  Here is a document that
helps you get setup:

http://tomcat.apache.org/connectors-doc/generic_howto/loadbalancers.html

...

2.

...

Then

...

we

...

start

...

multiple

...

boxes

...

running

...

ofbiz

...

server

...

-

...

all

...

pointing

...

to

...

the

...


same

...

database.

...

 The servers are setup to communicate using mod_jk's

...

AJP

...


protocol.

...

  You

...

need

...

to

...

set

...

the

...

"jvm-route"

...

in

...

the

...


framework/base/config/ofbiz-containers.xml

...

file

...

to

...

insure

...

the

...

load

...

balancer

...


maintains

...

sessions

...

between

...

requests.

...

 Here is a snippet of that
configuration file.

<container name="catalina-container"

...


class="org.ofbiz.catalina.container.CatalinaContainer">

...


<

...

!-

...

-

...

static

...

configuration

...

for

...

tomcat

...

-->

...


<property

...

name="delegator-name"

...

value="default"/>

...


<property

...

name="use-naming"

...

value="false"/>

...


<property

...

name="debug"

...

value="0"/>

...


<property

...

name="catalina-runtime-home"

...

value="runtime/catalina"/>

...


<property

...

name="apps-context-reloadable"

...

value="false"/>

...


<property

...

name="apps-cross-context"

...

value="false"/>

...


<property

...

name="apps-distributable"

...

value="false"/>

...


<

...

!-

...

-

...

one

...

or

...

more

...

tomcat

...

engines

...

(servers);

...

map

...

to

...

this

...

+

...

host

...

-->

...


<property

...

name="default-server"

...

value="engine">

...


<property

...

name="default-host"

...

value="0.0.0.0"/>

...


*<property

...

name="jvm-route"

...

value="jvm1"/>

...

*

...


<property

...

name="access-log-pattern">

...


.....

...


===

...

/mail

...

1

...

===

...

 ===

...

mail

...

2

...

===

...

1.

...

 We run one instance of ofbiz on a separate server but this is because we
are running a single application and want to scale by adding more machines.

2.  It is easier to use the embedded ofbiz version rather than a standalone
tomcat with ofbiz placed as a standard WAR file.  From the Apache Web server
perspective there isn't any difference.  It is talking AJP protocol and
can't tell if it is an embedded version of tomcat or standalone.

3.  I'm not sure the reason some are running several version of ofbiz on the
same machine.  My guess is they have different customers or application and
don't need the extra hardware to service these applications.  We multiple
instances of ofbiz on the same machine but this is so we can have a dev,
testing, and production version running on the same machine.

For maximum scalability you would put 1 instance of ofbiz on a single
machine and load balance between these machines.  We are using Amazon's EC2
servers so it is easy for us to shutdown to a single server at night and
then start up several server during the days when the application is busy.

=== /mail2 ===

 Multiple OFBiz instances talking to the same database



Clustering several OFBiz  instances

Clustering is a feature since Tomcat 5.5 and since OFBiz uses even Tomcat 6.0, the on board clustering with catalina has improved even more.

 The configuration for clustering is comprised (and by default commented out) with
OFBIZ_HOME/framework/base/config/ofbiz-containers.xml

...

 Multiple OFBiz instances on the same physical machine

The port configuration of each OFBiz instance is controlled in

OFBIZ_HOME/framework/base/config/ofbiz-containers.xml

...