Deployment options

The Tomcat packaging comes in two flavors:

• bare Tomcat packaging,
• JCA/JTA Tomcat packaging (default): it adds to Tomcat the required infrastructure to manage transaction and JCA polling.

In most of the case, the Nuxeo server is behind a reverse proxy that is used to provide:

• HTTPS/SSL encryption,
• HTTP caching,
• URL rewritting.

Cluster deployment

In order to manage scale out, Nuxeo EP provides a simple clustering solution.

When cluster mode is enabled, you can have several Nuxeo EP nodes connected to the same database server. VCS cluster mode manages the required cache invalidation between the nodes. There is no need to activate any application server level cluster mode: VCS cluster mode works even without application server.

Depending on the UI framework used for presentation layer, the network load balancing can be stateful (JSF webapp) or stateless (WebEngine).

Multi-VM deployment

Nuxeo components interact between each others via service interfaces. Since most services can be remotely called via RMI, you can split a Nuxeo distribution (like DM) in several parts on several JVM.

Of course, this kind of multi-VM deployment is more complex than simple mono-vm deployment:

• you need to configure service lookup layout (service groups),
• all additional custom plugins must be cleanly packaged.

Nevertheless, this kind of deployment can be interesting to solve specific requirement.

Service externalization

Depending on your use cases, some services may consume more resources than others. For example, if the application needs to do heavy conversion work or needs to resize a lot of pictures, it may be interesting to isolate theses services:

• to prevent batch processing from slowing down interactive processing,
• to spread services on more CPUs.

Isolating the web layer

An other use case is to separate Nuxeo bundles into two categories:

• bundles that manage persistent transactional data,
• bundles that don't.

By doing this split, we have:

• A "Stateless server" that runs:
  • all services without state,
  • the UI layer (framework and screens associated to features).
• A "Stateful server" that runs all persistent services including the Document repository.

This two parts packaging provides some advantages:

• it allows scaling out of the web layers,
• it provides full three layers decoupling (Nuxeo can be hosted in a 3 layers DMZs architecture).

These two packaging are somehow badly named since the Stateless server is not really stateless (JSF is stateful for example), but it does not manage any persistent state.

Sample deployments

HA deployment and DRP

If you want to provide a Disaster Recovery Plan, you will need to host two separated Nuxeo infrastructures and be sure you can switch from one to an another in case of problem.

The first step is to deploy two Nuxeo infrastructures on two hosting sites. These infrastructure can be mono-VM, cluster or multi-VM. The key point is to provide a way for each hosting site to have the same vision of the data:

• SQL data stored in the SQL database server,
• Filesystem data.

Because Nuxeo storage VCS+Filesystem is safe, you can use a replication system between the two sites. Basically, you can use the replication/standby solution provided by the Database server you choose. This replication tool just has to be transactional.

For the filesystem, any replication system like RSync can be used.

Because the blobs are referenced by their digest in the database, you don't have to care about synchronization between the DB and FS: in the worst case, you will have blobs that are not referenced by the DB on the replicated site.

This kind of DRP solution has been successfully tested in production environment using:

• PosgreSQL stand-by solution (WAL shipping),
• RSync for the file system.

Offline client

Multi-Instances

In some cases, you may want to have several separated instances:

• because you have several sub-applications,
• because you want to use different kinds of hardware depending on the sub-application,
• because you have constraints on hosting in separated DMZ.

A typical use case is when you have an internal application for contribution and viewing, but you also need to let external (internet) users access a small part of the content. Technically, you could have the same application serving the content depending on the user profile or several applications sharing the same repository. But in many cases, hosting and security constraints may lead to have two separated hosting platforms: one for internal and one for external.

In order to achieve that you can leverage the built-in feature for remote publishing between two Nuxeo instances.

See Remote Plublisher for more details).