Part 1
Part 2
You will need QuickTime Player installed. Here is the transcript:
Hi, my name is Kedar and I am administration/management architect for GlassFish V2. Welcome to this GlassFish V2 Screen-cast.
Owing to growing popularity of clustering features of GlassFish V2, from build b48 onwards, we have added a nice feature to dynamically add the clustering support to an existing domain. I expect it to ease migration of your applications to the enterprise, by helping you scale those applications.
First, some terminology -- A developer domain -- a domain where the domain = server. There is a single VM that hosts user applications. The same VM has built-in support to manage applications including management of itself. Thus, in this case, the domain is same as server, and the so-called domain admin server (DAS) is the same as your server where you deploy your applications. Such a domain is characterized by a "developer" profile.
A cluster-aware domain -- a domain where the domain has support for standalone and "clustered" server instances. Every server instance is a separate Java EE engine (and VM) and those instances host your applications. In other words, they are your "deployment targets". The plain old domain in that case assumes the role of a manager of these clusters and instances. Of course, the manager itself can continue to be deployment target. But it is not the usual case. As you can imagine, in a production/enterprise scenario, you'd want to limit the manager to management and not expose it to users of your applications, isn't it? Such a domain is characterized by two profile names -- "cluster" and "enterprise" in GlassFish V2.
The usual way in which GlassFish V2 and Sun's Application Server solve this problem is by creating the domains with a create-time-profile. This profile determines whether a domain supports clusters to begin with. As you can imagine, clustering brings in some additional features and subsystems that won't be required in the developer case. Thus, the DAS for developer profile (which is of course the only server process in the domain) and that for cluster profile are slightly different entities. A developer domain, as you can imagine, would throw an error when asked to create a cluster for instance, because it is not equipped with all the bells and whistles needed to provide such a support.
So, developer domain is popular with developers. The NetBeans assisted develop+build+deploy+debug cycle is facilitated in that setup.
So, what do you do? Right -- you start with the developer
domain. Of course, you deploy and debug your applications.
Maybe you host an application like forums or bookstore etc. But it may so happen that the only server machine you have is shut down. The application/service you have is then unavailable. That's where the cluster domain comes into picture. You can deploy your application to the cluster and bingo, if one of the machines goes down, your availability is affected only slightly!
But wait a minute. You have started with developer domain, deployed services and six months go by and the service is shut down for a while. Is the only way out to impart availability then to start all over? You'll say, "You mean I redo the entire configuration changes? I don't remember all those! Bummer".
Well, that is unfortunate if true.
That's where this feature comes in handy. Once you think that your domain needs availability, you just do it "on the fly".
Here's how you do it:
You have a developer domain.
This is shown in the start-domain output as shown here.
The output says -- this domain does not support the clusters and instances. Say you have deployed some applications. Now, logon to the powerful GlassFish V2 admin console. It shows the state of the domain and as you can see, it does not have any clusters/load-balancing configuration support.
Owing to the previous discussion, you decide to provide clustering support. Here is the button that is available right on the "Application Server" tab. Just click here and it does all the magic. Now, this domain is "upgraded" to have the cluster management support!
You can continue to modify the configuration, but it is better that you restart the domain as the console shows.
Thus, when you start the domain, you'll see that it takes a little longer to start up and also displays that it now supports the clusters.
After you restart the domain, you will observe the subtle changes that happen to the domain's configuration and admin console appearance. For example, you'll see cluster and instance nodes that were not available before. You can now use targets for deployment. Thus the given application which is available on the DAS alone can easily be referred to from other targets.
What happens under the hood?
- The server is upgraded to have domain administration support. This requires few JVM parameters to be tweaked. These are internal GlassFish/Application Server VM parameters that turn on the clustering.
- The enabling factor here is that all distributions of GlassFish/Application Server have exactly same set of bits! This is a welcome change in the way we distributed the application server bits. In other words, the support was already available in the server's binaries, we only ensured that that it is instrumented through configuration.
How to impart availability to existing applications and resources?
Here are the (only) steps:
- Select the application deployed onto domain. At the moment, since this is only upgraded to be cluster-aware, it is available only on the domain. Go to admin console and make the changes to its configuration to say that its "availability-enabled" flag is turned on. Make sure that your web-application is distributable.
- Create clusters of your interest. Add server instances to it.
- Create and start the node-agents on the machines where your instances in your cluster are going to reside. Of course, you need to have GlassFish V2 installation on those machines.
- Create references to applications and resources that you deployed to the domain, from the cluster(s) of interest. Note, you don't have to redeploy!
- Start the cluster(s).
- The applications are available in all the server instances. You can then load balance these applications using a software load balancer (and/or h/w load balancer). Thus an application like bookstore that was available on http://das-machine:8080/bookstore would be available also on http://foo:38080/bookstore and http://bar:38080/bookstore. The only difference is that the applications available on machines "foo" and "bar" take part in availability. The one that is available on "das-machine" does not. But that's the way it should be, as you don't want to stress the "das-machine" to serve pages from your bookstore. Thus, once everything works, you can "de-reference" the bookstore application from the DAS!
That's it, no other changes needed.
What if something goes wrong?
The only file that is modified by this operation alone is domain's domain.xml. So, before you do this operation, it might be better to back domain.xml up.
Is there a way to go back?
Yes, only if domain.xml is backed up. Application Server software does not provide a way to do it. The reason we don't have it is because we think you'll never want to go back once you "upgrade" the domain this way. The reason is that the domain continues to work the way it was working and adds a clustering support on top!
That's about it. Thank you for listening.
]]>
