 |
Contact us: 314.238.1354 Toll Free: 888.326.1354 |
   |
Cluster your application - NOW!
May 16, 2008 on 12:06 am | In Tech |Is your Java Application Server clustered? Why not? It should be, and your reasons for NOT clustering have vanished, so there’s no excuse. Cluster. Now.
When designing a web architecture for an application, this question always comes up: “To cluster or not to cluster?” Clustering allows two or more app servers to act as one. This has many advantages, such as high availability if one server goes down, or the cluster can enable seamless upgrades to software or hardware. Clustering also allows a successful application to scale by spreading users across more and more servers. Unfortunately, clustered servers are much too rare today. But they shouldn’t be rare, clustering should be the default, the normal case.
Question: To cluster or not to cluster?
At first the answer is “no”, I mean… clustering make the installation more complex, there are performance impacts, and configuration problems and… well… RISK! But the benefits can be pretty great for an app that is growing. So if we can eliminate the RISK, then we have no reason NOT to cluster.
Answer: Always Cluster.
The time for clustering every Java application has come. Worrying about statefullness was a habit we acquired when SFSBs in EJB2 were dangerously bad at clustering (and a bad solution for many applications). But today, JBoss, Tomcat, and other Java app servers have matured to make clustering a solid part of any server. Terracotta has even come in to save the day for clusters with large node counts, or with huge memory needs, so the reasons not to cluster become smaller.
RedHat is telling everyone to virtualize Linux.. ALWAYS! And it makes sense. Servers out there need the flexibility of virtualization, and the reasons to NOT virtualize have vanished. It’s time has come. Technologies like Xen and VMWare have improved, but more than the technologies, the people have matured to understand the benefits and risks of virtualization. So now it’s packaging and marketing that are driving virtualization as the default answer.
Java application server clustering should now follow and become the default installation. The technologies are solid, so the clustering idea is just in need of good packaging such as easier installation and configuration utilities, and good marketing in the form of endorsements and documentation about the many benefits of clustering.
The benefits:
- High Availability - Server crashes, app stays up, ‘nuf said, this bene’ is obvious.
- Scalability - more users? add more servers, clustering lets your app grow - also an obvious bene’
- Hot Deployment - this bene’ is rarely understood, but it will save your weekend! Stop deploying on a weekend at 2am! Deploy on Tuesday at 11am, yes, while users are still using the system…. You see, most code changes do not require huge data conversions and outages (although those cases do happen). Most deployments are to fix a bug, change a label, add a brand new feature, or add more memory to the server - and those changes do not require downtime if I have a cluster and a deployment process that can make it HOT. Its quite simple - 1)take a server node out of the cluster, 2) upgrade the code, 3) put it back in the cluster, 4)repeat on other nodes. No late nights, no weekends -and no lost sleep. Developers and admins are handy and awake if anything goes wrong, no need to start that late-night conference call. Freedom…
Believe it? You may not, but I’ve witnessed it. My system took a millions of hits a day, and we deployed twice a day at times - between 8 and 5. We had a cluster of JBoss application servers and did the deployments in broad daylight without any affect on users. And all this with out-of-the-box clustering from JBoss.
If you want to talk RISK - try taking an outage at 2am on a Sunday for 5 hours after 3 months of intense development by a large team. Put in a massive code change and pray that the deployment goes well… Now that’s the stuff that nightmares are made of.
So cluster your Java servers, the benefits are big, and clustering comes with every application server - it probably came with the server you’ve got. No excuses, do it now.
-Jay Meyer
4 Comments »
RSS feed for comments on this post. TrackBack URI
Leave a comment
Cluster your application - NOW!
May 16, 2008 on 12:06 am | In Tech |Is your Java Application Server clustered? Why not? It should be, and your reasons for NOT clustering have vanished, so there’s no excuse. Cluster. Now.
When designing a web architecture for an application, this question always comes up: “To cluster or not to cluster?” Clustering allows two or more app servers to act as one. This has many advantages, such as high availability if one server goes down, or the cluster can enable seamless upgrades to software or hardware. Clustering also allows a successful application to scale by spreading users across more and more servers. Unfortunately, clustered servers are much too rare today. But they shouldn’t be rare, clustering should be the default, the normal case.
Question: To cluster or not to cluster?
At first the answer is “no”, I mean… clustering make the installation more complex, there are performance impacts, and configuration problems and… well… RISK! But the benefits can be pretty great for an app that is growing. So if we can eliminate the RISK, then we have no reason NOT to cluster.
Answer: Always Cluster.
The time for clustering every Java application has come. Worrying about statefullness was a habit we acquired when SFSBs in EJB2 were dangerously bad at clustering (and a bad solution for many applications). But today, JBoss, Tomcat, and other Java app servers have matured to make clustering a solid part of any server. Terracotta has even come in to save the day for clusters with large node counts, or with huge memory needs, so the reasons not to cluster become smaller.
RedHat is telling everyone to virtualize Linux.. ALWAYS! And it makes sense. Servers out there need the flexibility of virtualization, and the reasons to NOT virtualize have vanished. It’s time has come. Technologies like Xen and VMWare have improved, but more than the technologies, the people have matured to understand the benefits and risks of virtualization. So now it’s packaging and marketing that are driving virtualization as the default answer.
Java application server clustering should now follow and become the default installation. The technologies are solid, so the clustering idea is just in need of good packaging such as easier installation and configuration utilities, and good marketing in the form of endorsements and documentation about the many benefits of clustering.
The benefits:
- High Availability - Server crashes, app stays up, ‘nuf said, this bene’ is obvious.
- Scalability - more users? add more servers, clustering lets your app grow - also an obvious bene’
- Hot Deployment - this bene’ is rarely understood, but it will save your weekend! Stop deploying on a weekend at 2am! Deploy on Tuesday at 11am, yes, while users are still using the system…. You see, most code changes do not require huge data conversions and outages (although those cases do happen). Most deployments are to fix a bug, change a label, add a brand new feature, or add more memory to the server - and those changes do not require downtime if I have a cluster and a deployment process that can make it HOT. Its quite simple - 1)take a server node out of the cluster, 2) upgrade the code, 3) put it back in the cluster, 4)repeat on other nodes. No late nights, no weekends -and no lost sleep. Developers and admins are handy and awake if anything goes wrong, no need to start that late-night conference call. Freedom…
Believe it? You may not, but I’ve witnessed it. My system took a millions of hits a day, and we deployed twice a day at times - between 8 and 5. We had a cluster of JBoss application servers and did the deployments in broad daylight without any affect on users. And all this with out-of-the-box clustering from JBoss.
If you want to talk RISK - try taking an outage at 2am on a Sunday for 5 hours after 3 months of intense development by a large team. Put in a massive code change and pray that the deployment goes well… Now that’s the stuff that nightmares are made of.
So cluster your Java servers, the benefits are big, and clustering comes with every application server - it probably came with the server you’ve got. No excuses, do it now.
-Jay Meyer
4 Comments »
RSS feed for comments on this post. TrackBack URI
-
Are you kidding or what? Stop being so “this is ALWAYS good”-like. This is not true. Clustering really do add complexity in the setup.
Apart from the fact, that about 99,9% percent of the web applications done in Java these days don’t need to scale very big, there is also the consideration, that there are other ways to scale than clustering.
You can simply keep your server-side kode stateless all the way through to the database, and then scale out by adding more servers behind a load-balancer.
Ooh, yeah, and there are licensing issues, with commercial servers.
And there are issues with how you write your application. If you want full bang-for-the buck on your clustering setup, you will need to ensure idempotence for all your server-side method calls. Something that sure as hell aint coming for free, when developing.
My advice is: Do *not* cluster, until you are perfectly sure about your requirements to do so. There are other, simpler, better ways, to achive most of what cluster setups today is supposed to solve.
-
To the previous comment:
“You can simply keep your server-side kode stateless all the way through to the database, and then scale out by adding more servers behind a load-balancer.”
So you’re suggesting all session state (shopping carts, etc.) belong in the db? How well do you think that’s going to scale?
Comment by Scott Bale — May 16, 2008 #
-
It is not the wonder-solution of all kind, true. But it is simpler to deal with. And it can scale far more than one would think, though one should think about the read/write ratio of the application up front.
And BTW: The database will always be a problem to scale, also in a appserver-clustered environment.
-
I agree with Tech Per; the ALWAYS attitude is simply wrong.
We run a large insurance system and we will never have it run on VMWARE after no end of performance issues in our test setups.
At this time virtualization is good for workstations and test environments with 10 users.
As far as clustering goes, you’d have to develop you app from scratch and honestly, load balancing with database clustering is cheaper and easier to live with.
Comment by Ink — May 17, 2008 #
Leave a comment
Powered by WordPress with Pool theme design by Borja Fernandez.
Entries and comments feeds.
Valid XHTML and CSS. ^Top^
Are you kidding or what? Stop being so “this is ALWAYS good”-like. This is not true. Clustering really do add complexity in the setup.
Apart from the fact, that about 99,9% percent of the web applications done in Java these days don’t need to scale very big, there is also the consideration, that there are other ways to scale than clustering.
You can simply keep your server-side kode stateless all the way through to the database, and then scale out by adding more servers behind a load-balancer.
Ooh, yeah, and there are licensing issues, with commercial servers.
And there are issues with how you write your application. If you want full bang-for-the buck on your clustering setup, you will need to ensure idempotence for all your server-side method calls. Something that sure as hell aint coming for free, when developing.
My advice is: Do *not* cluster, until you are perfectly sure about your requirements to do so. There are other, simpler, better ways, to achive most of what cluster setups today is supposed to solve.
Comment by Tech Per — May 16, 2008 #
To the previous comment:
“You can simply keep your server-side kode stateless all the way through to the database, and then scale out by adding more servers behind a load-balancer.”
So you’re suggesting all session state (shopping carts, etc.) belong in the db? How well do you think that’s going to scale?
Comment by Scott Bale — May 16, 2008 #
It is not the wonder-solution of all kind, true. But it is simpler to deal with. And it can scale far more than one would think, though one should think about the read/write ratio of the application up front.
And BTW: The database will always be a problem to scale, also in a appserver-clustered environment.
Comment by Tech Per — May 17, 2008 #
I agree with Tech Per; the ALWAYS attitude is simply wrong.
We run a large insurance system and we will never have it run on VMWARE after no end of performance issues in our test setups.
At this time virtualization is good for workstations and test environments with 10 users.
As far as clustering goes, you’d have to develop you app from scratch and honestly, load balancing with database clustering is cheaper and easier to live with.
Comment by Ink — May 17, 2008 #