Skip to main content
Sign in

Managing Cluster Components

Brendan Gibbs
  • Updated

This section describes how to start and stop server processes, and how to add, remove, and configure ASs and LBs in a FAS cluster.

All of the nodes in a FAS cluster, and all of the server processes in a FAS node (that is, AS, LB, and SNMP Agent) can be run independently of each other; however, the master node plays the most important role. Specifically:

  • Configuration changes such as application deployment or un-deployment require that the master node is running, since only the master node runs the management server process.

  • Slave nodes receive updated configuration from the master. If the master node is not running, the slaves will use cached configuration and then periodically make attempts to connect to the master to get configuration updates.

We therefore recommend that you start the master node before the slaves or the other processes. The start-up order of these other processes is unimportant.

Starting a FAS Node

During installation, you can choose to start the FAS services automatically - see the Fusion Application Server Installation Guide.

Once FAS is installed, you can start and stop FAS from the command line, either as a service (if you installed it as a service), or using a script.

Starting a FAS node starts whatever server processes it finds on the node. Thus, if an AS and an LB are both present, it will start both.

As a Service

If you have created an Operating System service to run FAS (see the Fusion Application Server Installation Guide for details on creating a service either during or after installation), you can start and stop it from the command line:

service fas start

service fas stop

You can also restart and examine the status:

service fas restart

service fas status

Using the Script

You can also start FAS using the supplied script:

<install dir>/bin/fas.sh

Starting and Stopping Server Processes

You can start and stop any server process in a domain using the Management Console:

  1. Launch the Management Console - see the Starting the Management Console section in the Management Interfaces article.

  2. From the top right menu, select Runtime.

  3. From the top left menu, select the host that is running the server process that needs starting or stopping.

  4. From the menu on the left, select Server Instances:

image_10.png

  1. In the main content area, select the server process you want to start or stop.

  2. Click the Stop button. When the server process has stopped, it will show a circle with a line through it in the Active column:

image_11.png

To start a stopped server process, click the Start button.

Note: Because the service does not stop immediately upon clicking the Stop button, it is possible to try to start a service while it is still stopping, which will result in an error. It is advisable to wait for the service to stop (up to a minute) before trying to start it again.

Adding Load Balancers

You can add additional nodes containing an LB to a multibox cluster. You can also add an LB to an existing host on which only an AS was originally installed. Both procedures are described below.

: The cluster element discovery mechanism in FAS uses multicast based on Classful addressing. You must ensure that all hosts in the cluster have addresses in the same Classful subnet, even if your network infrastructure is configured with Classless addressing and multicast will span Classful subnets.

Adding a Load Balancer to the Cluster

  1. Run the FAS installer on the new host (see Fusion Application Server Installation Guide), ensuring that you select the following options:

    • Topology type: Multibox

    • Installation Options: Slave and only Load Balancer

    • Load Balancer Cluster Address: Public FQDN of the cluster

    • Cluster ID: Same as for master node.

If you did not set the Cluster ID when installing the master node, you can leave this blank to use the default. If it was set explicitly, that value must be used.

  1. Restart FAS on the master node.

Adding a Load Balancer to an Existing Node

  1. Launch the Management Console - see the Starting the Management Console section in the Management Interfaces article.

  2. In the top right menu, select Server.

  3. In the top left menu, select the host to add an LB to.

  4. In the left hand menu, select Server Configurations:

image_12.png

  1. Click Add:

image_13.png

  1. Enter the server process name.

  2. Select lb-server-group.

  3. Set the port offset to 0.

  4. Select the Auto Start checkbox.

  1. Click Save .

Configuring Load Balancers

You can configure LB properties using the Management Console or the CLI, using the lb profile.

Editing LB Properties using the Management Console

  1. Launch the Management Console - see the Starting the Management Console section in the Management Interfaces article.

  2. From the top right menu, select Profiles.

  3. From the top left menu, select the lb profile.

  4. In the left hand menu, expand Load Balancer, and select Configuration.

  5. Select the Properties navigation tab.

  6. The properties are listed in the Key column. Click on the cell in the Value column of the property you wish to edit:

image_14.png

  1. Enter the new value and press Return.

Editing LB Properties using the CLI

  1. Start the CLI (see the Starting the CLI section in the Management Interfaces article).

  2. Display the list of LB properties which you can configure:

/profile=lb/subsystem=lb/:read-resource(recursive=true)

  1. Edit the value you wish to change:

/profile=lb/subsystem=lb/property=<property>/:write-attribute(name=value,value=<new value>)

