Clustering

=20

Introduction

Clustering in eZ Platform refers to setting up your install with several= web servers for handling more load and/or for failover.

Server setup overview

This diagram illustrates how clustering of eZ Platform is typically set = up, the parts illustrate the different roles needed for a successful cluste= r setup. The number of web servers, Memcached servers, Solr servers, Varnis= h servers, Database servers, NFS servers, as well as whether some servers p= lay several of these roles (typically running Memcached across the web = server) is up to you and your performance needs.

The minimal requirements are the following (with what is currently s= upported in italics):

Shared HTTP cache (using Varnish)
Shared Persistence cache and Sessions (using Memcached, or experime= ntally also Redis)
Shared Database (using MySQL/MariaDB)
Shared Filesystem (using NFS, or experimentally also S3)

For further details on requirements, see Requirements page.

While this is not a complete list, further recommendations include:

Using Solr for better se= arch and better search performance
Using a CDN for improved performance and faster ping time worldwide
Using Active/Passive Database for failover
In general: Make sure to use later versions of PHP and MySQL/MariaDB wi= thin what is supported for your eZ Platform version to get more performance out o= f each server.

Binary files clustering

eZ Platform supports multi-server by means of custom IO handlers. They w= ill make sure that files are correctly synchronized among the multiple clie= nts that might use the data.

Configuration

DFS IO Handler

What it is meant for

The DFS IO handler (legacy_dfs_cluster) can be us= ed to store binary files on an NFS server. It will use a database to m= anipulate metadata, making up for the potential inconsistency of network ba= sed filesystems.

Configuration

You need to configure both metadata and binarydata handlers.

As the binarydata handler, create a new Flysystem local adapter configur= ed to read/write to the NFS mount point on each local server. As metadata h= andler handler, create a dfs one, configured with a doctrine connection.&nb= sp;

V1.8.0

Note: the default database install will now include the dfs table in= the same database

For production, we strongly recommend creating the DFS table in its own = database, using the vendor/ezsystems/ezpublish-kernel/data/mysql/dfs_= schema.sql file.
In our example, we will use one named dfs.

=20

# new doctrine connection for the dfs legacy_dfs_cluster metadata h=
andler.
doctrine:
    dbal:
        connections:
            dfs:
                driver: pdo_mysql
                host: 127.0.0.1
                port: 3306
                dbname: ezdfs
                user: root
                password: "rootpassword"
                charset: UTF8

# define the flysystem handler
oneup_flysystem:
    adapters:
        nfs_adapter:
            local:
                directory: "/<path to nfs>/$var_dir$/$storage_dir$"

# define the ez handlers
ez_io:
    binarydata_handlers:
        nfs:
            flysystem:
                adapter: nfs_adapter
    metadata_handlers:
        dfs:
            legacy_dfs_cluster:
                connection: doctrine.dbal.dfs_connection

# set the application handlers
ezpublish:
    system:
        default:
            io:
                metadata_handler: dfs
                binarydata_handler: nfs

=20

Customizing the storag= e directory

eZ Publish 5.x required the NFS adapter directory to be set to $va= r_dir$/$storage_dir$ part for the NFS path. This is no longer requir= ed with eZ Platform, but the default prefix used to serve binary files will= still match this expectation.

If you decide to change this setting, make sure you also set io.ur= l_prefix to a matching value. If you set the NFS adapter's directory= to "/path/to/nfs/storage", use this configuration so that the files can be= served by Symfony:

=20

ezpublish:
=09system:
=09=09default:
=09=09=09io:
=09=09=09=09url_prefix: "storage"

=20

As an alternative, you may serve images from NFS using a dedicated we= b server. If in the example above, this server listens on =20 http://static.example.com=20 and uses =20 /path/to/nfs/storage=20 as the document root, configure =20 io.url_prefix=20 as follows:

=20

ezpublish:
=09system:
=09=09default:
=09=09=09io:
=09=09=09=09url_prefix: "http://static.example.com/"

=20

You can read more about that on Binary files = URL handling.

Web server rewrite rules

The default eZ Platform rewrite rules will let image requests be served = directly from disk. With native support, files matching ^/var/([^/]+/= )?storage/images(-versioned)?/.* have to be passed through /we= b/app.php.

In any case, this specific rewrite rule must be placed without the ones = that "ignore" image files and just let the web server serve the files.

A= pache

=20

RewriteRule ^/var/([^/]+/)?storage/images(-versioned)?/.* /app.php =
[L]

=20

ngin= x

=20

rewrite "^/var/([^/]+/)?storage/images(-versioned)?/(.*)" "/app.php=
" break;

=20

In this topic:

=20

Introduction=20
- Server setup overview=20
- Binary files clustering

=20

Configuration=20
- DFS IO Handler=20
  - What it is meant for
  - Configuration
  - Web server rewrite rules<= /a>

=20

Overview of step= s to set up Cluster:

=20

Clustering

Introduction

Server setup overview

Binary files clustering

Configuration

DFS IO Handler

What it is meant for

Configuration

Customizing the storag= e directory

Web server rewrite rules

A= pache

ngin= x

In this topic:

Related: