WildFly Auto-Clustering in Managed Domain Mode and Scaling Inside Containers

These days, setting up a WildFly standalone server in a container is quite straightforward. However, enabling clustering in Managed Domain mode—a key feature of Jakarta EE —is a different story.

This task is challenging, and some argue it’s nearly impossible in a cloud-native environment because Jakarta EE clustering was designed before the container era. An unanswered question on the official developers’ portal highlights this issue.

As a result, developers often resort to using standalone nodes as the only viable production-ready option in containers, incorporating clustering and management features from third-party solutions. Alternatively, they continue running applications in VMs, facing complexities that hinder migration.

So, what should developers do if they want to migrate existing, well-functioning Jakarta EE clusters in Managed Domain mode from VMs to containers?

Until now, there have been very few examples such as for GlassFish and demonstrating how to correctly run and scale Java application servers in Managed Domain mode within containers. This lack of knowledge or solutions often leads to the loss of Jakarta EE clustering features, rendering them obsolete.

Nevertheless, the Managed Domain mode remains impressive! Many mission-critical and large-scale applications, like those in banking and billing, still run on Jakarta EE in VMs.

Integrated Jakarta EE clustering offers desirable functionality, including high availability and automated deployment across distributed Java application servers, regardless of the underlying infrastructure. Furthermore, the Admin Panel offers a simple interface for managing your cluster effectively.

To understand the advantages of natively integrated clustering technology, check out the informative article Under the Hood of J2EE Clustering. Combining this robust functionality with pre-configured containers offers significant time and effort savings for the team. It allows for quick iterations since most developers can avoid dealing with containers or VMs, thanks to a fully automated environment setup.

When, What, and Why Managed Domain Mode?

In WildFly, each standalone server operates with its admin console, giving it independent management. Conversely, in the domain mode, where multiple WildFly instances run, they share a common management interface known as the domain controller. This setup allows you to execute commands and deploy applications across all running servers from a single location. According to the official documentation, the domain mode is recommended for:

1. Multi-server production setups, enabling centralized management through the managed domain’s capabilities.
2. Advanced development scenarios involving interactions between multiple WildFly instances.

Using the managed domain mode, we can efficiently run either a large service or several interconnected smaller services within a cluster. Deployment to such clusters is automated, facilitating the migration of applications from VMs to containers without the need for extensive re-architecture.

This method uses cloud-native characteristics such as elastic computing and auto-scaling to give a viable solution to duplicate on-premise applications in the cloud. As a result, older applications can benefit from the cost savings given by cloud-native capabilities.

Complexity of Managed Domain Topology

Take a peek at the layout of the WildFly cluster operating in managed domain mode, as showcased in the official docs. The diagram below paints a picture of how intricate the managed domain setup can get. It’s like the classic Jakarta EE setup running on virtual machines, often referred to as the “legacy dragon” that needs to be handled delicately and broken down into containers for better management.

We tweaked the illustration to give a clearer view of the setup and also to reveal some extra Java processes tucked away within each virtual machine or bare metal host. This modification will be useful as we continue to break things down.

• The Worker Server, essentially a Java Virtual Machine (JVM) process, is where the enterprise Jakarta EE applications are deployed and handle requests.
• Meanwhile, the Host Controller, another JVM process, takes charge of configuring Worker Servers and ensuring synchronization between these servers and the Domain Controller.
• Now, the Process Controller, also a JVM process, plays a crucial role in managing the lifecycle of Worker Servers, handling tasks like starting, stopping, and restarting them. While it might not have been initially part of the plan, it’s vital to consider its role in decomposition.
• Lastly, the Domain Controller, a specific type of Host Controller, acts as the master admin server or orchestrator in a cluster running in managed domain mode. It serves as a centralized hub for managing distributed Worker Servers, offering a unified interface for administrators.

Running Multiple Processes in an Application Container

The illustration shows that VM1 contains two Java processes: the Process Controller and the Domain Controller. In contrast, each additional VM hosts at least three Java processes, which can increase depending on the number of server instances you decide to run. These processes include the Process Controller, Host Controllers, and Worker Servers.

Running this setup in containers is challenging because it conflicts with best practices in the application container world. The official Docker documentation advises against having a single container manage multiple aspects of an application:

While it’s fine to use multiple processes, to fully leverage Docker’s benefits, ensure each container handles a single aspect of your application rather than multiple tasks.

This advice often confuses users who are hesitant to follow what appears to be unreliable guidance. Past negative experiences have understandably led to a lack of trust in this approach.

Running Multiple Processes in a System Container

The situation isn’t as dire as it may seem. With the right configuration, domain mode operates seamlessly within system containers, efficiently managing numerous processes within a single container. This greatly facilitates the transition from resource-intensive virtual machines to more efficient virtualization methods. Notably, LXD and OpenVZ are two prominent options available. Additionally, system containers and application containers complement each other, together offering VM-like features for dockerized applications.

Furthermore, system containers offer superior resource and security isolation compared to application containers. This allows cloud providers to securely host applications from various projects on the same infrastructure, thereby reducing costs and simplifying management. Although system containers take slightly longer to start compared to application containers

Decomposition and Building Modified Topology

We’re set to begin our decomposition journey. The first principle, inspired by microservices, is to deploy only one Worker Server per container. Additionally, we establish a single server group per domain to encompass all containers within the cluster.

These straightforward tweaks provide significant flexibility: they allow each Worker Server to be scaled vertically for better resource efficiency and enable the entire container group to scale horizontally by adding new instances as needed.

Each container that handles incoming requests operates with three Java processes: the Worker Server (WS), the Host Controller (HC), and the Process Controller (PC). Additionally, the administrative container responsible for managing the cluster runs two Java processes: the Domain Controller (DC) and the Process Controller (PC).

