Innovate faster and cut risk with PHP experts from Zend Services.
See How Zend Helps Leading Hosting Providers Keep Their Managed Sites on Secure PHP
Learn PHP from PHP experts with free, on-demand, and instructor led courses.
Submit support requests and browse self-service resources.
In this blog, we explore the various tasks involved in managing a PHP server on an AWS cluster, and how Zend Server can save you significant time.
The basic scheme of a cluster of PHP nodes usually looks as follows:
Deploying an initial cluster of PHP nodes is a relatively simple task. Managing the cluster is where you encounter more complexity. For example, some of the tasks you will need to continually manage include:
You can deploy and manage a PHP application server on an AWS cluster using community PHP and the utilities supplied by Linux distributions (RHEL/Ubuntu and derivatives). An easier option is deploying Zend Server in an AWS cluster.
Zend Server greatly simplifies the management of a cluster of PHP servers and can be controlled via a web based user interface or Web API (simple API that works on top of HTTP protocol). Zend Server requires a separate MySQL database when running in cluster mode to store its internal data. On AWS, you can use RDS as a MySQL server.
One of most common tasks involved in managing a PHP cluster is maintaining an updated PHP stack across all the nodes in the cluster. Linux (RHEL/Ubuntu) with Apache and PHP installed from packages supplied with the distribution do not provide any special means to solve this task. Of course, one can use rsync (or similar file synchronization tool) to synchronize files from a source host. You could even go further and spend time adding crons for rsync tasks and automate PHP code synchronization to run every few minutes. But to support and manage this solution is time consuming and complicated, and later requires even more management (especially when there are scripts that have to be run on every node before/after code synchronization because of a software version upgrade).
Another option is to use an NFS server to store all the PHP code on a single server and mount that NFS to all the PHP servers. But the performance of such a solution is very poor. Additionally, this automatically creates a single point of failure - the NFS server.
Zend Server solves this by providing the Zend Deployment component. Zend Deployment allows developers to pack their software in single a .ZPK file (zip based) and allows supplying scripts to run during the deployment stages: before/after staging, activating, rolling back, deactivating, unstaging. You can use a tool called zdpack to pack your application along with all the scripts (entirely optional). Each application deployed on Zend Server can later be upgraded and there is even an option to roll back.
This greatly simplifies the management of the cluster. You do not have to write and manage scripts that synchronize and deploy files and keep everything in sync. You can focus on developing your application and only manage the scripts related to upgrading the application.
Since PHP itself does not work as a cluster, the php.ini file, which holds PHP’s internal configurations, along with all the .ini files related to different PHP extensions, is not synced between PHP servers. Therefore, to keep configurations consistent between PHP servers, one has to find a way to sync .ini files and restart Apache as needed.
Again, there are a few ways to do this - from rsync running in cron, to NFS sharing .ini files between all nodes. There is also an additional solution using puppet or chef or a similar IT automation software, and managing the servers’ configurations centrally. If you already have puppet or chef deployed, then this solution will be most effective.
When deploying a Zend Server Cluster, you do not have to deal with this issue. Zend Server provides you with an easy way to configure all the PHP settings via a friendly and easy-to-use user interface, and every node entering the cluster is adjusted to match the existing PHP configuration. If that’s not enough, you also have a way to configure PHP in a cluster using Zend Server’s Web API.
PHP can store its log either in a file locally or send it to syslog. This complicates log analysis in case of a cluster. To examine PHP logs you either have to go through log files on each of the PHP servers, sync them to some central server or setup syslog to aggregate all the logs on a central server.
Using a Zend Server Cluster, you can centrally examine log files from all the nodes in the cluster, again using the user interface. Zend Server saves the log files locally on each node and fetches them from relevant nodes as needed.
Additionally, Zend Server’s Monitor component allows events to be shown in the Zend Server user interface based on event rules which represent certain configurable thresholds monitored during code execution. Events are shown for the entire cluster and not per cluster node, and are split by application.
In the most basic PHP cluster architecture, one of most important issues is how to share PHP sessions across PHP servers. There are a few ways to solve this issue:
Let’s go through each of these solutions with a quick comparison.
AWS Elastic Load Balancer can be configured to route requests from the same user to the same server. This allows saving PHP sessions locally on a PHP Server, but then there is problem with High Availability because each session is saved only on one single server.
NFS allows saving all the PHP sessions centrally on one server. But this complicates our setup by adding NFS server and also means that the NFS server is single point of failure. So it is also hard to implement High Availability here. There is also a chance of sessions being corrupted because it is used on different servers simultaneously and multiple simultaneous requests. And NFS performance is not particularly good.
There are a lot of best practices involving saving PHP sessions to a DB. You can use MySQL, MS SQL, PostgreSQL, etc. Since you’re running on AWS, it would be wise to choose a DB that is supported by AWS RDS. Then you do not have to manage the DB by yourself and you have an option to simply scale your RDS server as needed.
Memcached memory object caching system can be used to store PHP sessions in RAM. Its performance is very good because all the data is stored in memory. And although it can be clustered, it lacks an option for High Availability. In case memory allocated to memcached gets full, data is overwritten (because memcached uses cyclic memory).
Redis is an in-memory data structure store. It is similar to memcached, but it’s state can be saved between restarts. Since Redis stores it’s data in memory, it’s performance is very high too.
Session Clustering is an integral part of Zend Server and can be easily enabled on Zend Server Cluster in one click. It was designed to provide High Availability while maintaining good performance. PHP sessions are stored both on disk and in memory. To improve performance and lower resource consumption, it uses Peer-to-Peer protocol to communicate between nodes.
If you want to simplify your PHP AWS clusters further, check out this blog post on the AWS EFS file storage service.
To sum it all up, a Zend Server Cluster simplifies the management of a cluster of PHP servers. It provides a solution to most of the common tasks out-of-the-box and without additional writing and managing scripts.
In addition, Zend Server comes with bundled with a variety of tools not covered in this article (like Zend Data Cache - a component providing caching layer in PHP, Zend Debugger - a component that allows debugging PHP code, Zend Page Cache - a component that improves performance by caching output of PHP script, and plenty more).
Try Zend Server Free