Last time I introduced the serverAddToCluster Web API action which allows us to initiate clusters and join existing ones with Zend Server. The previous installment shows some code and discusses how this process is started but not how we should track progress and deal with ongoing issues. In this article, I aim to take what was discussed in the Zend Server Asynchronous Actions actions and combine it with what we know about cluster-joining into a complete process.
Having called serverAddToCluster, we now have a server which is in transition from being a standalone, sqlite based Zend Server and into a MySQL connected Zend Server. It’s important to stress that this transformation is a subtle one as far as Zend Server is concerned – we merely switch the data source for management and handling of directives, extensions and applications. The rest is just going through the motions of going back to baseline so that the new member is identical to the other cluster members.
The serverAddToCluster response should look something like this:
2 admin 2010-12-15T17:59:12+02:00
I’ve left in the important bits: A new database user/password pair was created, the cluster admin Web API key is displayed.
First thing first: copy over the
Polling after serverAddToCluster
serverAddToCluster is unusual in that it goes through two phases once it is actually being processed. We’ve found out about the first phase in the previous post. The initial phase is concluded when we finally have some information about the new cluster member in the cluster database.
Next, Zend Server continues the connection process on the cluster’s database, updating the Server record with its progress. During this stage, the cluster’s configuration is applied to the new member. Changes are made to the existing members to accomodate the new ip address and those configuration directives that reflect the cluster’s structure.
Once this process is complete, the server is effectively connected and the Join task is deleted. Polling the tasksComplete action from this point on will indicate that the cluster has no ongoing tasks. This indication is, unfortunately, a little misleading as there is still work beind done. The newly joined server now goes through the process of deploying all existing applications, vhosts and libraries.
During this time the client may poll the clusterGetServerStatus Web API action to retrieve the current server’s status. Once this status shows the server at a final state (i.e, not in-progress) the process is finally complete.
Lets see some code
First, we will poll on the tasksComplete action:
$client = new ZendHttpClient(); $client->setUri('http://localhost:10081/ZendServer/Api/ tasksComplete') ->setMethod('POST') ->setHeaders(array( ... )); $response = $client->send(); echo $response->getBody();
Which should return something like this:
tasksComplete may be false for a few iterations but eventually it will turn true.
Next, we can retrieve server status information to see how our server is doing in the 3rd phase:
$client = new ZendHttpClient(); $client->setUri('http://localhost:10081/ZendServer/Api/ clusterGetServerStatus') ->setMethod('GET') ->setHeaders(array( ... ))->getRequest()->getQuery()->fromArray(array('servers' => array(5)));
$response = $client->send(); echo $response->getBody();
Which should respond with:
25 Server unique name10.0.0.10 restarting false
Continuously polling the clusterGetServerStatus should eventually land the server in some final state – error, warning or otherwise an “OK” state. At this point, you can rest assured that your server is connected and fully operational within your cluster.