Zend Server Web API spotlight: Connecting to a Zend Server cluster, part 3

Hey Everybody,

In my previous posts in the cluster series, I covered different ways to connect Zend Server directly to a cluster. This method of connection was introduced in Zend Server 6.0.0, giving it the much needed flexibility. Using the direct approach, a server can either create a cluster or connect to an existing cluster and all you need is database credentials and good intention.

Back in the days prior to the Zend Server 6 availability, a different beast ruled the land: the indirect approach.

Why Indirect? A little history

Zend Server 5.0.0 was introduced in two different editions (besides community): Professional and Cluster Manager. These two editions were actually very different from each other. Cluster Manager was designed to act as the administrative center for a cluster. A cluster therefore was composed of a Cluster Manager and cluster members (of Professional edition). All activity was actually done through the Cluster Manager, including adding new servers to the cluster.

This was done through the clusterAddServer Web API action (est. Version 5.1) that was called on the Cluster Manager.

The Indirect Approach

The clusterAddServer Web API action survives to this day and can be used on any server, since we no longer have a Cluster Manager. This is one of the unique actions in Zend Server that uses a Nested Web API action. Nested actions are Web API actions that are called from within a Web API action. This effectively means that in this scenario there is actually a 3rd party – the real target of the action.

One big advantage of working with the indirect approach is that you do not need to provide any database credentials – just point the Web API action to the right target, send a host parameter and Zend Server takes care of everything else.

Naturally, for this action to work you must have a Zend Server that you want to connect to a cluster (name it Server A), another Zend Server (name it Server B) which is already connected, and a client for sending the Web API action request.

The Indirect Approach, play by play

We want to connect Server A to our Cluster. Our client is a basic http client which is ready to send a Web API action. This was covered previously and so I’ll skip the setup for brevity.

The client sends a clusterAddServer Web API action request to Server B. Recall, Server B is already connected to the cluster and for all intents and purposes acts as a Cluster Manager. Server B is important – it is connected to the cluster database and is therefore privy to the database credentials needed to connect.

One of the parameters passed to the request is the “serverIp” parameter which indicates to Server A how Server B is to be contacted. Server A then internally generates a serverAddToCluster Web API action request and sends it to Server B, based on the serverIp parameter. Along with the request are sent the database credentials Server A has internally.

Server B receives the serverAddToCluster Web API action request and acts on it. Server B goes through a standard 1st phase connection process. If you recall, the 1st phase completes when we have a server Id to return to the client and so Server B returns its response to Server A.

Server A then repackages this response, checks it for errors and then sends it on to our client as its own response.

From here, the Indirect approach seems remarkably like the direct approach. The client is expected to poll the cluster (through Server A or Server B) and track the connection process through its three phases till completion.

Lets see an example

$client = new ZendHttpClient();
$client->setUri('http://10.0.0.9:10081/ZendServer/Api/
          clusterAddServer')
 ->setEncType(ZendHttpClient::ENC_FORMDATA)
 ->setMethod('POST')
 ->setHeaders(array(
   ...
 ))
 ->getRequest()->getPost()->fromArray(
     array(
     'serverName' => 'Server unique name',
     'serverIp' => '10.0.0.10'
 ));
$response = $client->send();
echo $response->getBody();

After some time, this action should respond with:

      25
      Server unique name
      
10.0.0.10
      restarting
      
      false

      No

      2
      admin
      
      
      2010-12-15T17:59:12+02:00

Notice how the action has no database credentials’ details but it also returns a full payload.

Now what?

Using the serverId we retrieve from the element you may now begin polling the tasksComplete Web API action and then the clusterGetServerStatus action. Note the availability of an updated Web API key. A key which you probably already have since you used it to run clusterAddServer …

In summary

In this 3-part post we’ve gone through the motions of adding new members to our cluster in two different ways. We used the basic mechanisms of the Web API and also saw how we can use and monitor Web API actions that are asynchronous.

Creating and joining clusters are two really basic actions that were designed, both for the old and the new Zend Server 6. They incorporate many of the basic concepts Zend Server uses for other activities and actions.

Future posts will cover other sections of the Web API with a strong emphasis on useful workflows.

Read more : Zend Server Web API spotlight: Connecting to a Zend Server cluster, part 3