users@glassfish.java.net

Re: [ADVICE] DAS best practices in prodcution environment ?

From: John Clingan <john.clingan_at_oracle.com>
Date: Mon, 28 Nov 2011 10:01:56 -0800

Response inline.

On Nov 24, 2011, at 3:15 AM, forums_at_java.net wrote:

> Hi,
> If possible, I would need your suggestions on ths best pratices to setup
> glassfish DAS on our production platform.
> The context is the following:
> - Currently, we have more than 100 webapps hosted in clustered tomcat servers
> (at least 2 tomcat instances are used for lb) hosted on virtualized machines,
> - We are studying the migration of application servers from tomcat to
> glassfish, we are thinking about the following architecture:
>
> * Group webapps together in term of functionality criteria in the same
> domain.
> * Each webapp will be deployed in a cluster composed of 2 glassfish
> instances hosted in 2 different nodes (and probably with several glassfish
> instances on the same node).
>
> Due to the number of webapps hosted, this will lead to the creation of
> multiple domains, each of them hosting several cluster instances.
> I have seen that a common best practice is to separate the DAS from hosts
> used as glassfish instances.
> I agree with this, but I would need your advices to go in the right direction
> to setup glassfish domain(s) adminstration.
> According tou you, which option should be the best ?:
>
> /*option 1:*/
> - Use only one VM for the DAS that will host multiple domains (each domain
> will then hosts several clusters).
> Using for that asadmin "create-domain" --portbase option for each domain
> instance should do the job.
> In our production platform, this will probably lead to the creation of more
> that 20 different domains.
> I have read that this configuration is rather uncommon.
> Moreover, if this option is chosen, this will lead a lot of domain number and
> in addition of the feasability it will probably difficult for Adminstration
> tasks (eg. deployments) to known the relationship beetwen a particular domain
> and its adminstration port number.
> /*option 2:*/
> - Use one dedicated machine for each adminstration domain => will multiple
> the number of VM that will host each DAS but its not really an issue.

The approach of option 1 vs option 2 is really up to you. Different customers prefer different approaches, depending on existing business practices and preferences. Some will say placing all DASs on one machine (with different portbase) easier to manage and lower overall hardware costs. Some will same placing each DAS on its own machine easier to manage because they all use the same portbase. At the end of the day, it will probably depend on the number of DASs you have to deploy and the resources available on the machines.

Because you are consolidating lots of applications into a domain, be sure to take a look at DAS backup and recovery to minimize the impact of a hardware failure.
Oracle GlassFish Server: http://docs.oracle.com/cd/E18930_01/html/821-2416/gksgn.html#scrolltoc
GlassFish Server Open Source Edition: http://glassfish.java.net/docs/

The difference between the two is that Oracle GlassFish Server supports live DAS backup and the ability to schedule backups on a regular basis, whereas the open source distributions require you to shut down the DAS to back it up and do manual snapshots.

> /*option 3:*/
> - Use only one DAS hosted on one machine and create as many as cluster
> instances as needed. Everything is administrated by one domain, and I fear
> that it could be messy over time and that the DAS instance become overloaded.

We've done a lot of work on DAS scalability We formally test (and support) 100 instances per DAS, although there is no technical limitation. I recommend that you do not go over 100 instances (ex: 50 2-node clusters), especially if you want support.

Because you have 100 webapps, that's 200 instances (assuming 100 2-node clusters). That's a minimum of 2 DAS's, and 3-4 would be ideal to support future growth. I would also try to "standardize" on GlassFish configurations (settings) such as "small, medium, large" and have your clusters share those configurations to minimize management and DAS resource usage overhead. By default each cluster will create it's own configuration. Refer to "named configurations":
http://docs.oracle.com/cd/E18930_01/html/821-2426/abdjk.html#scrolltoc

Another thought is that you can split the DASs across two physical machines. A "catastrophic hardware failure" will impact the manage only 1/2 of your apps while the server is down, and using DAS backup and recovery, you can recover onto the remaining machine. While the DAS is down, the managed clusters will continue to run.

> According to you, which option should be the best or maybe is there a 4th
> option ?


> Cheers,
> Larico
>
>
>
> --
>
> [Message sent by forum member 'kerigan']
>
> View Post: http://forums.java.net/node/867604
>
>