The JBoss EAP6 and AS7 supports different approaches to mange server configurations. One approach is the command line interface (CLI). It is based on the De-Typed Management API and allows the execution of management operations. The CLI has support for CLI scripts with management and configuration operations that can be executed in a non-interactive mode.
In this post we want to introduce two ways of using CLI scripts to manage server configurations.
As announced this is the last post of our series about clustering of the Redhat EAP 6 and JBoss AS 7. The other posts of this series were
This post will dig deeper into the clustering mechanisms of the EAP 6 and JBoss AS 7. We will show different solutions to multicast problems you will get in most cloud networks as well as some other networks. Infinispan uses JGroups to do its cluster communication. Cluster communication here means multiple things: finding other cluster nodes, providing a reliable transfer, implementing multicast communication even if there is no IP multicast available, identifying dead cluster nodes and a little bit more. In fact JGroups is able to do a lot more but Infinispan does not need all of the opportunities JGroups offers. The upcoming HornetQ version 2.3 which will be included in the EAP 6.1 will use JGroups for server discovery too. This post will explain the basic principles of JGroups and how to configure it in different network setups, especially most cloud networks.
In the recent posts of this series we talked about many different aspects of clustering for the JBoss AS 7 and its quality assured version EAP 6, such as:
Until now, there is one important thing we have not covered yet: clustering of the messaging subsystem. The EAP 6 as well as the AS 7 uses HornetQ as default messaging provider. In this post we want to give an overview about the clustering abilities of HornetQ and explain how to use the various clustering features in combination with the EAP 6 or respectively the JBoss AS 7. We implemented a simple JMS client application to demonstrate the HornetQ clustering abilities.
In a software development process, there are usually multiple environments, such as development, test and production, etc. The development team usually provides the QA users a test version before acceptance and production, as illustrated below.
If, however, the application contains assumptions about the environment, this chain is broken. Therefore it is good practice, for the deployment to make no assumptions about the target environment. A good way to achieve this is that the application servers provide the environment specific configurations of the application, such as datasource configuration or integration of other Enterprise Information Systems (EIS). But this is often not so easy.
In the recent posts of this series about the clustering capabilities of the JBoss EAP6 and the AS7, we covered the basic concepts, managing cluster nodes in domain mode and scalable HA cluster topologies. This post will be about clustering capabilities for remote EJB clients. We will explain how to cluster EJB components and invoke them from a standalone remote client with client-side failover and load balancing.
In a recent blog-post Clustering in JBoss AS7/EAP 6 we showed how basic clustering in the new EAP 6 and JBoss AS 7 can be used. The EAP 6 is basically an AS 7 with official RedHat-support. Our cluster we described in that post was small and simple. This post will cover much more complex cluster structures, how to build them and how we can utilize the new domain-mode for our clusters. There are multiple ways to build and manage bigger JBoss cluster environments. We will describe two ways to do so: One using separating techniques also applicable to older JBoss versions and the other way using an Infinispan feature called distribution.
The main challenge when building a cluster is to make it both highly available and scalable.
Availability for a cluster means: If one node fails, all the sessions on that node will be seamlessly served by another node. This can be achieved through session-replication. Session-replication is preconfigured and enabled in the ha profile in the domain.xml. Flat replication means that all sessions are copied to all other nodes: If you have got four nodes with 1GB memory for each of them, your cluster can only use 1GB of memory because basically all nodes store copies from each other. I. e. your cluster will not have 4*1GB=4GB memory. If you would add more nodes to this cluster you would not get more memory, you will even lose some memory due to overhead for replication. But you will get more availability and more important more network traffic due to replication overhead (all changes need to be redistributed to all other nodes). Let us call this cluster topology full-replication.
Continue reading
The first post of this series focused on the basic concepts behind clustering JBoss AS 7 and EAP 6. We explained how to enable cluster capabilities for a simple Java EE application and setup a basic cluster environment in the standalone operation mode. In this post we will now explain the domain mode and how to manage a cluster environment in managed domains.
A managed domain spans over multiple hosts with centralized administration and management policies. Each host that runs in domain mode can contain several server instances that belong to one domain. The domain mode is one of two possible operating modes of the EAP 6 respectively the JBoss AS 7. The other mode is the standalone mode. A JBoss application server, which operates in the standalone mode, is an independent process. This mode is pretty similar to the previous versions of the JBoss application server. The different operating modes have no influence to the capabilities of the application server, but rather how to manage one or multiple servers. So, the domain mode is completely independent from clustering. But it provides many useful features for managing clustered environments such as handling of deployments for multiple instances. For example the JBoss AS 7 running in standalone mode does not support any more the previous farming deployment capabilities. Now, this can be done with the domain mode capabilities and of course there are more features such as starting and stopping servers from one single console that makes it easier to handle clustered environments.
The ability to combine different servers to a cluster that hides its internal servers from the clients and offers a virtual platform for an application is important for enterprise applications. It can be used to provide
Usually high scalability limits high availability and vice versa, but it is also possible to get both. The JBoss application server can be configured to support both features.
This post is the first one of a series about clustering with the JBoss AS 7. Here, we focus on the basic concepts behind JBoss AS 7 clustering and show you how to setup a basic clustered environment with a simple Java EE application.
In the series, we concentrate on the JBoss AS 7 respectively the EAP 6, which is the Red Hat-supported version of the JBoss application server. Future posts will be about particular subsystems of the JBoss AS, such as HornetQ or Infinispan.
You must be logged in to post a comment.