To understand the term high availability, here is its definition from Wikipedia:
"High availability is a system design approach and associated service implementation that ensures that a prearranged level of operational performance will be met during a contractual measurement period. Users want their systems, for example, hospitals, production computers, and the electrical grid to be ready to serve them at all times. ... If a user cannot access the system, it is said to be unavailable."
In the IT field, when we mention the words "high availability", we usually think of the uptime of the server, and technologies such as clustering and load balancing can be used to achieve this.
Clustering means to use multiple servers to form a group. From their perspective, users see the cluster as a single entity and access it as if it's just a single point. The following figure shows the structure of a cluster:
To achieve the previously mentioned goal, we usually use a controller of the cluster, called load balancer, to sit in front of the cluster. Its job is to receive and dispatch user requests to a node inside the cluster, and the node will do the real work of processing the user requests. After the node processes the user request, the response will be sent to the load balancer, and the load balancer will send it back to the users. The following figure shows the workflow:
Besides load balancing user requests, the clustering system can also do failover inside itself.
Tip
Failover means when a node has crashed, the load balancer can switch to other running nodes to process user requests.
In a cluster, some nodes may fail during runtime. If this happens, the requests to the failed nodes should be redirected to the healthy nodes. The process is shown in the following figure:
To make failover possible, the node in a cluster should be able to replicate user data from one to another.
Tip
In JBoss EAP6, the Infinispan module, which is a data-grid solution provided by the JBoss community, does the web session replication.
If one node fails, the user request could be redirected to another node; however, the session with the user won't be lost. The following figure illustrates failover:
To achieve the previously mentioned goals, the JBoss community has provided us a powerful set of tools. In the next section we'll have an overview on it.
As a Java EE application server, JBoss EAP6 uses modules coming from different open source projects:
Web server (JBossWeb)
EJB (JBoss EJB3)
Web service (JBossWS/RESTEasy)
Messaging (HornetQ)
JPA and transaction management (Hibernate/Narayana)
As we can see, JBoss EAP6 uses many more open source projects, and each part may have its own consideration to achieve the goal of high availability. Now let's have a brief on these parts with respect to high availability:
The clustering for a web server may be the most popular topic and is well understood by the majority. There are a lot of good solutions in the market.
For JBoss EAP6, the solution it adopted is to use Apache httpd
as the load balancer. httpd will dispatch the user requests to the EAP server. Red Hat has led two open source projects to work with httpd, which are called
mod_jk
and
mod_cluster
. In this book we'll learn how to use these two projects.
JBoss EAP6 has provided the @org.jboss.ejb3.annotation.Clustered annotation that we can use on both the @Stateless and
@Stateful session beans.
When using @Clustered with @Stateless, the session bean can be load balanced; and when @Clustered is used with the
@Stateful bean, the state of the bean will be replicated in the cluster.
JBoss EAP6 provides two web service solutions out of the box. One is JBossWS and the other is RESTEasy. JBossWS is a web service framework that implements the JAX-WS specification. RESTEasy is an implementation of the JAX-RS specification to help you to build RESTFul web services.
HornetQ is a high-performance messaging system provided by the JBoss community. The messaging system is designed to be asynchronous and has its own consideration on load balancing and failover.
In the database and transaction management field, high availability is a huge topic. For example, each database vendor may have their own solutions on load balancing the database queries. For example, PostgreSQL has some open source solutions, for example, Slony and pgpool, which can let us replicate the database from master to slave and which distributes the user queries to different database nodes in a cluster.
In the ORM layer, Hibernate also has projects such as Hibernate Shards that can deploy a database in a distributed way.
In the previous sections, we had an overview of high availability and what JBoss EAP6 provides to us in relation to this topic. It doesn't matter if you haven't understood all the things. We'll touch these parts in this book step by step to help you build the whole picture. The first step is to install JBoss EAP6. Please download JBoss EAP 6.1.0.Final from the following URL:
http://www.jboss.org/jbossas/downloads/
Locate the 6.1.0.Final version and download the ZIP file. After the ZIP file has been downloaded, extract it. The contents are shown in the following screenshot:
From the previous screenshot, we can see a JAR file named jboss-modules.jar. This JAR file will help us to load the components of the server. The components of the EAP6 server are located in the modules directory. This directory contains the components of EAP6 that could be loaded by jboss-modules.jar.
The bin directory contains the start script and other tools that we'll use later.
The standalone and domain directories are related with the EAP6 startup mode. We'll cover it in more detail in the next section.
The startup mode is a new concept introduced in JBoss EAP6. There are currently two modes provided by EAP6:
The standalone mode
The domain mode
And there are two startup scripts in the bin directory for these two modes:
domain.sh standalone.sh
Let's see the meanings of these two modes.
The domain mode is a new concept introduced in EAP6. A domain means a group of servers that can share configuration/deployment information, which is very useful in a clustering environment.
For example, we have the three JBoss EAP6 servers running, and they form a cluster. Suppose we have a project called cluster-demo and want to deploy it to the cluster. The traditional method is to deploy this project to each EAP6 instance manually.
Fortunately, with the help of the domain management function in EAP6, we can now configure many EAP6 servers as a server group and deploy a project into this group. Then the project will be deployed into all the EAP6 servers that belong to this group. The domain mode provides a centralized management point to our cluster. The server group also shares the same configuration that is automatically distributed to all nodes. We'll see its usage in later chapters.
Let's now try to start JBoss EAP6 in the standalone mode. Go to the bin directory and run standalone.sh. The server output is shown in the following screenshot:
Now let's look at some details on the server output to understand the startup process.
We can see several important things from the server output. The following is the first one:
Started 123 of 177 services (53 services are passive or on-demand)
From the previous log, we can see that not all the components are started during the EAP6 startup process. This design greatly speeds up the startup time of EAP6. We can see that some services are started by default during the start process:
These components are called subsystems. These subsystems are configured in the standalone.xml file upon navigating through standalone/configuration.
Now let's see the actual command in standalone.sh that starts the EAP6 server:
eval \"$JAVA\" -D\"[Standalone]\" $JAVA_OPTS \
\"-Dorg.jboss.boot.log.file=$JBOSS_LOG_DIR/server.log\" \
\"-Dlogging.configuration=file:$JBOSS_CONFIG_DIR/logging.properties\" \
-jar \"$JBOSS_HOME/jboss-modules.jar\" \
-mp \"${JBOSS_MODULEPATH}\" \
-jaxpmodule "javax.xml.jaxp-provider" \
org.jboss.as.standalone \
-Djboss.home.dir=\"$JBOSS_HOME\" \
-Djboss.server.base.dir=\"$JBOSS_BASE_DIR\" \
"$SERVER_OPTS" "&"Tip
Downloading the example code
You can download the example code files for all Packt Publishing books you have purchased from your account at http://www.packtpub.com. If you purchased this book elsewhere, you can visit http://www.packtpub.com/support and register to have the files e-mailed directly to you.
From the previous command, we can see that jboss-modules.jar is the bootstrap JAR file for the whole EAP6 server, and the entry point is org.jboss.as.standalone, which is specified in the following command:
-jar \"$JBOSS_HOME/jboss-modules.jar\" org.jboss.as.standalone
We'll see more details about the startup process later. Now let's check the configuration file of the standalone mode.
The structure of standalone.xml is as follows:
As shown in the previous screenshot, standalone.xml defines multiple aspects of the standalone service. Let's have a brief view:
Besides the default file standalone.xml, EAP6 has provided some other profiles for the standalone mode.
Tip
There is only one profile per standalone configuration file. In contrast, multiple profiles could be defined in the domain configuration file.
We can check them in the standalone/configuration directory:
These files define the different profiles for different purposes. The following is a summary of their differences:
To use these alternative configurations during startup, we can use the -c option when calling standalone.sh. For example, if we want to use standalone-ha.xml, the command is as follows:
$ ./standalone.sh -c standalone-ha.xml
Please note that the -c option assumes that the configuration is located at $JBOSS_HOME/standalone/.
In this section, let's have a look at the domain mode. Use the following command in the bin directory to start the EAP6 server in the domain mode:
$ ./domain.sh
We can see that the startup process is different with the standalone mode. Firstly, there are many more components loaded in the domain mode:
Started 274 of 401 services (126 services are passive or on-demand)
And in domain.sh, we can see that the startup command is also different:
eval \"$JAVA\" -D\"[Process Controller]\" $PROCESS_CONTROLLER_JAVA_OPTS \
\"-Dorg.jboss.boot.log.file=$JBOSS_LOG_DIR/process-controller.log\" \
\"-Dlogging.configuration=file:$JBOSS_CONFIG_DIR/logging.properties\" \
-jar \"$JBOSS_HOME/jboss-modules.jar\" \
-mp \"${JBOSS_MODULEPATH}\" \
org.jboss.as.process-controller \
-jboss-home \"$JBOSS_HOME\" \
-jvm \"$JAVA_FROM_JVM\" \
-mp \"${JBOSS_MODULEPATH}\" \
-- \
\"-Dorg.jboss.boot.log.file=$JBOSS_LOG_DIR/host-controller.log\" \
\"-Dlogging.configuration=file:$JBOSS_CONFIG_DIR/logging.properties\" \
$HOST_CONTROLLER_JAVA_OPTS \
-- \
-default-jvm \"$JAVA_FROM_JVM\" \
'"$@"'
'jboss-modules.jar' is still used for bootstrap:
-jar \"$JBOSS_HOME/jboss-modules.jar\" \Compared with the standalone mode, the entry point is no longer org.jboss.as.standalone; instead, it becomes process-contoller:
org.jboss.as.process-controller
There is also a process called host-controller:
-Dorg.jboss.boot.log.file=$JBOSS_LOG_DIR/host-controller.log
The following figure shows the relationship of these processes when EAP6 is running in the domain mode:
As in the domain mode, a lightweight Process Controller is started first, and then it spawns a Host Controller process that will control multiple server processes. This is because in the domain mode it allows multiple server instances to run at the same time, and each server will have its own JVM process.
As we have seen previously, when EAP6 is running in the domain mode, multiple severs can run at the same time. In addition, these servers can belong to different server groups. The servers that belong to the same group will share the deployment and configuration information.
For example, we have a server group called the main-server-group
, and in this group, we have two servers called server-
one and server-two
. If we deploy a project called cluster-demo.war in the main-server-group, then it will be deployed into both the servers at the same time. And if we change some settings in this group, the settings of these two servers will all get synced:
In the previous example the two servers of the same group are in the same machine and the same EAP6 instance. But actually they can exist in different EAP6 servers, and the servers in the same group can be synced across the network.
Unlike the standalone mode, the domain mode uses two configuration files:
domain.xmlhost.xml
These configuration files are in the location domain/configuration/. Now let's have a look at dom
ain.xml first.
The structure of the domain.xml file and its difference with standalone.xml are shown in the following screenshot:
If we compare its structure with the standalone mode, we can see the differences. Firstly there are three sections in plural form:
profiles
interfaces
socket-binding-groups
The reason for this difference is easy to guess. In the domain mode, there are multiple servers running in different server groups, and EAP6 supports each server group to have its own set of settings. So, different profiles, interfaces, and socket-binding-groups will be needed.
In addition, we can see a new section called server-groups. Here is its default setting in domain.xml:
<server-groups> <server-group name="main-server-group" profile="full"> <socket-binding-group ref="full-sockets"/> </server-group> <server-group name="other-server-group" profile="full-ha"> <socket-binding-group ref="full-ha-sockets"/> </server-group> </server-groups>
The previous settings are shown in the following figure:
In this way, different server groups are bound to different settings.
Now let's check host.xml. The following screenshot shows its structure:
The host.xml file is the setting file for the host controller. It has some parts similar to standalone.xml such as management and interfaces. Their purposes are also the same. Now let's see the domain-controller section.
The domain-controller section defines which host is used as the domain controller. The domain controller is actually a host controller, but it acts as the manager of the domain. The default domain-controller is set to local, which means EAP6 will use its host controller as its domain controller by default.
We can also define a remote host controller as the domain controller. Then multiple EAP6 could connect to the same domain controller and accept its management. Now let's see the servers section.
The servers section is shown in the following screenshot:
In the domain mode, a host controller can manage several servers at the same time, and each server has their own name and belongs to a server group; these servers are bound to different sockets to avoid conflicts.
The auto-start option checks whether to start this server during the EAP6 startup. We may choose which server to start during the EAP6 startup by this option.
The port-offset option is used to bind different servers into different ports to avoid conflict. Let's see the default configuration in host.xml:
<servers>
<server name="server-one" group="main-server-group">
<socket-bindings port-offset="0"/>
</server>
<server name="server-two" group="main-server-group">
<socket-bindings port-offset="150"/>
</server>
<server name="server-three" group="other-server-group">
<socket-bindings port-offset="250"/>
</server>
</servers>The following is the deployment diagram that shows the relationship between the previously discussed servers and server groups:
Here are the server group settings in domain.xml:
<server-groups>
<server-group name="main-server-group" profile="full">
<socket-binding-group ref="full-sockets"/>
</server-group>
<server-group name="other-server-group" profile="full-ha">
<socket-binding-group ref="full-ha-sockets"/>
</server-group>
</server-groups>We can see that the main-server-group is bound to full-sockets, and the other-server-group is bound to full-ha-sockets. These two sockets are defined as follows:
<socket-binding-group name="full-sockets" default-interface="public"> <socket-binding name="http" port="8080"/> </socket-binding-group> <socket-binding-group name="full-ha-sockets" default-interface="public"> <socket-binding name="http" port="8080"/> </socket-binding-group>
The full-sockets binds to the HTTP port 8080, and port-offset is 0. So the web port used by server-one is 8080; for server-two, because its port-offset is 150, its web port is 8080 + 150 = 8230. Similarly, the HTTP port used by server-three is 8080 + 250 = 8330.
Now let's set
auto-start for all three servers to true so that they will be started during the EAP6 startup:
<servers> <server name="server-one" group="main-server-group" auto-start="true">...</server> <server name="server-two" group="main-server-group" auto-start="true">...</server> <server name="server-three-master" group="other-server-group" auto-start="true">...</server> </servers>
Now let's start EAP6 in the domain mode by calling domain.sh. After EAP6 starts, let's try to access 8080, 8230, and 8330 with telnet commands:
$ telnet localhost 8080 Trying localhost... Connected to localhost. $ telnet localhost 8230 Trying localhost... Connected to localhost. $ telnet localhost 8330 Trying localhost... Connected to localhost.
We can see all the servers are listening for connections now.
JBoss EAP6 has provided the schema documents in docs/schema. Each schema has defined a namespace used by the EAP6 configuration file. For example, we can check the beginning of standalone.xml and see the xml namespace it's using:
<?xml version='1.0' encoding='UTF-8'?> <server xmlns="urn:jboss:domain:1.4"> ...
We can see that the namespace used is urn:jboss:domain:1.4. Let's find the defined namespace in the docs/schema directory by using the grep command:
$ grep -rl 'urn:jboss:domain:1.4' * jboss-as-config_1_4.xsd
We can see that jboss-as-config_1_4.xsd contains the definition of the xml namespace we are searching for. Now we can check the definitions for each element in this namespace. For example, if we want to understand the meaning of the server section in standalone.xml, we can check its definition in the xsd file:
<xs:element name="server">
<xs:annotation>
<xs:documentation>
Root element for a document specifying the configuration
of a single "standalone" server that does not operate
as part of a domain...
</xs:documentation>
</xs:annotation>
...
</xs:element>As we have seen in the previous code snippet, the xsd schemas are very useful documents. They can help us to understand the meaning of the elements in configuration files.
In this chapter, we have learned the basic concepts of high availability, and we have learned how to install JBoss EAP6 and run it in different modes. We also learned about the two running modes of EAP6. In the next chapter, we will learn to use the EAP6 management console, and we'll use it to deploy projects into EAP6.
