On June 23rd Zend announced the release of Zend Server Cluster Manager. Which means what, exactly.
PHP is designed using a shared-nothing architecture. What that means is that nothing is shared. What that really means is that each individual PHP request is isolated from every other PHP request. That's great! It makes for a very stable, very easy to use architecture. But what happens when you go beyond one server?
Not much, in actuality. How about a hundred? Same thing (yes, that is to some degree a hyperbolous statement). You might need to worry about scaling your database now, but the PHP side of things will continue to chug along.
But what about management? Managing a hundred servers is quite different from managing one. Heck, managing three servers is different from managing one. As a side note, you should never have two servers. If you have the budget for two you have the budget for three. Why three? Because when you take one down for maintenance you still have redundancy. If you only have two you do not.
One of the primary ways that Zend Server (not Zend Server Cluster Manager) benefits you is in the monitoring of your PHP application. Checking for long running requests, excessive memory usage, PHP errors and the like, storing that information so you can either replay them in the testing environment or, with Code Tracing, seeing the individual function calls with timing and memory usage. Additionally, you have the ability to use the Job Queue to run tasks asynchronously. You have the ability to manage your configuration via an easy to use GUI. You have the ability to run Session Clustering.
But you don't have the ability to look at your Zend Server servers as a holistic environment. That is what Zend Server Cluster Manager does for you.
- Centralized settings
- Centralized Monitoring (including notification of unauthorized configuration changes)
- Centralized Session Clustering management
- Centralized everything
Got a hundred servers? Need to make a change to php.ini? Piece of cake. Need to add a server and have sessions automatically distributed to the rest of the cluster? Piece of cake. Need to aggregate monitoring data from those hundred servers? Piece of cake.
Setting up Zend Server Cluster Manager is really easy. First, make sure that you have the Zend repository settings in your configuration. In my case I'm using Yum.
[Zend]
name=Zend Server
baseurl=http://repos.zend.com/zend-server/rpm/$basearch
enabled=1
gpgcheck=0
[Zend_noarch]
name=Zend Server - noarch
baseurl=http://repos.zend.com/zend-server/rpm/noarch
enabled=1
gpgcheck=0
After that "yum install zend-server-cluster-manager". The next thing you need to do is make sure that a MySQL server is available somewhere. This MySQL server needs to be accessible to the individual Zend Server nodes so simply doing root@localhost won't be sufficient. Have a non-standard user and make a good password. Keep the server behind a firewall, but make it available to the nodes.
After you have installed Zend Server Cluster Manager you need to go to the GUI page which is on http://(server):10081/. There you will agree to the terms and conditions and enter in the GUI password. After the first two pages you will come upon a page that asks you for two different licenses. The first license key is for the cluster manager itself. The second is the license key that the cluster manager will use on all of the nodes. After you have entered the license keys you will be asked to enter in the database information. It will not accept the localhost as the database. It must be an outward facing network address so the nodes can connect.
After you've done that you are ready to start adding nodes. You can actually add existing Zend Server instances (which is kinda how it works anyway), but make sure that you have updated them to the most current revision first. I didn't do that and submitted a bug report 3 days before the launch because a bunch of things were broken. Hilarity did not ensue.
Adding a new server to the cluster is relatively easy. In the Cluster Setup window click on the "Add Server" button. Enter in the information. Done. When setting up an individual node you will need to at least go through the setup in the GUI once (again, server:10081). You can enter in the license key if you want, but the only thing that's needed on the node is the password so that ZSCM can authenticate against it. Once a server is part of a cluster you cannot manage it except through the ZSCM GUI. Well, I take that back. You can manage it by making changes locally via the CLI, but then ZSCM will throw a warning stating that a server is out of sync. It won't remove it or anything like that, just tell you about it.
Comments
Alex
Hello,
I were searching the article of yours which best suit the subject i’m proposing to discuss around and i think it’s this one.
When in front of session clustering subject, often, things are not going to be easy for everyone 🙂 After diving more or less into the subject, my decision were to follow approach of “storing session information in a database along with relying on session affinity”. Now i have discover Zend clustering solution, i’m not so sure of my choice as Zend approach seems one of the best solution, if not the best one.
That being said, it’s not so easy as well to understand the Zend communication on the subject and i would be glad to suppress my lack of understanding. Indeed, Zend communication seems to me sometimes incomplete, sometimes contradictory, sometimes vague, sometimes unfair. That make me think of the Lotus Notes platform along new releases, where new features seem to be great, but at a quick time or another, they come with advices (even from lotus itself) to avoid their usage whatever the reason (performance, architecture workaround…), Lotus is among the best specialist of that kind of things and this lets me the taste of “look but don’t touch, touch but don’t taste, taste but don’t eat…”; this reminds me a movie and something else… 🙂 At the end, this kind of communication does not deserve well the product and the subject.
Alex
Coming back on zend, what do we have in this communication ? For example these 2 documents for which i will only mention some kind of comparison between “storing session information in a db” and Zend cluster as the subject is not to have a too big discussion on the clustering purpose in general.
So, let’s name Doc_A this http://static.zend.com/topics/session_clustering.pdf
and Doc_B that http://static.zend.com/topics/Session-Clustering-ZSCM-WP-0610-EN-A4.pdf
There is 5 years of date publication as a difference but this does not change much things to my mind.
Doc_A mentions that db approach suffers from (which is also the summary of the different approachs) :
a) In addition to being significantly slower than local session access, storing session data in the database puts a lot of additional strain on the database
b) A database remains a single point of failure
c) Writing session data to the database remains a scalability bottleneck, especially since the scalability of the cluster is impaired not only by the database’s ability to serve session data but also by it’s overall ability being impaired by the load of dealing with sessions
Alex
In my opinion, these are not the best arguments for Zend cluster when the db in question is a good NoSQL clustered db that we can benefit today. But let’s move on the Zend solution : “Zend solution avoids the drawbacks present in alternative solutions – in a cost effective manner”. Well that may need to be discussed outside this comment but in short, that’s probably true Zend solution is easier to practise; the “simple thing” that Zend uses PHP’s native session extension – without changing any code is a must among the facts. Among the benefits, when something is easier, it has good chances to cost less. Here the db approach is quite an investissement at the beginning, well, depdending of the number of zend servers, Zend approach is quite an investissement too… hopefully if we have a lot of servers, Zend Unlimited program comes to the rescue and we have to consider the fact Zend server has other added values but i just focus the clustering subject right now as covering everything would take too long, particulary in this comment.
I also have doubts about several others Zend marketing promises like “Fast: the session clustering module has been benchmarked to be 4 to 6 times faster than alternative solutions in a typical configuration “, well i would be curious to see some situations compared with Caucho distributed and persistent sessions explained here http://www.caucho.com/articles/php-sessions.pdf. Here again, i don’t think Zend is using the good arguments of the Zend clustering benefits. I would prefer truth over marketing and rely on the main points, something like ok Zend is not the best here and here but here what we particulary focused on and so what you can really benefit of, that would help to drive us to our real objectives and the way we want to manage them.
Alex
They are several others talks like that i skip here for convenience and in order to mention the one that really keep my attention : the session-persistent load balancing. In this section of the document, there are some arguments i look as incomplete, fuzzy and not so far from wrong these days (document is 2005 dated) but the one that i keep in mind is “When distributing sessions to the same servers, the load is not optimally balanced between the servers in the cluster”. Well, at the end of a global point of view, some agree, some disagree and to give examples in the java space, the zk framework community agree while the lift framework guys disagree. I think they have both valid arguments but whatever these discussions, there is some truth in the zend declaration and this the precise reason i’m not so sure between the db approach and the Zend proposition.
To try making progress on this point, let’s move on Doc_B which uses the quite the same arguments as Doc_A with a little more details. Skipping these details, we see that Zend is now the advocate of session affinity : ” If you have a sticky or semi-sticky load balancer, Session Clustering will work well with it, and in fact will perform even better with higher levels of session affinity.” What ? first, i were personaly in the doubt between the session affinity approach (Zend declared as a drawback in Doc_A) and the Zend approach and now Zend tells in Doc_B that affinity is and advantage and the good way to follow ? Zend insists by using the argument of this alternative approach : “With Session Clustering, network
access and session retrieval time are greatly reduced if a sticky load balancer is used. Since sticky load balancers typically direct users to the server in which their session was created, sessions are almost always fetched from local storage. Network access will only be needed in case of server or load balancer failure, in which case Session Cluster will ensure session fail-over”.
Alex
Something bugs me here 🙂 as finally, among all the arguments exposed, the affinity supposed drawback were finally one of the really main argument i kept in mind in favor to Zend clustering; if now Zend itself suppress this last one, i may finally wonder why i should choose Zend solution… yeah, the “famous others added values of the zend platform” but well, here again, i’m just talking of clustering only. The zk community, previously mentionned, is more into the Zend clustering approach without session affinity, relying on the argument to benefit of a really linear scability. This is the main thing i were and i’m still thinking about but i feel Zend cuts the line here by turning back its first approach. This is the main existential question I have in this regard “session affinity with a clustered db versus Zend solution” and if I had the suggestion of an article to submit, it would be on this point.
I conclude my comment by this last subject: the master server and a backup server for Zend redundant session storage. True that the replication of each session to two servers provides a very good balance between performance and high-availability, this compare to others products architecture implying far more than 2 servers. True again in most clusters, the chance of multiple servers failing at the same time is very low but it depends at what degrees. I follow the Zend approach here but to guarantee a better chance of session availability, i would vote for 3 servers instead of 2, that’s very possible to achieve. I saw that the performance overhead of replication could become a problem after 6 or 8 servers, some products do better but i’m not a supporter of this approach, i prefer Zend one but admit only 2 servers seem to me too little as if the master or backup server fails, we have only one level of protection, that is we are nearly out of the session clustering scenario… if i miss a thing, this could also be subject to an article 🙂
Sorry to have been a bit long…