Mindmajix

Managing mod cluster with the CLI

There are a couple of options that can be used to manage and retrieve runtime information from your cluster. Your first option is the command-line management interface, which can be used to trigger a set of commands available in the mod_cluster subsystem.

The first command you need to learn is list-proxies , which returns merely the hostnames (and port) of the connected proxies:
[standalone@localhost:9999 subsystem=modcluster] :list-proxies
{
“outcome” => “success”,
“result” => [
“CP11-010:8888”,
“CP12-010:8888”
]
}

While this can be useful for a quick inspection of your cluster members, you can get detailed info with the read-proxies-info command that actually sends an INFO message to the httpd server:
[standalone@localhost:9999 subsystem=modcluster] :read-proxies-info
{
“outcome” => “success”,
“result” => [
“CP11-010:8888”,
“Node: [1],Name: de6973fe-b63d-31dc-a806-
04ec16870cfa,Balancer: mycluster,LBGroup: ,Host: 192.168.10.1,Port:
8080,Type: http,Flushpackets: Off,Flushwait:
10,Ping: 10,Smax: 65,Ttl: 60,Elected: 0,Read: 0,Transfered:
0,Connected: 0,Load
: 1
Vhost: [1:1:1], Alias: default-host
Vhost: [1:1:2], Alias: localhost
Vhost: [1:1:3], Alias: example.com
Context: [1:1:1], Context: /, Status: ENABLED

“CP12-010:8888”,
“Node: [1],Name: re5673ge-c83d-25dv-y104-
02rt16456cfa,Balancer: mycluster,LBGroup: ,Host: 192.168.10.2,Port:
8080,Type: http,Flushpackets: Off,Flushwait:
10,Ping: 10,Smax: 65,Ttl: 60,Elected: 0,Read: 0,Transfered:
0,Connected: 0,Load
: 1
Vhost: [1:1:1], Alias: default-host
Vhost: [1:1:2], Alias: localhost

Vhost: [1:1:3], Alias: example.com
Context: [1:1:1], Context: /, Status: ENABLED

]
}

Note

The mod_cluster subsystem also provides the read-proxies-configuration command, which can provide slightly more verbose information about your cluster. For the sake of brevity, we will omit printing its output. The list of proxies that are part of your cluster can also be modified with the CLI. For example, you can use the add-proxy command to add a proxy that has not been “captured” by the mod cluster’s httpd configuration.

[standalone@localhost:9999 subsystem=modcluster] :add-proxy(host=
CP15-022, port=9999)
{“outcome” => “success”}

At the same time, you can remove proxies from the list using the corresponding removeproxy command:

[standalone@localhost:9999 subsystem=modcluster] :removeproxy(
host=CP15-022, port=9999)
{“outcome” => “success”}

Managing your web contexts with CLI

You can use the CLI to manage your web contexts. For example, the enable-context command can be used to tell Apache that a particular web context is able to receive requests:
[standalone@localhost:9999 subsystem=modcluster] :enablecontext(
context=/myapp, virtualhost=default-host)
{“outcome” => “success”}

The corresponding disable-context command can be used to prevent Apache from sending new requests:

[standalone@localhost:9999 subsystem=modcluster] :disablecontext(
context=/myapp, virtualhost=default-host)
{“outcome” => “success”}
Rather, if you want to stop Apache from sending requests from a web context, you can use the stop-context command:

[standalone@localhost:9999 subsystem=modcluster] :stopcontext(
context=/myapp, virtualhost=default-host, waittime=50)
{“outcome” => “success”}

Adding native management capabilities

If you are not able (or simply don’t want) to use the CLI, then you can alternatively configure Apache web server to provide some native management capabilities through the browser. In order to do that, all you need to add is the mod_cluster_manager application context:

<Location /mod_cluster_manager>
SetHandler mod_cluster-manager
Order deny,allow
Deny from all
Allow from 192.168.10
</Location>

You can test your mod_cluster manager application by pointing to the mod_cluster_manager web context at:

http://192.168.10.1:8888/mod_cluster_manager.

In our example, the mod_cluster manager displays information about all the JBoss AS 7 nodes that have been discovered through multicast announcements.

Screenshot_1

As you can see, in the mod_cluster manager page you have plenty of useful information, such as the number of hosts that are currently active (in our example, two nodes) and the web context that are available. By default, all web contexts are mounted automatically (not requiring an explicit mount as for mod_jk), but you can, at any time,
exclude or include them by clicking on the Disable/Enable link, which is placed next to the web context.

Managing web contexts using the configuration file

For the sake of completeness, we will add one more option that can be used to manage your web context, by using your application server configuration file. By default, all web contexts are enabled; however, you can exclude web contexts from the main configuration file using the excluded-contexts directive:

<subsystem xmlns=”urn:jboss:domain:modcluster:1.0″>
<mod-cluster-config excluded-contexts=”ROOT, webapp1″/>
</subsystem>

Troubleshooting mod_cluster

Installing mod_cluster requires just a few steps on the httpd side to get working; however, just in case you cannot get ahead with it, you can find some clues by allowing a verbose output on the administration console:

AllowDisplay On

When setting this directive, you can get some information about the single modules loaded into httpd:

Screenshot_2

Should you find any module that exhibits an OK in the display page, you have at least a clue to investigate.

One more possible cause of errors is advertising messages that could potentially hit a firewall. Remember that advertisement messages use UDP port 23364 and multicast address 224.0.1.105. In order to verify if advertising is an issue, you could try to turn it off by setting the following in the httpd side:

ServerAdvertise Off

This directive should be matched on the application server side by the proxy-list element, which defines the list of httpd servers with which the AS will initially communicate:

<mod-cluster-config proxy-list=”192.168.10.1:8888″>
. . . .
</mod-cluster-config>

Finally, don’t forget to check the httpd logs directory for the error.log file and see if it contains any descriptive error. For example, a common source of errors that can be found on a Windows machine is triggered by Apache’s Dynamic Shared Objects (DSO):

[Tue Aug 23 10:29:24 2011] [warn] proxy: No protocol handler was valid for the URL /balancedemo. If you are using a DSO version of mod_proxy, make sure the proxy submodules are included in the configuration using LoadModule.

This kind of error can be solved by loading the additional proxy module used for your protocol, in this case, the proxy_http_module module:

LoadModule proxy_http_module ./modules/mod_proxy_http.so


0 Responses on Managing mod cluster with the CLI"

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.