where is the property you want to change, and is the value you want to set it to. For the list of properties see the LB Properties section below.

LB Properties

Property Description
cluster-name The name of the cluster to which the LB belongs

com.alicecallsbob.loadbalancer.

http.ssl.keyStoreAlias

 The alias of the LB’s identity certificate store for HTTPS.

gov.nist.javax.net.ssl.

keyStoreAlias

 The alias of the LB’s identity certificate store for secure SIP.

gov.nist.javax.sip.LOG_

MESSAGE_CONTENT

 Set to true if you want to capture message content in the log.

Default is false.

gov.nist.javax.sip.MAX_

MESSAGE_SIZE

 Maximum size of a SIP message received over UDP. This is used to prevent DoS attacks.

Default is 10000

gov.nist.javax.sip.MAX_TCP_

MESSAGE_SIZE

 Maximum size of a SIP message received over TCP. This is to prevent DoS attacks.

Default is 2000000.

gov.nist.javax.sip.REENTRANT_

LISTENER

 Default is true, which means that the listener is re-entrant. In this case the stack manages a thread pool, and synchronously calls the listener from the same thread that read the message. Multiple transactions may concurrently receive messages and this will result in multiple threads being active in the listener at the same time.

gov.nist.javax.sip.SECURITY_

MANAGER_PROVIDER

 The name of the class used to provide certificates to the SIP stack. Do not change.

gov.nist.javax.sip.SILENTLY_

DROP_LARGE_MESSAGES

 Determines the behavior of the LB when it receives a message that exceeds either MAX_MESSAGE_SIZE or MAX_TCP_MESSAGE_SIZE (depending on the protocol). If set to true, it silently drops the message; if set to false, it sends a 513 Message Too Large SIP response.

gov.nist.javax.sip.THREAD_

POOL_SIZE

 Concurrency control for number of simultaneous active threads. Default is 64.

If this is not specified, and the listener is re-entrant, each event delivered to the listener is run in the context of a new thread.

If this is specified and the listener is re-entrant, the stack will run the listener using a thread from the thread pool. This allows you to manage the level of concurrency to a fixed maximum. Threads are pre-allocated when the stack is instantiated.

If this is specified and the listener is not re-entrant, the stack will use the thread pool thread from this pool to parse and manage the state machine but will run the listener in its own thread.

gov.nist.javax.sip.TIMER_

CLASS_NAME

 Name of the class implementing thegov.nist.javax.sip.stack.timers.SipTimer interface. This allows pluggable implementations of the timer that will take care of scheduling the various SIP Timers.
gov.nist.javax.sip.TRACE_LEVEL This property is set to LOG4J by default, which means the effective log levels are determined by log4j. Do not change this value; instead logging should be configured using the Logging subsystem of the Core subsystem in the lb profile. See the Logging section.
https.keystore.file.path The path to the LB’s identity certificate store for HTTPS.
https.truststore.file.path The path to the LB’s trust certificate store for HTTPS.

javax.sip.AUTOMATIC_

DIALOG_SUPPORT

 The default value is off, which means that the application is responsible for creating the dialog if required, and associate it with a response (provisional or final) of a dialog creating request.

If set to on a dialog gets created on a dialog creating transaction. The first response having both a From and a To tag creates the transaction. The first 2xx response to the transaction will drive the dialog to the CONFIRMED state.
javax.sip.ROUTER_PATH Sets the fully qualified classpath to the application supplied Router object that determines how to route messages when the stack cannot make a routing decision (ie. non-sip URIs).
javax.sip.STACK_NAM Sets a user friendly name to identify the underlying stack implementation to the property value.
removeRouteHeadersMeantForLB Whether the LB should remove Route headers meant for itself.

Default is false. Do not change.
rmiRegistryPort The port used by the Load Balancer to receive RMI notifications from the ASs

Default is 2000. Do not change.
sips.keystore.file.path The path to the LB’s identity certificate store for SIPS.
sips.truststore.file.path The path to the LB’s trust certificate store for SIPS.

Adding Application Servers

You can add additional slave nodes containing an AS to a multibox cluster.

: The cluster element discovery mechanism in FAS uses multicast based on Classful addressing. You must ensure that all hosts in the cluster have addresses in the same Classful subnet, even if your network infrastructure is configured with Classless addressing and multicast will span Classful subnets.

Adding an Application Server to the Cluster

  1. Run the FAS installer on the new host (see Fusion Application Server Installation Guide), ensuring that you select the following options:

    • Topology type: Multibox

    • Installation Options: Slave and only Application Server

    • Load Balancer Cluster Address: Public FQDN of the cluster

    • Cluster ID: Same as for master node.

