Mindmajix

Configuring server nodes

Configuring server nodes

The last element of the host configuration includes the list of server nodes that are part of the domain. Configuring a server requires, at minimum, the name of the server and the group to which the server belongs:

<!– host.xml configuration file –>

<servers>

<server name=”server-one” group=”main-server-group” />

</servers>

This server definition relies largely on default attributes for the application server nodes. You can, however, highly customize your servers by adding specific paths, socket binding interfaces, system properties, or JVMs.

<server auto-start=”true” name=”sample” group=”sample-group” >

<paths>

<path name=”example” path=”example” relative-to=”jboss.server.log.dir”/>

</paths>

<socket-binding-group port-offset=”250″ ref=”standard-sockets”/>

<system-properties>

<property boot-time=”true” name=”envVar” value=”12345″/>

</system-properties>

<jvm name=”default”>

<heap size=”256m” max-size=”512m”/>

</jvm>

</server>

 Note

If you want to know all the applicable attributes of the server nodes configuration, we suggest you have a look at the schema jboss-asconfig_1.1.xsd, which can be located in the JBOSS_HOME/docs/schema folder of your server distribution. Applying domain configuration A common misconception between users who are approaching the concept of domain is that a domain is pretty much the equivalent of a cluster of nodes, so it could be used to achieve important features such as load balancing or high availability. It’s important to understand that a domain is not pertinent to the functionalities that your application will deliver—a domain is designed around the concept of server management. Thus you can use it both for clustered applications and for applications that are not intended to run in a cluster. To understand it better, let’s give an example: supposing your server topology consists of multiple servers and you have defined a datasource that will be used by your application. So, whether or not you use a cluster, you would need to configure your server distribution.

Applying domain configuration

A common misconception between users who are approaching the concept of domain is that a domain is pretty much the equivalent of a cluster of nodes, so it could be used to achieve important features such as load balancing or high availability.

It’s important to understand that a domain is not pertinent to the functionalities that your application will deliver—a domain is designed around the concept of server management. Thus you can use it both for clustered applications and for applications that are not intended to run in a cluster.

To understand it better, let’s give an example: supposing your server topology consists of multiple servers and you have defined a datasource that will be used by your application. So, whether or not you use a cluster, you would need to configure your datasource across all your standalone servers configuration (this means adding the definition of the datasource in every standalone.xml).

In this case, the advantage of using a domain is evident: the datasource definition will be contained just in the domain controller that provides a central point through which users can keep configurations consistent and also the ability to roll out configuration changes to the servers in a coordinated fashion.

One other important aspect of domain is the ability to provide a more fine-grained configuration than clustering is able to. For example, you can define server groups, each one with its own custom configuration. In order to achieve the same thing with a clustered configuration, you have to manage each machine’s standalone configuration and adapt it to your needs.

Domain and clustering are not, however, mutually exclusive scenarios, but often part of a larger picture; for example, using a domain can further enhance the efficiency of a cluster in advanced configurations where you need to manage starting and stopping multiple AS instances. At the same time, clustering provides typical load balancing and high availability features, which are not integrated into domain management.

On the other hand, there are situations where using a domain may not prove that useful. For example, it’s possible that your system administrators have bought or developed their own sophisticated multi-server management tools, which can do more or less the same things that a domain configuration is able to perform. In this situation, it may be not desirable to switch-out what is already ad-hoc configured.

Another classic example where a domain is not needed is the development phase where you don’t gain anything from a domain installation. Rather, it may add an unneeded additional complexity to your architecture.

Furthermore, the standalone mode is the only choice available in some scenarios, such as if you are running the application server in embedded mode and thus the choice of a domain is incompatible. For example, when using Arquillian project you can test your Enterprise projects using an embedded container, which is managed by the Arquillan using a standalone-based configuration.

In definitive, since the individual server configuration does not vary if you are running domain mode or standalone mode, you can easily consider developing your application in standalone mode and then switch to domain mode when you are rolling in production the application.

An example domain configuration

We will now provide a detailed example of a domain configuration. In this sample, we will include two separate host controller configurations, each one with a list of three nodes. You would need two separate installations of JBoss AS 7, which can be either executed on two different machines or on the same machine. When running on the same machine, it’s practical to assign a virtual IP address to your machines so that you don’t have any port conflict in your domain.

The following image shows our domain project:

Screenshot_11

The first thing we need to do is bind the network interfaces to a valid inet address both for the public interfaces and for the management interfaces. So, assuming that the first domain installation will be bound to the inet-address 192.168.1.1, open the host.xml file and change it accordingly:

<interfaces>

<interface name=”management”>

<inet-address value=”192.168.1.1″/>

</interface>

<interface name=”public”>

<inet-address value=”192.168.1.1″/>

</interface>

</interfaces> In the second domain installation, change the inet-address to 192.168.1.2 in host.xml: <interfaces>         <interface name=”management”>

<inet-address value=”192.168.1.2″/>

</interface>

<interface name=”public”>

<inet-address value=”192.168.1.2″/>

</interface>

</interfaces>

The next thing to do will be defining a unique host name for each installation. So, for the first host.xml, we will have: <host name=”host1″/>

While for the second one, simply use:

<host name=”host2″/>

Next, the most important step will be choosing where the domain controller is located. As we have shown earlier in the image, the domain controller will be located in the first installation (192.168.1.1), so in the host.xml file you should contain the default:

<domain-controller>

<local/>

</domain-controller>

Switching to the other installation, point to the domain controller that is running on the host

192.168.1.1: <domain-controller>

<remote host=”192.168.1.1″ port=”9999″/>

</domain-controller>

The domain configuration is complete. Now, first start up the installation containing the domain controller and then the second installation using the domain.bat/domain.sh script in both cases.

If everything was correctly configured, the domain controller will show evidence of the new host controller registered:

Screenshot_12

Now, let’s have a look at the domain from the management console. The management interfaces are discussed in detail in the next chapter. However, we will peek at them shortly now, for the purpose of showing our domain example.

Point the browser to any of the management interfaces:

http://192.168.1.1:9990/console/

From the main screen, you can have a look at your domain configuration from different perspectives. By now, we are interested to have a look at host controllers that are part of the domain. So, in the top-right area of the screen, choose the Runtime tab, and then select the host you are interested in from the combo-box located on the left.

As you can see, you can find all servers that are running on the domain:

Screenshot_13

From there, you can not only check their status and group them by server-group, but also start and stop each node. For example, as per default, each distribution contains three nodes: two are activated at startup, while the third one will be started on demand. Select the node and then, in the Status panel, you will be able to start/stop the single node:
Screenshot_14

The same configuration could be observed on the Host 2 , which pretty much contains the same number of nodes:

Screenshot_15

So, it should be clear that each Host section has its own list of nodes are part of the domain. What each Host depends on is, however, the Profiles section that contains the domain Profile used by your domain. As we said, one of the most evident advantages of a domain over individual installation is the ability to centralize the services configuration as well as deployed resources.

From within the Web console you can also install application or modules like datasources. In the next tutorial we will discuss in depth about deploying and installing a module to a domain. The main difference from the standalone mode is that once the datasource is added to the domain controller (192.168.1.1), its definition will be part of the default profile, and every host that connects to the domain will inherit its configuration.

Screenshot_16


0 Responses on Configuring server nodes"

Leave a Message

Your email address will not be published. Required fields are marked *

Copy Rights Reserved © Mindmajix.com All rights reserved. Disclaimer.
Course Adviser

Fill your details, course adviser will reach you.