Managing JBoss Application Server 7 with System Center Operations Manager 2012 R2: Part 2 - Domain Mode

First published on TECHNET on Feb 12, 2015

This blog is a continuation of “Managing JBoss Application Server 7 with System Center Operations Manager 2012 R2: Part 1 - Standalone Mode” found here .

As a reminder, JBoss Application Server 7 can be booted in two distinct operating modes: standalone and domain mode. The first blog covered a walkthrough of the standalone mode and this blog covers a walkthrough of domain mode.

Originally the plan was to use the JBoss Application Server 7.1.0.Final for both walkthroughs, but what better way to celebrate the new management packs than with the new Widlfly 8.2 - Generally available since November 20 ^th , 2014.

Important to note: most of the steps detailed for Wildfly translate to JBoss Application Server 7 and JBoss Enterprise Application Server.

Basic Setup

My environment in this walkthrough consists of three Ubuntu 14.04 LTS 64-bit servers managed by System Center Operations Manager 2012 R2 w/ Update Rollup 4 installed. For more details on managing a Linux machine with System Center Operations Manager please refer to the following blog post .

Additionally, all the new JEE Management Packs for JBoss Application Server and Wildfly have been imported. For steps on obtaining and importing the JEE Management Packs refer to the previous blog post section - “Obtaining the Java EE Management Pack and JBoss MP Guide - found here

Planning the domain configuration

Background

Domain mode for JBoss Application Server and Wildfly allow multiple application server instances to be managed from a single control point. The application servers managed from that control point are referred to as members of the domain. Domains have the ability to span application servers running on single or multiple OS instances. A domain configuration is made up of the following entities.

Planned Setup

My environment consists of three Ubuntu 14.04 LTS 64-bit servers: ubuntu-wildfly-1, ubuntu-wildfly-2, and ubuntu-wildfly-3. The server ubuntu-wildfly-1 acts as a domain controller while ubuntu-wildfly-2, and ubuntu-wildfly-3 are host controllers each with two application servers - for a total of four application servers.

The profile we use for our setup is the default “full” profile and the server-group the four application servers belong to are the default “main-server-group”. Finally the data enumerated in Operations Manager console are four independent application server instances.

Obtaining the Wildfly installation: all servers

• The first step for setting up the environment is retrieving the application server installation files


• Run the following command , or download the file and transfer it to the server

• Once downloaded, extract the contents

Setting up the domain controller:ubuntu-wildfly-1

• change into the domain configuration directory of the installation

Removing the application servers from the domain controller

Traditionally a domain controller’s only role is to manage and govern the domain. A default Wildfly installation includes two application servers when a domain instance is started. For our setup we remove these two default application servers from the host configuration file.

• Open up the host.xml file in the domain/configuration directory


• Under the servers tag remove all default servers

Before

After

• Once all servers are removed save and quit the host.xml file

Creating the management user for the domain

The management user is created on the domain controller for use with the host controllers. Each host controller uses this management user to connect to the domain controller.

• Change into the bin directory of the Wildfly installation

• run the add-user.sh application and enter the following

• Add a management user (a)


• Enter username -- anugup


• Enter password -- password


• Enter groups -- leave blank


• Confirm adding user -- yes


• Confirm “Is this new user going to be used for one AS process to connect to another AS process?” -- yes

• At the end note down the message defining the secret value for server-identities definition.
  
  
  
  • The secret value is a base64 encoding of the management users password
  
  
  • In our case the secret value is equal to "cGFzc3dvcmQ="
  
  
  
  

Starting the server

• Once we have completed the setup in the host.xml file change into the bin directory and start the domain controller
  
  
  
  • Replace 10.30.68.91 with the IP address you wish to bind with the domain controller
  
  
  
  

• As the domain controller does not have any application servers running we do not see any enumerations for Wildfly on the ubuntu-wildfly-1 server in the Operations Manager console

Setting up the host controller: ubuntu-wildfly-2, ubuntu-wildfly-3

Modifying the host.xml file

• Change into the domain configuration directory in the host controller’s installation

• Replace the host.xml file with the preconfigured host-slave.xml file
  
  
  
  • Backing up the original host.xml is recommended
  
  
  
  

• Open and edit the host.xml file


