Zend Server User Guide > Concepts > Architecture

Architecture

The Zend Server for IBMi architecture is based on a modern architectural model that is more robust and scalable in nature that allows you to support much larger clusters.

Homogenous Cluster

In a clustered environment, seamless scalability and flexible management are crucial, especially in cloud-based clusters. The Zend Server for IBMi architecture is based on a de-centralized management system that is comprised of identical components, facilitating high availability and supporting cloud environments.

Database Centricity

Zend Server uses a database back-end (MySQL, or SQLite in the case of a single server) to store information about the server, or servers, on which it is installed. The database stores two main types of information:

Configuration Settings Blueprint
This blueprint contains the desired configuration of all Zend Server components (including PHP), as well as any applications deployed through Zend Server’s deployment mechanism. It serves as a reference point for the server/s, which poll it periodically and check for changes (by default, every 30 seconds). Once detected, any changes made to the central blueprint are automatically applied individually by each server. Unexpected changes (e.g., if a configuration file was edited on a certain server and not through the Zend Server UI) will be automatically detected and reported in a detailed notification (see Notification Center for more information).
Server Status Information
Up-to-date information about the servers’ status, health, resource utilization and other statistics. This information is continuously updated by each server individually.

The robustness of the architecture stems from the fact that ultimately, each server is responsible for itself : it reports its own status, and takes care of its own configuration updates. There is no single active process that is responsible for these tasks, which makes it less prone to bugs and much more scalable.

The Zend Server UI interacts with the database via the Zend Server daemon (ZSD), changing configurations and issuing commands, and can be located on any one of the servers in the cluster, or even on separate servers.

Zend Server Daemon (ZSD)

The ZSD is the Zend Server service that manages the system and PHP configurations in your environment:

It is in charge of the initial creation of the Configuration Settings Blueprint on the database the first time you set up your environment, and all subsequent polling for configuration changes. Any configurations changes made via the UI are updated by the ZSD, on the blueprint and in the file system. Configuration changes made via the file system, are identified by the ZSD, which then reports the mismatched configuration, and depending on your decision - either applies the change, or reverts it to its former value.
In a cluster, the ZSDs for each server are in charge of aligning the configurations as defined on the central blueprint saved on the database. The adage and removal of servers from the cluster is also under the ZSD's responsibility.
The ZSD is responsible for identifying errors and failures in your PHP runtime environment (e.g., missing binary of a PHP extension).
The ZSD manages the Zend Server restarts. Should a configuration change warrant a restart, the ZSD will report this, and then perform a selective restart of only the components that actually need to be restarted. The ZSD also handles the Zend Server Restart Strategy.

Scenario: Changing a Directive in a Cluster

To illustrate how the Zend Server architecture works in a cluster, the following diagram simulates the process of changing a directive from the Zend Server UI:

The user changes a configuration directive via UI.
The UI modifies the server blueprint via the ZSD, and stores it on the database.
The ZSD for each individual server in the cluster identifies the directive change and retrieves the new changed blueprint requirements from the database.
The ZSD for each individual server writes the directive change locally, and updates the blueprint on the database.

Note:

If necessary, the user is notified that a restart of the servers is required (only services applying the changes will actually be restarted).