WildFly Managed Domain in Containers: Automatic Micro Clustering and Scaling

Nowadays it’s easy to get up and running WildFly standalone server in a container but what if you need to enable clustering in Managed Domain mode which is one of the key features of Java EE in general. That is not so easy task. Some people claim it’s nearly impossible in the cloud-native world because Java EE clustering was designed before the era of the container. The old question at the official developers portal is still not answered with any adequate instruction that just proves the presence of the issue.

As a result, developers go with standalone nodes as the only available production-ready option in containers integrating clustering and management features from the 3rd party solutions. Or they just keep running applications in VMs facing complexity that makes migration nearly impossible.

But what developers should do if they are looking for a solution to migrate from VMs to containers already existing and nicely working Java EE clusters in managed domain mode?

Till this time there were very few examples (e.g. for GlassFish and WebLogic) of how to run and scale Java application servers in managed domain mode within containers correctly. In most cases, lack of knowledge or even the absence of a working solution for the domain mode in containers leads to the loss of integrated Java EE clustering features that just become obsolete.

But managed domain mode is still awesome! A vast portion of mission-critical and large-scale applications such as banking and billing are still running on Java EE in VMs. Integrated Java EE clustering provides functionality that people are interested in, including high-availability and automated deployment among distributed Java application servers regardless of the underlying infrastructure, and, of course, Admin Panel to manage your cluster using a nice UI.

To get familiar with the benefits of natively integrated clustering technology please refer to a good article “Under the Hood of J2EE Clustering”. Merging this rich functionality with ready-to-go containers provides a huge benefit by saving time and efforts of the team, and enables fast iterations as the majority of developers do not deal with containers or VMs if the environment setup is fully automated.

When What and Why Managed Domain Mode?

Every WildFly standalone server has its own admin console and is managed independently. At the same time, WildFly multiple instances running in the domain mode share the same management interface called a domain controller. So you can issue commands and deploy applications to all running WildFly servers from one place. The official documentation suggests considering the domain mode for:

• Multi-server production environments with the ability to use centralized management capabilities that a managed domain provides.
• For advanced development scenarios, i.e. those involving interaction between multiple WildFly instances.

We can easily run one big service or several small interrelated services per cluster running in managed domain mode. Deployment to such a cluster is automated so applications running in VMs can be lifted and shifted to containers without re-architecturing. It provides a very convenient way for replicating on-premise applications in the cloud while avoiding costly and time-consuming re-design. As a result, the legacy applications can benefit from the cost-efficiency of cloud-native features such as elastic compute and auto-scaling.

Complexify of Managed Domain Topology

Let’s have a look at the topology of the WildFly cluster in managed domain mode, which is illustrated in the official documentation. The illustration below provides a sense of the complexity of managed domain architecture. This scheme is considered as a classical Java EE topology in VMs or the so-called “legacy dragon” which should be tamed and decomposed properly into containers.

We adjusted this illustration for a little bit better view of the topology, as well as to show additional “hidden” Java processes inside each VM or bare metal host.  This will help us during further decomposition.

• Worker Server is a JVM process where the enterprise Java EE applications are deployed and handle requests.
• Host Controller is a JVM process that is responsible for configuring Worker Servers, and synchronization between the Servers and Domain Controller.
• Process Controller is a JVM process that is responsible for a lifecycle (start/stop/restart) of  Worker Servers. It is absent in the original scheme but it is important to take into account while decomposition.
• Domain Controller is a type of Host Controller that is designated to act as master admin server (or orchestrator) at the cluster running in managed domain mode and provides a single pane for managing distributed Worker Servers.

Running Multiple Processes in an Application Container

As we can see from the illustration above, the VM1 contains 2 Java processes inside: Process Controller and Domain Controller. And every other VM contains at least 3 Java processes (or more, depending on how many server instances you want to run inside every host): Process Controller, Host Controllers and Worker Server(s).

That’s not easy to run it in containers. Such topology conflicts with the anti-pattern in the application containers world. The official Docker documentation warns us about running multiple Java processes inside the same container:

“It’s ok to have multiple processes, but to get the most benefit out of Docker, avoid one container being responsible for multiple aspects of your overall application.”

So users feel confused when they get the message to perform this “seems-unreliable” action. Take a look at the quite recent conversation.

Running Multiple Processes in a System Container