WildFly Managed Domain in AccuWeb.Cloud

To simplify moving legacy Jakarta EE applications from virtual machines to containers, we developed a unique embedded Auto-Clustering mode for WildFly. This feature can be activated for new instances.

The key benefit of this solution is that it automatically connects multiple application servers when the environment’s topology changes, mimicking the commonly used clustering configuration in managed domain mode.

In the following sections, you’ll see how standalone WildFly becomes a cluster using the Auto-Clustering feature, allowing for straightforward horizontal scaling without any manual configurations. We’ll also explain the specifics of infrastructure topology and how to set up suitable development and production environments within AccuWeb.Cloud PaaS.

Create Standalone WildFly

Using AccuWeb.Cloud, you can easily construct the necessary topology with the help of an intuitive wizard. Simply follow these steps:

Step 1. Begin by creating a new environment

• Select the appropriate version of WildFly
• Configure the vertical scaling limits
• Rename the environment if necessary (e.g., wildfly).

You will get an email confirming the creation of your environment, along with the login details for the Admin Panel.

Step 2. You are now ready to deploy the application to the newly provisioned standalone server.

In the Deployment Manager, click on the Deploy to… button.

You can either set the Context as needed or simply stick with the default ROOT value.

Be sure your app is good to go by clicking on “Open in browser” next to the environment you’ve set up.

When you access your container using the web SSH client that’s included, you’ll notice that there’s just one active process for the Standalone server.

Get Clustered WildFly with Managed Domain Mode

In WildFly, clustering with domain mode gets set up smoothly thanks to the Auto-Clustering feature. Once you’ve got it turned on, you can expand your server setup either by doing it manually or letting it happen automatically.

For manual scaling, you can bring in new servers using a wizard during setup or by adjusting the topology later on.

Simply navigate to the application server layer on the left-side environment panel. Then, switch on Auto-Clustering mode and include additional nodes by clicking the “+” sign within the Horizontal Scaling section.

For automatic scaling, you can adjust the number of servers automatically by configuring scaling triggers that respond to resource usage. Just head to Settings > Auto Horizontal Scaling to set it up.

• When you switch your application from standalone to domain mode initially, it’ll be offline for around a minute.
• However, any future adjustments to scale won’t disrupt your service.
• If you activate Auto-Clustering and begin with two instances simultaneously, the domain mode will be set up from scratch, ensuring seamless scaling without any downtime.

Once the scaling process finishes, whether done manually or automatically, all WildFly instances will link up with the cluster, operating under the WildFly Managed Domain mode.

Automatically, the Domain Controller and Load Balancer are incorporated as necessary parts of the cluster setup.

With this scaling, any application already deployed is automatically redeployed across the other WildFly instances within the cluster.
Moreover, configurations like the database connection pool, along with any other custom settings previously configured through the

WildFly admin console, are seamlessly replicated throughout the application server layer.

You can see the transformation of WildFly’s structure from a standalone mode to a managed domain cluster.:

In standalone mode, a worker node only ran a single process. However, now it runs three distinct processes:

• Server:worker
• Process Controller
• Host Controller

The Domain Controller node operates two distinct processes:

• Process Controller
• Host Controller

Additionally, any changes to the topology are synchronized and displayed in the WildFly Admin Panel.

This approach provides you with a WildFly cluster that’s ready for immediate use, allowing you to easily scale it up or down as needed. This flexibility makes it highly efficient and cost-effective for hosting your applications.

Application Availability among Workers

During the transition to a cluster, the application originally deployed on the standalone server is redistributed to all server instances. To verify this, you can click “Open in browser” on each Worker.

You can ensure that the cluster offers high availability by pressing the Restart node button for one or two nodes, then attempting to access your application using the Open in browser option for the entire cluster.

The application will run smoothly without any interruptions.

Cloning Cluster in Domain Mode

When launching a new version of an application or making important updates, it’s wise to assess the impact of these changes on the service. AccuWeb.Cloud PaaS offers a convenient way to perform this testing seamlessly, without causing downtime or disrupting your customers, using the Clone Environment feature.

In simple terms, a cloned environment is like a duplicate of your setup that’s all set to go. It’s got everything tweaked just how you need it. Once you’ve set up a new Domain Controller node, it pairs up with the cloned Workers that are already set up in its control panel.

Then, you just transfer your application from the original environment to the cloned one. After that, it’s just a matter of double-checking your application’s code and server configurations to make sure any hardwired IP addresses or domains are adjusted if needed.

In this manner, you can implement the suggested adjustments to your environment replica without disrupting the live system. To increase system reliability, AccuWeb.Cloud teams have multiple synchronized load balancers distributed across various nodes to manage requests concurrently.

These load balancers operate with a unified data storage setup, allowing seamless substitution if any problems arise with one of the instances.

Conclusion

This instruction demonstrates that managed domain mode and container technology may be used to achieve the desired results without completely rebuilding the application architecture.

It is not at all difficult to migrate old projects from virtual machines (VMs) to micro-clusters using system containers. It offers a “rich taste” of efficiency and flexibility to boost competitive advantage. Simply give it a go! With AccuWeb.Cloud PaaS, you may build your cluster at any decentralized service provider across the globe.

Jilesh Patadiya

Jilesh Patadiya, the visionary Founder and Chief Technology Officer (CTO) behind AccuWeb.Cloud. Founder & CTO at AccuWebHosting.com. He shares his web hosting insights on the AccuWeb.Cloud blog. He mostly writes on the latest web hosting trends, WordPress, storage technologies, and Windows and Linux hosting platforms.