• On line 58 we see the preconfigured domain controller settings. These are settings the host controller uses to connect to the domain controller with the specified security-realm “ManagementRealm”.
  
  
  
  • Add an attribute named username with the value of the user created on the domain controller
    
    
    
    • In our case the username is “anugup”
    
    
    
    
  
  
  • As the user was created in the ManagementRealm we can leave the security-realm property alone
  
  
  • We can either replace the jboss.domain.master.address here or specify it through the commandline when the Wildfly host controller is started
    
    
    
    • I specify these settings when I start the Wildfly host controller
    
    
    
    
  
  
  
  

• In the same host.xml file go to line 10 where the <secret value=””> is defined


• As the comment says replace this with the base64 password for the added management user.
  
  
  
  • In our case the value is “cGFzc3dvcmQ=”
  
  
  
  

• the last change we make to this host.xml file is to name this specific host controller


• On line one add the attribute ‘name’ and give it a unique value for the domain
  
  
  
  • ubuntu-wildfly-1 has the name wildfly-host-1.
  
  
  • ubuntu-wildfly-2 has the name wildfly-host-2.
  
  
  
  
  
  

Adding the servers in host.xml file

• On line 86 we see the preconfigured servers in the host.xml file


• To create the architecture we defined in the ‘Planned Setup’ section of this blog post, change the second server to the main-server-group and name it server-two
  
  
  
  
  • For ubuntu-wildfly-2 we rename server-one and server-two to server-three and server-four, respectively
  
  
  
  

Starting the Wildfly host controller

• Change into the bin directory of the Wildfly installation

• start the server with the following parameters for specifying the domain controller
  
  
  
  • -Djboss.domain.master.address=<ip of domain controller>
  
  
  • -Djboss.bind.address.management=<ip of host controller>
  
  
  
  

• Ensure that the host  controller and domain controller can communicate with each other
  
  
  
  • Note: firewall settings might need to be adjusted for the host controller to connect to the management port
  
  
  
  


• Repeat these same tasks with ubuntu-wildfly-3 and ensure that a different name is used for the server name

Viewing the environment in Operations Manager

• If we go to the OpsMgr management server we can see the four servers enumerated in the console

• This base level of monitoring allows us to see some basic information as well as determine if the process is running. For a deeper level of monitoring we need to deploy BeanSpy.

Deploying BeanSpy to the domain

One of the advantages of having a domain environment is it is easy to deploy an application to multiple application servers

• We can deploy BeanSpy through the JBoss command line utility or through the management console for the domain controller
  
  
  
  • In this blog I use the JBoss command line utility (jboss-cli.sh)
  
  
  • I am using the BeanSpy.HTTP.NoAuth.war module which requires no authentication
    
    
    
    • refer to the ‘Part 1’ blog post for using the authentication BeanSpy module
    
    
    
    
  
  
  
  


• Move BeanSpy.HTTP.NoAuth.war to the domain controller host Linux server


• change BeanSpy.HTTP.NoAuth.war name to BeanSpy.war

• On the domain controller change into the Wildfly bin directory


• From here run the following command where the text following “--controller” is the domain controller ip address and management port

• Run the following command in jboss-cli to create the opsmgr security domain
  
  
  
  • For the full profile we add the security-domain ‘opsmgr’.
  
  
  • These commands are also documented in Microsoft’s management pack guide for the JBoss Application Server management pack
  
  
  
  

• In the JBoss command line utility issue the following command to deploy BeanSpy to all servers in the main-server-group
  
  
  
  • main-server-group includes server-one, server-two, server-three, and server-four
  
  
  • There is no output indicating success or failure
  
  
  
  

• Issue the following command in the JBoss command line utility to get deployment info

• If we receive “STATE” of “enabled” we are ready to enable deep monitoring!


• For each of the Configurations in Operations Manager console select the configuration in the OpsMgr console and run the OpsMgr task “Enable deep monitoring using HTTP”


• That’s it! you now have a managed domain configuration with OpsMgr

Side Note: Manual Discovery

Out of the box JBoss standalone and domain mode are supported when using default files domain.xml, standalone.xml, and host.xml. If you are using specific configurations specified during boot time such as alternate bind-addresses or configuration files the easiest work around is to manually discovery the application server. Manual discovery has been available since 2010 and has allowed non-standard Java EE installations to be monitored. For more information on Manual discovery check out Christopher Crammond’s blog post