If you did not set the Cluster ID when installing the master node, you can leave this blank to use the default. If it was set explicitly, that value must be used.

  1. Restart FAS on the master node

Configuring Application Servers

The main properties which you can configure for an AS are SIP Servlet properties. See the Configuring SIP article.

Removing an AS or LB

If required, you can remove an AS or an LB server process from a cluster. You should ensure that at least one AS and one LB remain in the cluster following the removal.

  1. Launch the Management Console - see the Starting the Management Console section in the Management Interfaces article.

  2. From the top right menu, select Server.

  3. From the top left menu, select the host from which you want to delete a server process.

  4. In the menu on the left, select Server Configurations.

  5. In the main content area, select the server process from the table.

  6. Click Remove.

  7. When the confirmation dialog is displayed, click Confirm to remove the server process from the cluster:

image_15.png

Disabling Support for RFC 3581

Fusion Application Server implements RFC 3581 (an extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing). This involves populating the rport parameter with the port from which FAS received the request, and adding a Received parameter containing the address from which it received the request.

Some entities, such as Linphone, take these values and use them to populate the contact header in the INVITE request that it sends out. This would be fine if the entity sent the REGISTER from the port it was actually listening on, but causes problems if it is sent from an ephemeral port, as in the case of Linphone.

You can configure Fusion Application Server to disable RFC 3581 behavior by setting the gov.nist.javax.sip.stack.SUPPORT_RFC3581 property to false. (The default value is true.)

Disabling RFC3581 using the Management Console

  1. Launch the Management Console - see the Starting the Management Console section in the Management Interfaces article.

  2. From the top right menu, select Profiles.

  3. From the top left menu, select the ha profile.

  4. In the left hand menu, expand Sip and select Sip Servlet.

  5. Select the Properties navigation tab.

  6. Find the gov.nist.javax.sip.stack.SUPPORT_RFC3581 property:

image_16.png

  1. Change the value to false.

Disabling RFC3581 using the CLI

  1. Start the CLI (see the Starting the CLI section in the Management Interfaces article).

  2. Change the gov.nist.javax.sip.stack.SUPPORT_RFC3581 property to false:

/profile=ha/subsystem=sip/property=gov.nist.javax.sip.stack.SUPPORT\_RFC3581/:write-attribute(name=value, value=false)

 

Viewing Cluster Configuration

You can browse through all of the configuration options for your FAS cluster using the Configuration Browser in the Management Console. This browser provides a read-only view of the Dynamic Representation Model, in a tree structure. This may help understand the structure of resources in the CLI, and allows you to see attributes which you cannot access in the Management Console.

Open the Management Console, and in the bottom right toolbar, select Tools->Browser:

image_17.png

Expand the nodes in the tree structure on the left, and click on the relevant node. The content pane displays the configuration details for that node: the Description tab provides a description of each of the data values applicable to the selected node; the Data tab displays the actual data values:

image_18.png

Changing Addresses

Addresses can be configured at two levels:

  • The IP addresses that each node should use

  • The address the cluster should use when identifying itself externally (in the Contact and Route SIP headers for instance).

Configuring Addresses on a Node

Address configuration for each node is stored on that node, in the <install dir>/domain/configuration/fas.properties file. This file contains several properties; the properties that are important when configuring addresses are:

Property Example Description
lb.bind.address 192.168.2.3 LB Internal Traffic IP address on ports 5065 and 7580

This is the IP address that the LB server process uses for communication between cluster elements.
lb.public.bind.address 192.168.2.3 This is the IP address that the LB server process binds to for HTTP, HTTPS, SIP, and SIPS traffic on ports 8080, 8443, 5060, and 5061.

See the Changing the LB HTTP Address to bind to all IP Addresses section in this article for other options.
jboss.bind.address 192.168.2.3 AS Service and Internal Traffic IP address on ports 5080 and 8100

This is the IP address that the AS server process binds to for HTTP, HTTPS, SIP, and SIPS traffic from the LBs, as well as for communication between cluster elements.

Note: It is not currently possible to configure the addresses for service and internal traffic separately for the AS server process.

jboss.bind.address.

management

 192.168.2.3 This is the IP address that the Management Traffic binds to on port 9999.

This is used by the CLI and Management Console, and for communication between master and slave host controllers.

jboss.domain.master.

address

 192.168.2.3 The address that management traffic is bound to on the master node. Only used on slaves, where it should be the same as the jboss.bind.address.management value on the master.

