The content of this guide is the following:
This guide is intended for JOnAS administrators responsible for the configuration and administration of JOnAS servers running within a management domain.
A JOnAS management domain is composed of a set of JOnAS servers that are running under the same management authority. All the servers in the domain must have a distinct server name and a common domain name.
The servers in a domain can be administered by a management application running on a server playing the role of administrator or master. The managed servers play the role of slaves. Note that it is possible to have several masters in a domain. Also note that default configuration corresponds to a slave server running without the discovery service (the role of this service is described below and its configuration here).
Typically, when deploying the JonasAdmin application on a slave, the administrator can manage only the server on which the application is running. When deploying JonasAdmin on a master server, the administrator can manage all the known servers in the domain:
Cluster management facilities was introduced in JOnAS 4.7. A cluster is a group of servers having common properties within a domain. A cluster may be the target of a domain level management operation - currently applications and J2EE modules deployment only.
The domain topology (servers and clusters composing the domain) can be defined using a new domain.xml configuration file. Also, servers and clusters may be dynamically added and removed to the domain via JonasAdmin.
Starting with JOnAS 4.8, domain and cluster management is enhanced with monitoring functions available in JonasAdmin. As in the previous version, clusters may be created by an administrator in a static (via domain.xml) or dynamic (via JonasAdmin) way. These clusters are now called logical cluster. A new class of clusters is supported in the current version, the physical clusters that are detected automatically by the management infrastructure. Several types of physical clusters are supported: Mod JK clusters, Tomcat clusters, CMI clusters, etc. All the members of a type of physical cluster share specific properties which depend on the cluster type, e.g., all the members of a CMI cluster have the same JGroups configuration. Note that a given JOnAS instance may belong to several physical and logical clusters.
An important domain level administration operation introduced in JOnAS 4.8, is the possiblity to start/stop the managed servers via a so called cluster daemon. Cluster daemons can be defined and associated to servers using the domain.xml configuration file. A cluster daemon has to be collocalized (located on the same machine) with the servers it controls.
Basically, domain management in JOnAS relies on JSR 160 specification. When a JOnAS server is started, it creates at least one JSR 160 connector server as explained in JSR 160 support in JOnAS.
A connector server makes it possible for a JMX remote API client to access and manage the MBeans exposed through the MBean server running in a remote JVM. In order to establish a connection, the remote client needs to know the address of the connector server. JSR 160 does not provide any specific API that would make it possible for a client to find the address of a connector server. The standard suggests using existing discovery and lookup infrastructures, for instance, JNDI API with an LDAP back end.
A new service added to JOnAS, the Discovery Service, allows JOnAS servers running over a LAN within the same management domain to communicate to each other the connector-server addresses they create at start-up. All the servers in the domain having the discovery service in the services list, will publish their connector-server address at start-up. The goal is to allow master servers to discover which servers are running in their domain, and to establish connections allowing them to remotely manage the slave servers by a management application deployed on a master server.
Starting with JOnAS 4.7, a server can be added to a domain via a management operation, thus allowing servers which cannot use the multicast-based discovery service to join a management domain.
The current discovery service implementation is based on MBeans (called discovery MBeans) which use:
J2EEDomain MBean has the following JMX ObjectName:
domainName:j2eeType=J2EEDomain,name=domainNameWhere domainName is the name of the domain.
J2EEDomain MBean contains several management attributes and operations related to servers management
in a domain:
J2EEDomainis registered in a master server's MBean server, the servers attribute keeps the list of the servers known in the domain. Otherwise, it contains only one element corresponding to itself. The elements in the servers list are Strings representing
J2EEServerObjectNames associated to the running servers. By iterating over the servers list, a management application can determine the name of the servers in the domain.
In order to administer a given server in the domain, any management application has to create an
MBeanServerConnection object using one of the connector-server addresses corresponding to that server
Starting with JOnAS 4.7, the
J2EEDomain MBean was enriched in order to support adding/removing a server to/from the domain,
creating a cluster in the domain, listing the clusters in a domain.
The following is a list of some of the new management attributes and operations exposed by a
J2EEDomainObjectNames associated to the clusters created in this domain (or in this cluster if the current
J2EEDomainMBean is associated to a cluster).
In JOnAS 4.7, clusters are implemented as "sub-domains", they have associated
type MBeans. For example, if a cluster named clust is created in the domain named
domainName, it has an associated
MBean with the following JMX ObjectName:
An important re-engineering of domain management mechanisms was conducted in JOnAS 4.8 to support
cluster and domain monitoring. Clusters aren't implemented as sub-domains anymore; there is only
J2EEDomain MBean registered in the master's MBean server. Another important point
is that the servers' state is no longer accessible in the J2EEDomain MBean (getServerState(serverName)
operation doesn't exist anymore). On the other hand, new MBeans were created:
ServerProxyMBeans. For every server known in the domain, a ServerProxy MBean is created with the following JMX ObjectName:
domainName:type=ServerProxy,name=serverNameIt contains a
Stateattribute which gives the server state as known by the master, and a set of monitoring information like memory usage, threads, transactions, etc. which are periodically updated. The servers may be in one of the following states:
MBeanServerConnectioncould not be established, or it doesn't work anymore)
jonas stopcommand (if the server has enabled its discovery service), or if the server was stopped using the remote control mechanisms (via the cluster daemon).
ClusterMBeans. For every cluster created in the domain, a
LogicalClusterMBean is created with the following JMX ObjectName:
The master may have registered other types of cluster MBeans which correspond to physical clusters. They are automatically created by the management system if managed servers are identified as being members of supported physical cluster types.A cluster MBean contains a
Stateattribute and a member's list. A cluster may be in one of the following states, which depends on the state of its members.
ClusterMemberMBeans. A member MBean's role is to make the link between a cluster MBean and the ServerProxy MBean corresponding to the server which belongs to that cluster. Any member MBean has a ServerProxy attribute equal to the corresponding ServerProxy MBean OBJECT_NAME. If a server belongs to several clusters, there is a member MBean for each cluster, and all these members have the same value for the ServerProxy attribute. There are several types of member MBeans. They correspond to the several cluster types. The
LogicalClusterMemberMBeans are used to represent
Mod_jkload balancing clusters. The members of such a cluster are workers defined in the mod_jk configuration file workers.properties. The workers correspond to JOnAS server instances having the web service based on Tomcat and a specific configuration (server.xml having a Connector XML element for AJP1.3 protocol defined, as well as the Engine element having the jvmRoute attribute set to the worker name).
The ObjectNames corresponding to Mod_jk clusters and Mod_jk cluster members are:
domainName:type=JkClusterMember,name=workerName,JkCluster=clusterNameThe workerName and clusterName are defined in the workers.properties configuration file.
Tomcatsession replication clusters. The members are JOnAS-Tomcat cluster servers having a
Clusterelement defined in server.xml file. The management infrastructure detects Tomcat cluster members by looking for Tomcat Cluster MBeans in the managed server's MBean server.
The ObjectNames corresponding to Tomcat session replication clusters and Tomcat cluster members are:
domainName:type=TomcatClusterMember,name=serverName,TomcatCluster=clusterNameThe clusterName can be defined in the server.xml configuration file.
CMIclusters. The members are JOnAS cluster servers sharing the same CMI configuration for the JNDI replication and the EJB clustering.
The ObjectNames corresponding to the CMI clusters and cluster members are:
domainName:type=CmiClusterMember,name=serverName,CmiCluster=clusterNameThe clusterName can be defined in the carol.properties configuration file and represents a JavaGroups group name.
HAclusters. The members are JOnAS cluster servers sharing the same HA service configuration for the EJB replication.
The ObjectNames corresponding to the HA clusters and cluster members are:
domainName:type=HaClusterMember,name=serverName,HaCluster=clusterNameThe clusterName can be defined in the jonas.properties configuration file and represents a JavaGroups group name.
The servers must adhere to these rules:
Also note the following:
Consider a scenario in which there are three JOnAS servers named jonas, j1 and j2. Assume that they have discovery service configured with at least one of the servers playing the role of master.
jonas start -n j1 -Ddomain.name=jonas
jonas start -n j2 -Ddomain.name=jonas
A default domain configuration is provided in
This configuration corresponds to a domain named jonas managed by a master
server also named jonas. The
location tag defines a JMX remote
connector server URL for this server.