Skip to end of metadata
Go to start of metadata

To run a group of servers as a managed domain you need to configure both the domain controller and each host that joins the domain. The following steps focus on the the network configuration for the domain and host controller components.

Domain Controller Configuration

The domain controller is the central government for a managed domain. A domain controller configuration requires two steps:

  • A host needs to be configured to act as the Domain Controller for the whole domain
  • The host must expose an addressable management interface binding for the managed hosts to communicate with it

Configuring a host to act as the Domain Controller is done through the domain-controller declaration in host.xml. If it includes the <local/> element, then this host will become the domain controller:

(See domain/configuration/host.xml)

A host acting as the Domain Controller must expose a native (i.e. non-HTTP) management interface on an address accessible to the other hosts in the domain. Also exposing an HTTP management interface is not required, but is recommended as it allows the Administration Console to work:

The interface attributes above refer to a named interface declaration later in the host.xml file. This interface declaration will be used to resolve a corresponding network interface. 

(See domain/configuration/host.xml)

Please consult the chapter "Interface Configuration" for a more detailed explanation on how to configure network interfaces.

Host Controller Configuration

Once the domain controller is configured correctly you can proceed with any host that should join the domain. The host controller configuration requires three steps:

  • The logical host name (within the domain) needs to be distinct
  • The host controller needs to be addressable by the domain controller (interface binding)
  • The host controller needs to know the domain controller IP address

Provide a distinct, logical name for the host. In the following example we simply name it "staging":

(See domain/configuration/host.xml)

Tell the host to expose a native (i.e. non-HTTP) management interface on an address accessible to the host that is acting as the Domain Controller. Exposing an HTTP management interface is not required, and is only necessary if the user has developed some custom HTTP-based management clients and wishes to use them to administer the host:

Assign an addressable IP address to the host controller itself. The address must be reachable by the Domain Controller:

(See domain/configuration/host.xml)

Tell it how to find the domain controller so it can register itself with the domain:

(See domain/configuration/host.xml)

Server groups

The domain controller defines one or more server groups and associates each of these with a profile and a socket binding group, and also :

(See domain/configuration/domain.xml)

The domain controller also defines the socket binding groups and the profiles. The socket binding groups define the default socket bindings that are used:

(See domain/configuration/domain.xml)
In this example the bigger-sockets group includes all the socket bindings defined in the standard-sockets groups and then defines an extra socket binding of its own.

A profile is a collection of subsystems, and these subsystems are what implement the functionality people expect of an application server.

(See domain/configuration/domain.xml)
Here we have two profiles. The bigger profile contains all the same subsystems as the default profile (athough the parameters for the various subsystems could be different in each profile), and adds the fictional-example subsystem which references the unique-to-bigger socket binding.

Servers

The host controller defines one or more servers:

(See domain/configuration/host.xml)

server-one and server-two both are associated with main-server-group so that means they both run the subsystems defined by the default profile, and have the socket bindings defined by the standard-sockets socket binding group. Since all the servers defined by a host will be run on the same physical host we would get port conflicts unless we used <socket-binding-group ref="standard-sockets" port-offset="150"/> for server-two. This means that server-two will use the socket bindings defined by standard-sockets but it will add 150 to each port number defined, so the value used for http will be 8230 for server-two.

server-three will not be started due to its auto-start="false". The default value if no auto-start is given is true so both server-one and server-two will be started when the host controller is started. server-three belongs to other-server-group, so if its auto-start were changed to true it would start up using the subsystems from the bigger profile, and it would use the bigger-sockets socket binding group.

JVM

The host controller contains the main jvm definitions with arguments:

(See domain/configuration/host.xml)
From the preceeding examples we can see that we also had a jvm reference at server group level in the domain controller. The jvm's name must match one of the definitions in the host controller. The values supplied at domain controller and host controller level are combined, with the host controller taking precedence if the same parameter is given in both places.

Finally, as seen, we can also override the jvm at server level. Again, the jvm's name must match one of the definitions in the host controller. The values are combined with the ones coming in from domain controller and host controller level, this time the server definition takes precedence if the same parameter is given in all places.

Following these rules the jvm parameters to start each server would be

Server JVM parameters
server-one -XX:PermSize=128m -XX:MaxPermSize=128m -Xms64m -Xmx128m
server-two -XX:PermSize=128m -XX:MaxPermSize=128m -Xms64m -Xmx256m
server-three -Xms64m -Xmx128m
Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.