Typically, the values (other than jboss.domain.master.address) will be the same, unless you need to split network traffic among different interfaces on the host. jboss.domain.master.address should be the same for all slaves in the cluster.

Changing the IP Addresses of a Node

  1. Edit the <install dir>/domain/configuration/fas.properties file.

  2. Edit the values of the addresses that you want to change and save the file.

  3. Restart FAS.

  4. Check that the ports are bound to the new addresses using a tool such as netstat.

If the check fails:

  • Check whether the port is in use.

  • Ensure that FAS started properly.

  • Look in the server logs for any information as to why the IP address could not be bound.

If you change the master node management bind address (jboss.bind.address.management), after restarting the node you must then update the fas.properties file on each of the slave nodes as described below:

  1. Update the jboss.domain.master.address property.

  2. Restart FAS.

  3. Check that the slave node rejoined the master. For instance, check that the host of the slave node appears in the Management Console.

Configuring the External Address Mode

You can configure how external entities should address the FAS cluster. You can configure the address modes for SIP and HTTP(S) separately. These settings are:

  • external-address-mode

Used for HTTP, this will affect the addresses the container provides to applications when they need to determine the address of the cluster for HTTP, such as when providing URLs to external clients.

  • sip-external-address-mode

Used for SIP, it determines the address that FAS uses when it populates the following headers of outbound SIP:

  • Contact header, when an application on FAS acts as a UAC or UAS.

  • Record-Route header, when an application acts as a record routing proxy.

Both external-address-mode and sip-external-address-mode can be set to one of:

  • cluster

The external-address is a static address as defined in the cluster-address attribute (see the Configuring the Cluster Address section in this article). When this option is selected, the Record-Route and Contact headers in SIP messages are populated with an address that will target any LB, and HTTP also uses this value for its address. This address should be an FQDN which resolves to all the LBs using DNS. This option requires DNS support in the network.

  • load-balancer

The external-address is a randomly-selected active LB address. This mode is useful for deployments that do not support DNS in their SIP infrastructure. It is also useful for single-box deployments where the machine on which FAS is installed is likely to frequently change networks, so that the DNS server is not always available.

  • application-server

The external-address is that of the local AS. This mode is useful for certain development topologies where IP addresses change often.

By default, both values are set to cluster.

Changing the External Address Modes

  1. Launch the Management Console - see the Starting the Management Console section in the Management Interfaces article.

  2. In the top right menu, select Profiles.

  3. In the top left menu, select the ha profile.

  4. In the left hand menu, expand Sip and select Sip Servlet.

  5. Select the Configuration navigation tab:

image_19.png

  1. Click Edit.

  2. In the HTTP External Address Mode or SIP External Address Mode drop-down lists, select the required option such as load-balancer).

  3. Click Save.

Configuring the Cluster Address

If you are using the cluster external address mode, you might need to change the cluster address when you change other addresses. See the Configuring the External Address Mode section for an explanation of this mode.

When you change the cluster address, you must typically make changes to the trust subsystem to ensure that it contains a valid identity certificate that matches the new cluster address. This will ensure the TLS server identity certificate presented to the HTTP and SIP client matches the new cluster address.

Changing the Cluster Address using the Management Console

  1. Launch the Management Console - see the Starting the Management Console section in the Management Interfaces article.

  2. From the top right menu, select Profiles.

  3. From the top left menu, select the ha profile.

  4. In the left hand menu, expand Sip and select Sip Servlet.

  5. Select the Configuration navigation tab:

image_20.png

  1. Click Edit.

  2. In the Cluster Address field, enter the new address.

  3. Click Save.

Changing the Cluster Address using the CLI

  1. Start the CLI (see the Starting the CLI section in the Management Interfaces article).

  2. Run the following command:

