Server cluster: Difference between revisions
| Line 59: | Line 59: | ||
The difference from $CFG->cachedir is that the directory does not have to be shared by all cluster nodes, the file contents do not change. Use local fast filesystem on each cluster node. | The difference from $CFG->cachedir is that the directory does not have to be shared by all cluster nodes, the file contents do not change. Use local fast filesystem on each cluster node. | ||
==Performance | ==Performance recommendations== | ||
#Use on big central memcached server for all shared caches that support it. | #Use on big central memcached server for all shared caches that support it. | ||
Revision as of 11:54, 2 November 2013
This page is going to describe some basic information related to server clustering...
Cluster installation
Requirements
- database server - ACID compliant, for example PostgreSQL and MariaDB
- main server that is able to share dataroot - locking support recommended, for example NFS
- load balancer - for example Nginx
- cluster nodes - web servers
- Memcached server for shared caches
Note: this guide is not intended for Windows OS or any other Microsoft technologies.
Initial installation
- Perform standard CLI installation on the main server using shared database and dataroot directory.
- Setup web servers on cluster nodes - use local dirroot and shared database and dataroot.
- Configure load balancing.
Related config.php settings
$CFG->wwwroot
It must be the same on all nodes, it must be the public facing URL. It cannot be dynamic.
$CFG->sslproxy
Enable if you have https:// wwwroot but the SSL is doen by load-balancer instead of web server.
Enable Secure cookies only to make your site really secure, without it cookie stealing is still trivial.
$CFG->reverseproxy
Enable if your nodes are accessed via different URL. Please note that it is not compatible with $CFG->loginhttps.
$CFG->dirroot
It is strongly recommended that $CFG->dirroot (which is automatically set via realpath(config.php)) contains the same path on all nodes. It does not need to point to the same shared directory though. The reason is that some some low level code may use the dirroot value for cache invalidation.
The simplest solution is to have the same directory structure on each cluster node and synchronise these during each upgrade.
The dirroot should be always read only for apache process because otherwise built in add-on installation and plugin uninstallation would get the nodes out of sync.
$CFG->dataroot
This MUST be a shared directory where each cluster node is accessing the files directly. It must be very reliable, administrators cannot manipulate files directly there.
Locking support is not required, if any code tries to use file locks in dataroot outside of cachedir or muc directory it is a bug.
$CFG->tempdir
It is recommended to use separate ram disks on each node. Scripts may use this directory during one request only. The contents of this directory may be deleted if there is no pending HTTP request, otherwise delete only files with older timestamps.
Always purge this directory when starting cluster node, you may get some notices or temporary errors if you purge this directory while other requests are active.
$CFG->cachedir
This directory MUST be shared by all cluster nodes. Locking is required.
$CFG->localcachedir
The difference from $CFG->cachedir is that the directory does not have to be shared by all cluster nodes, the file contents do not change. Use local fast filesystem on each cluster node.
Performance recommendations
- Use on big central memcached server for all shared caches that support it.
- Use local memcached instances on cluster nodes for local caches that support it.
- Use memory only filesystems for local temp directories on cluster nodes.
- Use fast local directory for dirroot on each cluster node.
- Use memcached sessions.
Upgrade procedure
TODO
