Chapter 10. Using JBoss EAP high availability in Microsoft Azure Microsoft Azure does not support JGroups discovery protocols that are based on UDP multicast. Although you may use other JGroups discovery protocols (such as a static configuration ( TCPPING ), a shared database ( JDBC_PING ), shared file system-based ping ( FILE_PING ), or TCPGOSSIP ), we strongly recommend that you use the shared file discovery protocol specifically developed for Azure: AZURE_PING . 10.1. AZURE_PING configuration for JBoss EAP high availability This section describes configuring your JBoss EAP cluster to use the AZURE_PING JGroups discovery protocol. Ensure that you meet the prerequisites when creating your virtual machines . AZURE_PING uses a common blob container in a Microsoft Azure storage account. If you do not already have a blob container that AZURE_PING can use, create one that your virtual machines can access. After creating your blob container, you will need the following information to configure AZURE_PING: storage_account_name : the name of the Microsoft Azure storage account that contains your blob container. storage_access_key : the secret access key of the storage account. container : the name of the blob container to use for PING data. Important The following instructions configure AZURE_PING using a UDP JGroups stack. If you will be configuring JBoss EAP messaging high availability in Azure , you must configure AZURE_PING in a TCP JGroups stack instead. To configure JBoss EAP to use AZURE_PING as the JGroups discovery protocol, you can either use a preconfigured example JBoss EAP configuration file , or modify an existing configuration . 10.2. Use of the example configuration file to configure high availability JBoss EAP includes example configuration files for configuring clustering of standalone servers in Microsoft Azure. These files are located in EAP_HOME/docs/examples/configs/ and are standalone-azure-ha.xml and standalone-azure-full-ha.xml . Note See the JBoss EAP Configuration Guide for an explanation of the differences between the server profiles. These sample configuration files are preconfigured for using clustering in Microsoft Azure, and all that is needed is to specify the values for your Azure storage account and blob container. Copy your desired example configuration file to EAP_HOME/standalone/configuration/ . 10.3. Modifying an existing server high availability configuration If you are modifying an existing JBoss EAP high availability configuration, the following changes to the jgroups subsystem are required. Procedure Launch the management CLI and embed a server to make offline changes to your chosen configuration file. For example: By default, JGroups uses the UDP stack. If you were using another stack, change back to using the UDP stack: Execute the following batch of commands to remove the existing UDP stack and insert a new UDP stack configured for Microsoft Azure: Important The encoding for storage_access_key used in the following command must be Base64. Note If you want to store the values of your Microsoft Azure storage account and blob container in your configuration file, replace the system property references in the above configuration with the values from your Azure environment. In the following command, examples for starting JBoss EAP, the system properties are used. The stack XML in your configuration file should look like the following: <stack name="udp"> <transport type="UDP" socket-binding="jgroups-udp"/> <protocol type="RED"/> <protocol type="azure.AZURE_PING"> <property name="storage_account_name">USD{jboss.jgroups.azure_ping.storage_account_name}</property> <property name="storage_access_key">USD{jboss.jgroups.azure_ping.storage_access_key}</property> <property name="container">USD{jboss.jgroups.azure_ping.container}</property> </protocol> <protocol type="MERGE3"/> <socket-protocol type="FD_SOCK2" socket-binding="jgroups-udp-fd"/> <protocol type="FD_ALL3"/> <protocol type="VERIFY_SUSPECT2"/> <protocol type="pbcast.NAKACK2"/> <protocol type="UNICAST3"/> <protocol type="pbcast.STABLE"/> <protocol type="pbcast.GMS"/> <protocol type="UFC"/> <protocol type="MFC"/> <protocol type="FRAG4"/> </stack> Stop the embedded server and exit the management CLI: 10.4. Starting JBoss EAP high availability in Microsoft Azure To start JBoss EAP using high availability in Microsoft Azure, you must: Use a configuration file that has been configured with the AZURE_PING discovery protocol and specify the required values of your Microsoft Azure storage account and blob container. Bind the private interface to the Microsoft Azure internal IP address that is used for clustering traffic. You can do this at startup, as shown below, or as a set configuration shown in the JBoss EAP Configuration Guide . Warning For security reasons, you must ensure that you do not expose clustering traffic to unintended networks. You can do this by restricting the endpoints to your Microsoft Azure virtual network or by creating a dedicated virtual network and dedicated virtual machine NICs for clustering traffic. Procedure Start your JBoss EAP high availability instance using the following command. If you stored your Microsoft Azure storage account and blob container values in your configuration file, you can omit the -Djboss.jgroups.azure_ping system property definitions. For example: Note As JBoss EAP subsystems only start when needed, you must deploy a distributable application to your JBoss EAP servers to start the high availability JBoss EAP subsystems. After you start a second JBoss EAP instance in a cluster, you should see logs similar to the following in the console log of the first server in the cluster: 10.5. Clean stale discovery files in your blob container If a JBoss EAP cluster that uses AZURE_PING is shut down abnormally, for example, using kill -9 to end the JBoss EAP process, some stale discovery files may be left in your blob container. These files are usually cleaned up in a graceful cluster shutdown, but if left there from an abnormal shutdown, it may impact startup performance of cluster members attempting to contact nodes that are no longer online. If this is a problem for you, you can set the following configuration to make the cluster coordinator remove and refresh all discovery files whenever the cluster view changes. Note Alternatively, if cleaning your container on each view change is not ideal, you can reduce the number of join attempts for a node attempting to join a cluster. The default number of join attempts is 10 . For example, to set the number of join attempts to 3 : The stale discovery files will still be present, but a node attempting to join a cluster will not spend as much time attempting to contact nodes that are no longer online. Revised on 2025-03-11 14:21:53 UTC