/profile=ha/subsystem=sip:write-attribute(name=cluster-address,value=<new cluster address>

where <new cluster address> is the address you want to change the cluster address to.

Configuring the Cluster Name

If your cluster is created with the default cluster name (ClusterID-<Cluster address>), and you subsequently change the cluster address or IP address, the original cluster name does not get changed. You do not normally need to change it, as long as it is still unique in your enterprise, and it is identical on each AS and LB in the cluster. You can change the name if required, however.

Note: While it is possible to change the cluster name through the CLI, the cluster name is used as the basis of many attributes (for example, the names of Infinispan caches), and these will not be changed. Therefore, the recommended approach is to find and replace all occurrences of the old cluster name value in the underlying configuration file, domain.xml.

  1. On the master FAS, open the <install dir>/domain/configuration/domain.xml in an editor.

  2. Find each occurrence of the old cluster name and replace it with the new cluster name. There will typically be around ten occurrences of the cluster name to be changed:

<transport cluster="sessionLocation-ClusterID-192.168.9.14" lock-timeout="60000"/>

would become

<transport cluster="sessionLocation-<new cluster name>" lock-timeout="60000"/>

where is the new name of the cluster.

  1. Save the file

  2. Restart the master FAS, and then restart FAS on all the slave nodes to pick up the changes.

The cluster name on each AS and LB in the cluster must match, otherwise the ASs will not be able to register with the LBs.

Changing the LB HTTP Address to bind to all IP Addresses

By default, the LB only listens on one network interface for all traffic: that is, HTTP, HTTPS, SIP, and SIPS. Using the CLI, you can configure the LB to listen for HTTP and HTTPS on all IPv4 addresses. Once the HTTP and HTTPS bindings are changed to bind to all interfaces, traffic can be sent to http://<any_bound_ip>:8080 and https://<any_bound_ip>:8443.

  1. Connect to the CLI (see the Starting the CLI section in the Management Interfaces article).

  2. Run the following commands:

/socket-binding-group=lb-sockets/socket-binding=http:write-attribute(name=interface,value=all)

/socket-binding-group=lb-sockets/socket-binding=https:write-attribute(name=interface,value=all)

  1. Restart FAS on each node to pick up the new configuration.

The HTTP and HTTPS bindings for the LB will now be to all interfaces ( 0.0.0.0).

Managing Frequently Changing IP Addresses

When running FAS on a development machine, it is likely that your IP address will be changing frequently. There are two ways to help manage this:

  • If you do not need FAS to send and receive SIP or HTTP traffic to and from other machines, you can use the loopback address. See the Using the loopback Address section in this article.

  • Otherwise, you should set the external address modes to use the load-balancer option (this step will avoid you having to update the cluster address each time the address changes), and then update the fas.properties file with details of the new IP address each time it changes, as described below. See the Configuring the External Address Mode section in this article for details of how to change the mode.

Note: The following instructions assume that FAS is running as a single box installation.

To Change the IP Address in the fas.properties file

  1. Edit the <install dir>/domain/configuration/fas.properties file.

  2. Edit the value of the jboss.bind.address property to the new IP address.

  3. Edit the value of the jboss.bind.address.management property to the new IP address.

  4. Edit the value of the jboss.domain.master.address property to the new IP address.

  5. Save the file.

  6. Restart the FAS service.

Using the loopback Address

For single-box installations, you might want to install FAS using the loopback address (127.0.0.1) to avoid having to change the bind address when the host machine's IP address changes. You can configure FAS to bind to the loopback address by editing the jboss.bind.address (as described in the To Change the IP Address in the fas.properties file section above) to be the loopback address.

Binding to the loopback address means that FAS will not be externally addressable, so all interactions with FAS (SIP messages, administration) must originate from that machine.

If the loopback address is used, for the AS and LB to communicate with each other they must use the FILE_PING discovery protocol. You can set this using the CLI:

  1. Connect to the CLI (see the Starting the CLI section in the Management Interfaces article).

  2. Run the following commands:

/profile=ha/subsystem=jgroups/stack=tcp:add-protocol(type=FILE_PING)

/profile=ha/subsystem=jgroups/stack=udp:add-protocol(type=FILE_PING)

  1. Run the following commands:

/profile=lb/subsystem=jgroups/stack=tcp:add-protocol(type=FILE_PING)

/profile=lb/subsystem=jgroups/stack=udp:add-protocol(type=FILE_PING)

Reverting the Changes

If at some point using the loopback address is no longer appropriate, you must remove the FILE_PING discovery protocol, and then set the jboss.bind.address to an appropriate IP address.

The FILE_PING discovery protocol can be removed with the following CLI commands:

/profile=ha/subsystem=jgroups/stack=tcp:remove-protocol(type=FILE\_PING)

/profile=ha/subsystem=jgroups/stack=udp:remove-protocol(type=FILE\_PING)

/profile=lb/subsystem=jgroups/stack=tcp:remove-protocol(type=FILE\_PING)

/profile=lb/subsystem=jgroups/stack=udp:remove-protocol(type=FILE\_PING)

When you have run these commands and edited the jboss.bind.address as required, restart FAS to pick up the changes.

 

Related articles

Comments

0 comments

Please sign in to leave a comment.

Powered by Zendesk