However, the situation is not so bad. If configured properly, the domain mode works perfectly inside system containers. They can handle as many processes as required inside one container. This kind of containers drastically simplifies migration from heavy VMs to a much lightweight virtualization. And there are two well-known options on the market LXD and OpenVZ. Moreover, system containers and application containers are complementary, the combination of both provides VM characteristics for dockerized applications.

An interesting feedback about different use cases from Stéphane Graber, LXD Technical Lead.

Cloudjiffy PaaS implemented support of system containers at early days of 2011 and can confirm that many customers are happy with running multiple processes inside the same container in production when it’s required.

Moreover, system containers provide a better resource and security isolation compared to the application containers, so cloud providers can safely host applications of different projects on the same infrastructure reducing the cost of ownership and complexity of management. As a side effect, system containers are starting up a little bit slower compared to the application containers, but they are still much slimmer and faster than VMs.

Decomposition and Building Modified Topology

We are ready to start our decomposition journey. The first rule is in the spirit of microservices – it is always better to put only one Worker Server per one container. Also, we create only one server group per domain for all containers inside the cluster. Such simple adjustments will give tremendous and desired flexibility for scaling each Worker Server vertically, gaining resource usage efficiency, and scaling the group of containers horizontally by adding new instances on demand.

Please note that each container for handling incoming requests runs 3 Java processes: Worker Server (WS), Host Controller (HC) and Process Controller (PC). And admin container that manages the cluster runs 2 Java processes: Domain Controller (DC) and Process Controller (PC).

WildFly Managed Domain in Cloudjiffy

In order to facilitate the migration of legacy Java EE applications from VMs to containers, we created a special embedded Auto-Clustering for WildFly that is enabled by default for new instances.

The main advantage of this solution is an automatic interconnection of multiple application servers upon the environment topology change, which implements the commonly used clustering configuration in managed domain mode.

Below you’ll see how standalone WildFly transforms into the cluster by means of a simple horizontal scaling with no manual configurations required. Also, we’ll describe infrastructure topology specifics and the way to get the appropriate development and production environments up and running inside Cloudjiffy PaaS.

Why use it on CloudJiffy?

• Easy to manage.
• One-Click Installation.
• Charges based purely on consumption (Pay As You Consume pricing) This helps you save cost.
• Real-time scaling with an increase in users.
• Data replication and backup solution to keep your data safe.
• Highly secure infrastructure.
• Inbuilt CDN to cater to a worldwide audience.

Environment Creation

Through the Cloudjiffy web interface a “WildFly Managed Domain” instance can be automatically deployed in a few clicks.

STEPS 

Step 1: Login to CloudJiffy.
    Go to https://app.cloudjiffy.com/

    Login using your credentials.

Step 2:Click on “Marketplace” to view the list of applications that can be installed automatically.

Step 3: A new window displaying the Apps will open, Select the “WildFly” instance and click on “Install”.

Step 4:  In the opened installation dialog box:

• type Environment name to be used as its internal hostname
• optionally, specify environment Display Name (so-called alias, for being shown within dashboard and SSH terminal)
• select an environment Region (if multiple ones are available)

Click Install and wait a bit to be shown a notification message on this process completion. In a minute, you’ll see a popup frame informing you about the successful package installation.

Now you can open your application in a web browser.

Click the Open in Browser button or you can also browse from your environment.

Cloning Cluster in Domain Mode

When releasing new application version or just applying some essential adjustments, it’s a good practice to check how the newly implemented changes could affect the service work. The Cloudjiffy PaaS allows you to accomplish such testing ‘on-fly’ (i.e. without service downtime and implicitly for your customers) with the Clone Environment option.

A cloned environment is a ready-to-work cluster copy with all the required modifications already applied. The newly provisioned Domain Controller node operates with the appropriate cloned Workers, which are already listed within its admin panel. And the application from the original environment is deployed to the cloned one. Thus, the only thing that remains is to recheck your application’s code and custom server configurations for the hardcoded IPs/domains and fix them accordingly (if there are any issues).  

This way, you can apply the implied changes to your environment copy without affecting the actual production. To increase the high availability of the system, Cloudjiffy uses several synchronized Load-Balancers, placed at different nodes, for handling requests simultaneously. All of them work with single data storage, which makes them fully interchangeable in case any issue occurs at one of the instances.

Don’t have a CloudJiffy account? Visit https://cloudjiffy.com and click on Free Signup for a free 14 days trial.