Commands:
EAP_HOME/bin/jboss-cli.sh [disconnected /] embed-server --server-config=standalone-ha.xml
[standalone@embedded /] /subsystem=jgroups/channel=ee:write-attribute(name=stack,value=udp)
batch /subsystem=jgroups/stack=udp:remove /subsystem=jgroups/stack=udp:add() /subsystem=jgroups/stack=udp/transport=UDP:add(socket-binding=jgroups-udp,properties={ip_mcast=false}) /subsystem=jgroups/stack=udp/protocol=azure.AZURE_PING:add(properties={storage_account_name="USD{jboss.jgroups.azure_ping.storage_account_name}", storage_access_key="USD{jboss.jgroups.azure_ping.storage_access_key}", container="USD{jboss.jgroups.azure_ping.container}"}) /subsystem=jgroups/stack=udp/protocol=MERGE3:add /subsystem=jgroups/stack=udp/protocol=FD_SOCK2:add(socket-binding=jgroups-udp-fd) /subsystem=jgroups/stack=udp/protocol=FD_ALL3:add /subsystem=jgroups/stack=udp/protocol=VERIFY_SUSPECT2:add /subsystem=jgroups/stack=udp/protocol=pbcast.NAKACK2:add(properties={use_mcast_xmit=false,use_mcast_xmit_req=false}) /subsystem=jgroups/stack=udp/protocol=UNICAST3:add /subsystem=jgroups/stack=udp/protocol=pbcast.STABLE:add /subsystem=jgroups/stack=udp/protocol=pbcast.GMS:add /subsystem=jgroups/stack=udp/protocol=UFC:add /subsystem=jgroups/stack=udp/protocol=MFC:add /subsystem=jgroups/stack=udp/protocol=FRAG4:add run-batch
<stack name="udp"> <transport type="UDP" socket-binding="jgroups-udp"/> <protocol type="RED"/> <protocol type="azure.AZURE_PING"> <property name="storage_account_name">USD{jboss.jgroups.azure_ping.storage_account_name}</property> <property name="storage_access_key">USD{jboss.jgroups.azure_ping.storage_access_key}</property> <property name="container">USD{jboss.jgroups.azure_ping.container}</property> </protocol> <protocol type="MERGE3"/> <socket-protocol type="FD_SOCK2" socket-binding="jgroups-udp-fd"/> <protocol type="FD_ALL3"/> <protocol type="VERIFY_SUSPECT2"/> <protocol type="pbcast.NAKACK2"/> <protocol type="UNICAST3"/> <protocol type="pbcast.STABLE"/> <protocol type="pbcast.GMS"/> <protocol type="UFC"/> <protocol type="MFC"/> <protocol type="FRAG4"/> </stack>
[standalone@embedded /] stop-embedded-server [disconnected /] exit
EAP_HOME/bin/standalone.sh -b <IP_ADDRESS> -bprivate <IP_ADDRESS> --server-config= <EAP_CONFIG_FILE> .xml -Djboss.jgroups.azure_ping.storage_account_name= <STORAGE_ACCOUNT_NAME> -Djboss.jgroups.azure_ping.storage_access_key= <STORAGE_ACCESS_KEY> -Djboss.jgroups.azure_ping.container= <CONTAINER_NAME>
EAP_HOME/bin/standalone.sh -b 172.28.0.2 -bprivate 172.28.0.2 --server-config=standalone-azure-ha.xml -Djboss.jgroups.azure_ping.storage_account_name=my_storage_account -Djboss.jgroups.azure_ping.storage_access_key=y7+2x7P68pQse9MNh58Bkk5po9OGzeJc+0IRqYcQ9Cr/Sp4xiUFJVlbY+MGXJRNx3syksikwm4tOYlFgjvoCmw== -Djboss.jgroups.azure_ping.container=my_blob_container
INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (thread-2,ee,eap-server-1) ISPN000094: Received new cluster view for channel server: [eap-server-1|1] (2) [eap-server-1, eap-server-2]
/subsystem=jgroups/stack=udp/protocol=azure.AZURE_PING/property=remove_all_data_on_view_change:add(value=true)
/subsystem=jgroups/stack=udp/protocol=pbcast.GMS/property=max_join_attempts:add(value=3)