Installing and running Shopware on a single server LAMP stack is easy to accomplish and a common solution for small and mid-size customers. When it comes to high performance and high reliability, however, having a clustered, redundant setup is inevitable.
The following document will describe ways to cluster Shopware as well as considerations related to running Shopware in a clustered setup.
Generally speaking, clustering is a way to link multiple computers for a certain purpose. Usually this purpose is to increase availability and / or performance of the setup and has several benefits:
The following schema shows a simplified cluster setup. The components will be discussed in detail below.
The load balancer is the foremost instance in every cluster setup. It will handle all customer requests and dispatch them to one of the varnish cache instances.
Responsibility: * SSL offloading * equal distribution of the traffic across all caches / app servers
Software to run: * Nginx (TLS offloading as well as load balancing)
Scaling: * second load balancer as fail-over * possibly floating IP and health checks for automated fail-over
If standalone caches are required, Shopware recommends Varnish, as there is a varnish configuration available.
Responsibility: * caching - reduce load on database and appserver
Software to run: * Varnish 4
Scaling: * scales horizontally (numerous cache server possible)
An appserver runs the actual Shopware application and handles all requests which could not be handled by the cache before:
Responsibility: * handle user requests * the shop itself
Software to run:
See: system requirements * Apache * PHP * latest version of Shopware (synced from the admin server)
Scaling: * scales horizontally (numerous appserver possible)
The admin server is an appserver dedicated to the Shopware back office. It is also the leading appserver - all code changes (e.g. deployment) happen on the admin server and are synced to the app servers. Furthermore, all periodic tasks should be run here.
Responsibility: * serving of /backend (the back office) * Cronjobs * Jumphost * Deployment
Software to run:
See: system requirements * Apache * PHP * latest version of Shopware
The database is the central persistent storage of all shop related data.
Responsibility: * Holds all persistent data, e.g. articles, orders, customers
Software to run: * MariaDB >= 10 (MySQL compatible database engine)
Scaling: * replication master/slave * cluster like percona / galera
For high performance setups, we recommend to store the sessions in memcache instead of the database (which is Shopware's default behaviour). See setup description here.
Responsibility: * Store sessions
Scaling: * memcache.session_redundancy * solutions like repcache available
Elasticsearch is a so-called "no sql" storage, a non-relational database engine, which is very efficient in searching and filtering big catalogues. For that reason it can optionally be used, if you have many articles in your shop or if there are special requirements for filtering and searching. Shopware generally recommends using Elasticsearch if more than ~140000 articles are in place. Even with fewer articles your overall system performance might profit from using Elasticsearch, as filtering and search queries will usually generate quite some load on the database and have a low cache hit rate. Additional information regarding Elasticsearch are available here.
Responsibility: * Search and filter articles quickly * reduce load on database engine
Software to run: * Elasticsearch >= 2.0
Scaling: * scales horizontally (numerous ES server possible)
Images are usually uploaded on the admin server - but need to be available on all app servers as well. Usually syncing (duplicating) the images is not to be recommended for larger setups, so there are alternatives in place:
There is not "the one and only" way to build a cluster. The layout of the cluster should be adjusted to the needs and budget of the customer. For that reason there are a lot of variations in the setup that should be considered:
In some cases you might want to consider moving the cache layer to the app servers themselves. In that case the appserver would include varnish, apache and the Shopware application. This will keep the overall infrastructure smaller, but will force you to optimize the appserver for varnish and the webserver / application.
As an alternative you could also remove the varnish cache entirely and only rely on Shopware's built-in HTTP cache. If you are using many uncached ESI tags or uncached pages in general, this might even be beneficial, as Shopware has some optimizations regarding the handling of ESI tags from within the built-in HTTP cache. Please notice, that this will force you to optimize for appserver and built in cache.
Shopware handles sessions in the database by default. As this is not recommended for frontend sessions in a high performance setup, using memcached instead was discussed before. In some cases, the memcached instance can run alongside with other services like the load balancer, varnish or elastic search, if used. If memcached is not an option in your case, using redis or even dedicated databases are possible by providing custom session backends.
Clustering usually has quite some implications regarding the "single source of truth" in the setup. This especially applies for local caches (e.g. APCu, proxy caches, generated attribute models), locally generated files (e.g. user upload) and the sourcecode itself.
Since Shopware 5.2.0 you are able to configure multiple HTTP reverse proxies (e.g. varnish). So whenever the HTTP cache is cleared or certain pages need to be invalidated, Shopware will distribute this BAN and PURGE requests to all configured caches.
This does not yet apply for clearing caches like attribute cache, proxy caches, object caches etc. You can clear those caches using the cache endpoint of the Shopware REST API.
Usually content is generated in and distributed by the admin server. The configured file syncs and media shares will ensure, that all app servers to have access to this information. If you are using plugins that allow customers to upload files in the shop frontend, the uploaded files will not be available for all other app servers automatically. In those cases, you need to make sure, that the uploaded files are shared using CDN, shared storages or other syncing mechanisms.
Usually the shopware backoffice is available at
Many customers reason, that introducing a rule on the load balancer, which redirects all
backend/* traffic to the admin server will be sufficient.
This is not always the case: The shopware backoffice will dynamically load files from other locations such as
If your regular app servers are down for maintanance or other reasons, these requests will fail if your load balancer rule is too naive.
For that reason we recommend, having a separate virtual host for your backoffice, such as
This way the backoffice will fetch all required files from that specific virtual host - and you can easily configure your load balancer correspondingly.
After deploying Shopware from VCS, installing plugins or generating themes from the admin panel the file base of the admin server should be synced to all the app servers.
rsync is a commonly used tool for this kind of task - but you could also consider using lsyncd,
which is an extension to
rsync and watches and syncs directories automatically.
As most shop setups are quite individual and will include custom plugins, there is no finite list of directories that need to be synced.
Generally all files / directories of the Shopware setup should be synced across the app servers.
The following directories, however, need special treatment:
/var/cache: Handled individually on every appserver, no syncing
/files: Synced to each appserver or shared storage. Depends on installed plugins and used Shopware featured such as ESD etc.
/media: see above
Directories that might change during runtime:
/engine/Shopware/Plugins: Changed when plugins are installed from the admin panel
/themes/Frontend: Changed when new themes are created from the admin panel
/media: Changed when new images / videos / media are uploaded in the admin panel
/files: Changed when ESD items are uploaded or order documents are generated
/web: Sitemap generation