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:

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:

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:

  1. The user changes a configuration directive via UI.
  2. The UI modifies the server blueprint via the ZSD, and stores it on the database.
  3. The ZSD for each individual server in the cluster identifies the directive change and retrieves the new changed blueprint requirements from the database.
  4. 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).