Axigen with Red Hat Cluster - Back-End Solution Deployment

From Axigen Wiki

DNS

A local DNS server, accessible from the cluster nodes, should be available in the infrastructure. All IP addresses should have a corresponding host name assignment in the local DNS server as an A record.

For example, for a cluster of three Axigen active nodes, a single OpenLDAP active node, and and a hot stand-by may be named in the cluster.local domain, as follows:

• Static IP addresses:
  • first back-end node: b1.cluster.local
  • second back-end node: b2.cluster.local
  • third back-end node: b3.cluster.local
  • first LDAP node: l1.cluster.local
  • first hot stand-by node: f1.cluster.local
• Dynamic/Floating IP addresses:
  • first failover domain (b1+f1): axib1.cluster.local
  • second failover domain (b2+f1): axib2.cluster.local
  • third failover domain (b3+f1): axib3.cluster.local
  • fourth failover domain (l1+f1): ldap1.cluster.local

Storage

The external shared storage must be configured with at least one partition for each failover domain in the cluster. The partition will store the shared data for the corresponding service provided by that failover domain.

Axigen's shared data may be split into multiple virtual entities, each one of them may have a separate corresponding partition:

1. Domains

   This entity is usually the largest in size, because it contains all the mailboxes from all the domains. Its size depends on the mailbox quotas and average mailbox usage.

2. Logs

   Depending on your company's logs retention rules, logs can have a size of under 1 GB to several gigabytes.

3. Queue

   It only contains temporary e-mails stored in the queue. Its size depends a lot on the email traffic, but usually shouldn't be more than 1 GB.

4. The rest of Axigen data

   This partition will contain the axigen configuration and filter files, WebMail and WebAdmin files, and the reporting and domain delegation databases. It is the smallest in size and should not be more than 200MB in size, but it may also grow to around 1 GB.

When performing the LUN configuration on the shared storage device, each cluster service should have a separate virtual disk with multiple partitions. This will allow the isolation of each virtual disk only on the nodes contained in its corresponding failover domain.

Example configuration

This document uses an example setup configuration, explained below.

IPs and DNS

Four nodes were involved, two Axigen active nodes, a single OpenLDAP active node, and their hot stand-by counterpart:

1. n1.cl.axilab.local: 10.9.9.91 (Axigen Backend 1)
2. n2.cl.axilab.local: 10.9.9.92 (Axigen Backend 2)
3. n3.cl.axilab.local: 10.9.9.93 (OpenLDAP Backend)
4. n4.cl.axilab.local: 10.9.9.94 (Failover)

The cluster service floating IP addresses follow:

1. axib1.cl.axilab.local: 10.9.9.96
2. axib2.cl.axilab.local: 10.9.9.97
3. ldap.cl.axilab.local: 10.9.9.98

All names are registered and available in the DNS server, so there is no need to use the /etc/hosts file.

Storage

For each Axigen cluster service, a storage unit, shared between two nodes in the same failover domain, contains the following partitions:

1. Axigen data directory

   Block device: /dev/disk/by-uuid/bd537993-d78a-4bf9-acf7-ed0993edbafb

   Mount point: /var/clusterfs/axib1-data

   Structure:

   • axigen/
   • axigen/domains -> ../../axib1-dom/domains
   • axigen/log -> ../../axib1-lq/log
   • axigen/queue -> ../../axib1-lq/queue

2. Axigen domains

   Block device: /dev/disk/by-uuid/4407d04d-f48a-456b-b3f4-11a8d0f6e254

   Mount point: /var/clusterfs/axib1-dom

   Structure:

   • domains/

3. Axigen logs and queue

   Block device: /dev/disk/by-uuid/59efb5e6-bf85-4486-ac75-57e2b40c2e78

   Mount point: /var/clusterfs/axib1-lq

   Structure:

   • log/
   • queue/

For each OpenLDAP cluster service, a storage unit may contain a single partition, organized as follows:

1. OpenLDAP

   Block device: /dev/disk/by-uuid/28a715bb-8b1d-4acd-959f-a67328f04d16

   Mount point: /var/clusterfs/ldap

   Structure:

   • db/
   • cf/

It is recommended, for the ease of manual mount operations, that the /etc/fstab file to be filled on each node with the cluster shared storage partitions accessible from that node.

Fence device

The nodes were handled by an APC power switch, available at the address 10.9.9.99. The fenceadm user will be used for power cycling the nodes, if considered necessary by the Red Hat Clustering software.

Cluster software installation

Base packages

On both nodes, the following packages are the minimum that should be installed for the cluster exemplified in this document to function correctly:

• rgmanager - Manages cluster resources defined by the user. It allows you to define services for high-availability on your cluster. Rgmanager monitors the services, and if a node fails, it will relocate the service to another node in the cluster.
• cman - A symmetric, general-purpose, kernel-based cluster manager.
• openais - The cluster manager (cman) locking scheme uses kernel modules to communicate cluster status and changes between nodes. OpenAIS uses userspace programs to accomplish the same thing.

To install the packages, please issue on all nodes involved in the cluster, the following command:

yum install rgmanager cman

Cluster administration packages

Conga

Client (ricci)

The ricci package provides the client component of the Conga administrative interface needed to configure the cluster. It needs to be installed on all nodes involved in the cluster, using the command:

yum install ricci

The package also provides a daemon, which must be started via its corresponding initscript:

services ricci start

Server (luci)

The luci package provides the server component of the Conga administrative interface needed to configure the cluster. You can install it on any of the nodes involved in the cluster. In this example setup, we have installed it on the n1.cl.axilab.local node.

In order to install the luci package, please issue:

yum install luci

After installation, you need to set the password for the admin user needed to access the UI interface:

luci_admin init

A (re)start is required for the password to be taken into account:

service luci restart

Then, the administrative interface can be accessed by typing into a browser the hostname or IP address of the node that contains the installed instance of the Conga web UI, via the secure https protocol on the 8084 port (default values).

Our specific example uses the https://n1.cl.axilab.local:8084 address to access the administrative interface.

OpenLDAP

Axigen performs the following interaction with an LDAP service:

• authentication (read operation)
• SMTP routing (read operation)
• Proxy redirection (read operation)
• Axigen-to-LDAP provisioning (read/write operation)
• LDAP-to-Axigen provisioning (read operation)

The OpenLDAP server can run in various different multi-node architectural configurations, depending on the overall number of accounts and the e-mail traffic - both number of e-mails transferred via SMTP and the number of connections via end-user protocols, POP3, IMAP and WebMail. This document will only describe two of these architectural configurations, following below.

The first architectural configuration is similar with Axigen's setup, with one or more OpenLDAP nodes serving different domains, each one of them configured with a corresponding hot stand-by node sharing the same storage, the monitoring and failover being performed by a cluster management software. This way, when an OpenLDAP node fails, its corresponding hot stand-by node will take over the responsibilities. This setup is recommended in most situations, when a single LDAP node can handle the entire LDAP traffic.

The second configuration involves setting up multiple OpenLDAP instances in master/slave replication mode and it should be used in situations where the overall LDAP traffic cannot be handled by a single LDAP node. A single master node will be configured as master and will be used only for provisioning purposes. Thus, the master OpenLDAP node will be installed in the back-end tier, in an active/passive configuration handled by the clustering management software. Additionally, a set of at least two (to ensure redundancy) LDAP replica nodes will be installed and configured in the front-end tier (none of the Axigen nodes in the back-end tier need to perform read operations to the LDAP server) and all the LDAP queries will be load-balanced the same way as the Axigen services (POP3, IMAP, WebMail) from the front-end proxy nodes.

The common point of setup for the two alternatives is the fact that the high-availability in the back-end tier is ensured by the Red Hat Cluster suite, regardless if you are setting up a stand-alone single OpenLDAP instance or a master/slave replication mode configuration.

The first alternative is explained as follows.

Base installation

Package installation

The OpenLDAP server package is called openldap-servers. OpenLDAP 2.3 is present by default in the Red Hat or CentOS version 5 repositories, and contains a back ported syncrepl overlay from the 2.4 version. On the other hand, it doesn't contain the memberof overlay, which is necessary if you want to use Axigen groups synchronized with LDAP. If you need both overlays, you have to manually compile a custom OpenLDAP 2.4 server. Red Hat and CentOS 6 contain the OpenLDAP 2.4 version, by default.

In order to install the default repository version, use the yum package manager:

yum install openldap-servers

After the package installation process has finished successfully, the ldap init script must be disabled to start at system boot, to avoid unnecessary errors at boot time, because the configuration file will not be available until the related cluster service starts:

chkconfig --del ldap

Repeat the same package installation steps on the hot stand-by node.

Storage preparation

Mount the cluster shared partition in its destination mount point, according to /etc/fstab:

mount /var/clusterfs/ldap

Create the working directories on the shared partition:

install -d -o ldap -g ldap -m 755 /var/clusterfs/ldap/{cf,db}

Configuration

Download the Axigen OpenLDAP Schema kit from axigen.com downloads page and decompress the archive, then navigate to the directory containing the axigen.schema file, and use the following command to install it:

install -o ldap -g ldap -m 640 axigen.schema \
  /var/clusterfs/ldap/cf/axigen.schema

Install database configuration file using the openldap-servers package example file:

install -o ldap -g ldap -m 640 \
  /etc/openldap/DB_CONFIG.example \
  /var/clusterfs/ldap/db/DB_CONFIG

If necessary, you may edit the /var/clusterfs/ldap/db/DB_CONFIG and perform any additional database configuration.

Then, create the OpenLDAP server configuration file, as follows:

cat > /var/clusterfs/ldap/cf/slapd.conf <<SLAPDCONF
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/misc.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /var/clusterfs/ldap/cf/axigen.schema

serverID 1
database bdb
suffix "dc=domains"
checkpoint 32 30
rootdn "cn=admin,dc=domains"
rootpw secret
directory /var/clusterfs/ldap/db
index objectClass eq,pres
index ou,cn,mail,surname,givenname eq,pres,sub
index entryUUID,entryCSN eq

## Axigen specific configuration for provisioning
moduleload syncprov.la
# openldap 2.3 in RHEL 5.x has only builtin syncprov
# so the following two lines must be commented
moduleload memberof.la

# Replication support enabled (for cookies)
overlay syncprov
syncprov-checkpoint 100 30
syncprov-sessionlog 100

# Member-of support enabled (not in openldap 2.3/RHEL 5.x)
overlay memberof
memberof-refint true
SLAPDCONF

Modify the ldap system init script configuration file, to point to the cluster configuration file:

echo SLAPD_OPTIONS=\"-f /var/clusterfs/ldap/cf/slapd.conf\" >> /etc/sysconfig/ldap

Start the slapd service by issuing:

service ldap start

Create root entries, as follows:

ldapadd -x -D "cn=admin,dc=domains" -w secret <<LDIF
dn: dc=domains
objectclass: dcObject
objectclass: organization
o: Axigen Mail Domains
dc: domains

dn: cn=admin,dc=domains
objectclass: organizationalRole
cn: admin
LDIF

At the end, create a domain with the following command:

ldapdomain=axigen.com ldapadd -x -D "cn=admin,dc=domains" -w secret <<LDIF
dn: o=${ldapdomain},dc=domains
objectclass: organization
o: ${ldapdomain}

dn: ou=Groups,o=${ldapdomain},dc=domains
objectclass: organizationalUnit
ou: Groups

dn: ou=Users,o=${ldapdomain},dc=domains
objectclass: organizationalUnit
ou: Users
LDIF

Stop the OpenLDAP server and umount the shared partition:

service ldap stop
umount /var/clusterfs/ldap

Axigen

Package installation

Axigen must be installed on all nodes, just the package, without being started or configured.

After the package installation process finishes successfully, the axigen and axigenfilters init scripts must be disabled to start at system boot in all runlevels:

chkconfig --del axigen
chkconfig --del axigenfilters

Storage preparation

Mount all the cluster shared partitions in their destination mount points, according to /etc/fstab:

mount /var/clusterfs/axib1-data
mount /var/clusterfs/axib1-dom
mount /var/clusterfs/axib1-lq

Copy the Axigen data directory form the default /var/opt/axigen on the corresponding partition:

cp -rav /var/opt/axigen /var/clusterfs/axib1-data

If multiple partitions are being used, create their folders and corresponding symbolic links on the main Axigen Data directory:

mkdir -v /var/clusterfs/axib1-{dom/domains,lq/{log,queue}}
chown -v axigen:axigen /var/clusterfs/axib1-{dom/domains,lq/{log,queue}}
ln -snv ../axib1-dom/domains /var/clusterfs/axib1-data/axigen/domains
ln -snv ../axib1-lq/log /var/clusterfs/axib1-data/axigen/log
ln -snv ../axib1-lq/queue /var/clusterfs/axib1-data/axigen/queue

Init script

First, you need to disable the regular axigen init script to accidentally start, by editing its corresponding configuration file /etc/sysconfig/axigen and literally setting:

AXIGEN_BACKEND="<DISABLED>"

A hard link must be created, which will point to the original package init script:

ln -v /etc/init.d/axigen /etc/init.d/axigen-axib1

Then, the corresponding configuration file must be created as /etc/sysconfig/axigen-axib1, with the following configuration:

# The AXIGEN_BACKEND variable is specific to failover domain
AXIGEN_BACKEND="axib1"

# The following AXIGEN_* variables are common on all nodes
AXIGEN_DATA_DIR="/var/clusterfs/${AXIGEN_BACKEND}-data/axigen"
AXIGEN_PID_FILE="${AXIGEN_DATA_DIR}/run/axigen.pid"
AXIGEN_DAEMON_OPT="-W ${AXIGEN_DATA_DIR}"
AXIGEN_SSL_CERT="${AXIGEN_DATA_DIR}/axigen_cert.pem"
AXIGEN_SSL_DH="${AXIGEN_DATA_DIR}/axigen_dh.pem"

Admin password

To be able to login in the Axigen administrative interfaces, you need to set the password for the top level administrative user, called admin. The following command helps you with this step:

/opt/axigen/bin/axigen -W /var/clusterfs/axib1-data/axigen -A your-password

Service start

By default, all enabled Axigen services will listen to the local loopback interface, 127.0.0.1. In order to be able to use the WebAdmin interface via the cluster floating IP address, you must set it on the corresponding network interface:

/sbin/ip -f inet addr add dev eth0 10.9.9.96

You can see it set if it appears in the output of the following command:

/sbin/ip -f inet addr show dev eth0

The output should be similar with the following one:

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
    inet 10.9.9.91/24 brd 10.9.9.255 scope global eth0
    inet 10.9.9.96/24 scope global secondary eth0

Start the Axigen service with the following command:

service axigen-axib1 start

WebAdmin setup

Then, enable the WebAdmin listener on the cluster service floating IP address, using the CLI service:

$ telnet localhost 7000
Trying 127.0.0.1...
Connected to localhost.localdomain (127.0.0.1).
Escape character is '^]'.
Welcome to AXIGEN's Command Line Interface
You must login first. For a list of available commands, type HELP
<login> user admin
<password> your-password
For a list of available commands, type HELP
+OK: Authentication successful
<#> config server
+OK: command successful
<server#> config webadmin
+OK: command successful
<server-webadmin#> add listener address 10.9.9.96:9000
+OK: command successful
<server-webadmin-listener#> commit
committing changes and switching back to previous context.
+OK: command successful (listener is closed)
<server-webadmin#> commit
committing changes and switching back to previous context.
+OK: command successful
<server#> commit
committing changes and switching back to previous context.
+OK: command successful
<#> save config
+OK: command successful
<#> quit
WARNING: all changes made and not committed are lost
connection to AXIGEN closing.
+OK: have a nice day
Connection closed by foreign host.

Point your browser at the failover domain corresponding floating IP address or its corresponding DNS name, for example http://10.9.9.96:9000 (http://axib1.cl.axilab.local:9000), and try to login using the admin username and the password you have set earlier.

If the login has been successful, you can login and set the listeners for the Axigen services you want to use, including but not limited to: SMTP, IMAP, POP3, WebMail. Please use the floating cluster IP address for these services listener addresses, like for the WebAdmin service you have set above, for example 10.9.9.96.

LDAP connector setup

Each Axigen back-end node must be set to authenticate its user base against the OpenLDAP service. To do this, from the WebAdmin interface, add an LDAP connector by expanding the Clustering left menu and clicking on the Clustering setup option. In the LDAP Connectors tab, press on the + Add connector button and fill in the fields, as follows.

The LDAP Connector name field must contain the name of the clustered LDAP failover domain tag, for example ldap or ldap1 if you are using multiple OpenLDAP instances.

The LDAP Server Parameters panel must also be configured with the hostname of the OpenLDAP failover floating IP address or its corresponding DNS host name. The standard for plain connections to the OpenLDAP server is 389 and the standard LDAP over SSL port is 636.

Select the Server type as OpenLDAP and check the Enable Clustered Operations option. The rest of the connectivity and synchronization parameters depend on your setup.

In the LDAP Search Parameters panel, select the Use Administrative DN option, and fill in the OpenLDAP server administrator, which will also be used for provisioning write operations. The Account Base DN parameter specifies the scope where the searches are being performed in. Finally, the Hostname attribute must be set to axiHost, defined in the axigen custom schema file you have installed in OpenLDAP.

Press the Quick Add button to complete adding the LDAP connector and then define a user map which will point to this connector. Switch to the User Maps tab and press the + Add User Map button. Name it accordingly and then select the LDAP Bind option from the User Map type drop-down list and then select the LDAP connector you have defined earlier from the next drop-down list.

Having a LDAP connector and an user map, you can now configure the user authentication from the Routing and Authentication tab, by selecting LDAP Bind and the corresponding user map from the Authentication Type (applies to all services) panel, and save the configuration to finish the setup.

Here is an example of LDAP connector and its corresponding user map, according to specific data from this document:

• LDAP Connector

  LDAP Connector name: ldap

  LDAP Server Parameters

  IP / Hostname: ldap.cl.axilab.local

  Port: 389

  Server type: OpenLDAP

  Enable Clustered Operations: [x]

  Synchronization direction: Axigen to LDAP

  LDAP Search Parameters

  Use Administrative DN: (*)

  Admin DN: cn=admin,dc=domains

  Admin DN Password: secret

  Account base DN: ou=Users,o=%d,dc=domains

  Enable Group Synchronization: [x]

  Group base DN: ou=Groups,o=%d,dc=domains

  LDAP Routing Configuration

  Hostname attribute: axiHost

• User Map

  User Map name: usermap-ldap

  User Map type:

  • LDAP Bind
  • ldap

• Routing and Authentication -> Authentication Type (applies to all services)

  Perform LDAP Bind authentication using: usermap-ldap.

LDAP synchronization

In order to synchronize the accounts base, groups and various settings, you have to enable LDAP synchronization for each domain you define in Axigen. It is also necessary to create the domain in OpenLDAP prior to enabling the synchronization process.

SMTP routing

The SMTP service must have a special rule specifying that all the outgoing traffic directed for both local and remote domains, to be routed through the corresponding load balancer service, which in turn will route the connections to the proxy nodes in the front-end tier. In short, all the outgoing SMTP traffic must directed through the front-end nodes, not delivered directly to their destination mailboxes, even if they are located on the same back-end node.

Cleanup

you can safely stop the Axigen service and its related resources and continue with the cluster setup:

service axigen-axib1 stop
/sbin/ip -f inet addr del dev eth0 10.9.9.96
umount /var/clusterfs/axib1-{data,dom,lq}

Cluster configuration

Conga

Login

In order to start configuring your browser, type the Conga interface address into a browser: https://n1.cl.axilab.local:8084. Login using the admin username and the password you have previously set in the previous luci configuration section.

Cluster creation

After a successful login, the interface will show the Luci homebase page. Click on the cluster tab and then on the Create a New Cluster option from the left side menu.

Fill in all the nodes involved in the cluster, along with their root password. Then, select the Use locally installed packages option (we have already installed all the needed cluster packages), and deselect all of Enable Shared Storage Support (we are not using GFS and other shared storage specialized file systems), Reboot nodes before joining cluster (there is no need for this option). The last option Check if node passwords are identical should be checked only if all the nodes involved in the cluster have the same root password and checking it will leave editable only the first node's password, all the other password fields will be grayed out (disabled). Please use a proper naming for the cluster, like cluster-axigen.

Press the View SSL cert fingerprints and the informational panel should appear at the bottom of the page. Click the Submit button and confirm this action to begin the cluster creation. At the end, the cluster configuration will be displayed.

New cluster creation page	Fingerprint verification messages	Cluster creation confirmation	Cluster creation progress (node creation)
Cluster creation progress (Installed)	Cluster creation progress (Configured)	Cluster creation progress (Joined)	Cluster configuration page is displayed after creation

Fence devices

Next step is to configure the cluster fencing, by adding a fence device. To add a fence device, in the cluster name left menu, click on the Shared Fence Devices menu and choose the Add a Fence Device option from the expanded submenu. Then, choose your fence device from the drop down options list and configure its parameters accordingly. Name the shared fencing device properly, like fence-type, for example fence-apc for an APC Power Switch.

After you finish setting up parameters for the fence device, press the Add this shared fence device button. A confirmation window will appear. Confirming will show the progress screen for updating the cluster configuration.

Shared Fence Devices menu

Configuration for an APC Power Switch

Fence addition confirmation

Cluster configuration update progress

After adding the shared fence device, it must be attached for fencing all nodes. To achieve this, click on the Nodes option from the cluster name left menu and then on each node's entry form the Configure submenu. Clicking on the Manage fencing for this node link will open the node configuration page. Click the Add a fence device to this level link from the Main fencing method panel. From the drop-down list, select the shared fencing device you have previously configured, under the Use an existing fence device option. Fill in any additional parameters, like the switch port or anything else that is requested by the fencing device to recognize this specific node. Click on the Update main fence properties button, confirm the fence addition and wait for the cluster configuration to be updated.

Repeat this step for all the other nodes in the cluster.

Nodes list example	Node n1 configuration	Click on the Add a fence device to this level option	Select the previously configured fence device
Configure switch port	Confirm the addition	Wait until the configuration is updated	Node n2 configuration

Failover domains

This step consists in creating a failover domain for each pair of active/passive nodes, so that when the active node fails at some point, the passive node takes over the responsibilities. In order to create a failover domain, click on the Failover Domains entry from the cluster name menu and then on the Add a Failover Domain option.

Fill in the failover domain name, which should be tagged according to the naming conventions you have previously set up, prefixed with the failover- text, for example failover-axib1. Check the Prioritized and Restrict failover to this domain's members options and, if you want a failed node not to take back resources after a failover process, then you should also check the Do not fail back services in this domain option. This is usually a desired behavior, because failing back the service and its resources involves stopping and then starting the Axigen server, disconnecting active connections for the end-users.

From the Failover domain membership panel, select the two nodes which will be the active and passive ones in this failover domain and set them different priorities, with the preferred node having a lower priority number, thus a higher priority in running cluster services.

At the end, click on the Submit button, confirm the failover domain addition and wait until the cluster configuration is modified.

Repeat adding a failover domain for all active/passive nodes pair that will be part of the cluster.

Failover Domains menu

Configuration for failover-axib1

Pressing Submit will pop up the confirmation dialog

Wait until update completion

Resources

At this step you will add the following resources to the Axigen cluster:

• Floating IP address
• Storage mount
• Startup script

Each resource can be added by clicking on the Resources entry from the cluster name menu and then on the Add a Resource option. Then you must select the resource type from the drop-down list and configure it as explained below.

The IP address resource represents the failover domain floating IP address. Fill this IP address and check the Monitor link option. Click on the Submit button, confirm the resource addition and then wait for the cluster configuration to be completed.

Repeat adding an IP address resource for each failover domain.

Each shared storage partition must be configured as resources in the cluster. To achieve this, you have to add each one of them as File system resources. Naming a resource is also important in order to ease performing future cluster administrative tasks, so you have to choose their names to be self explanatory and consistent.

For example, all file system resources which are part of the axib2 failover domain can be prefixed with fs-axib2- followed by a short descriptive text. In our example storage configuration we have named the file system resources for the axib1 failover domain as follows:

1. Axigen data directory: fs-axib1-data
2. Axigen domains: fs-axib1-dom
3. Axigen logs and queue: fs-axib1-lq

Continue adding all the file system resources for all partitions that will be used in the cluster configuration.

The last resource type that must be added to the cluster is the init script, used to start and stop the Axigen daemon. Each Axigen instance (one per failover domain) should have its own init script resource. To add a script resource, select Script from the resource type drop-down list and fill in the full path of the init script, as you have previously set. The name of the script should be prefixed with script-, followed by the name of the failover domain and the -axigen literal text.

The script in our example corresponding to the axib1 failover domain will be called script-axib2-axigen.

Resources menu	IP address resource type selection	Configuration parameters for the IP address resource	Each resource addition must be confirmed
Wait until the IP address resource is being added to the cluster configuration	File system resource type selection	Configuration parameters for the File system resource	Wait until the File system resource is being added to the cluster configuration
Script resource type selection	Configuration parameters for the Script resource	Wait until the Script resource is being added to the cluster configuration

Services

Each failover domain should have a corresponding cluster service configured. In order to create a cluster service, navigate to the Services entry from the cluster name menu and then click on the Add a Service option. Name the service prefixed with service-, followed by the failover domain tag, for example service-axib1. Check the Automatically start this service and the Run exclusive options, and then select the corresponding failover domain and set the Recovery policy to Relocate.

Before creating the cluster service, you need to add its corresponding resources by pressing the Add a resource to this service button for the IP address resource, then create a dependency based tree by subsequently using the Add a child buttons for each of the File system resources. The last resource should be the Script resource, dependent of all the other ones successful startup. This way, no resource is being started without the previous one successful startup.

Pressing the Submit button will first ask for a service creation confirmation, and then automatically create the cluster service by modifying the cluster configuration.

After the service will be created, you will be redirected to the service management page. In order to test the service startup, choose the option to start the service on the first preferred node, confirm the start action, and wait for it to finish. After its successful startup on the preferred node, test if the service is indeed relocatable to the hot stand-by node from the same failover domain. For this, you need to choose from the service management action drop-down list, the Relocate this service to <hot stand-by node name> option. Confirm the relocation and wait for the job to finish.

You need to repeat adding a service for each failover domain in the cluster.

Services menu	Parameters for adding a service. Press the Add a resource to this service button after filling in all the required service configuration parameters	IP address resource	File system resource for Axigen data directory
File system resource for Axigen domains	File system resource for Axigen logs and queue	Last resource, the Axigen init script resource	Confirm the service creation
Full service configuration. Review it and press the Submit button	Wait until the service is being added to the cluster	Service management page with the service stopped	Start the service on the preferred node
Confirm service start	Wait for the service to be started	Service management page with the service started on the preferred node	Choose the service to be relocated on the hot stand-by node
Confirm the relocation	Wait until job completes	Service management page with the service started on the hot stand-by node

Quick example

This section shows a step by step quick configuration example of a cluster based on Axigen and Red Hat Cluster, without additional explanations, using the data from the example configuration section and the Conga cluster administration interface.

• cluster -> Create a New Cluster

  Cluster Name: cluster-axigen

  Node hostnames:

  • n1.cl.axilab.local
  • n2.cl.axilab.local
  • n3.cl.axilab.local
  • n4.cl.axilab.local

  Use locally installed packages: (*)

  Enable Shared Storage Support: [_]

  Reboot nodes before joining cluster: [_]

  Check if node passwords are identical: [_]

  -> View SSL cert fingerprints

  -> Submit

• (cluster-axigen) -> Shared Fence Devices -> Add a Fence Device

  Fencing Type: APC Power Switch

  Name: fence-apc

  IP Address: 10.9.9.99

  Login: fenceadm

  Password: <password here>

  -> Add this shared fence device

• (cluster-axigen) -> Nodes -> Configure -> n1.cl.axilab.local

  Main Fencing Method -> Add a fence device to this level

  Use an existing Fence Device -> fence-apc (APC Power Switch)

  Port: 1

  -> Update main fence properties

• (cluster-axigen) -> Nodes -> Configure -> n2.cl.axilab.local

  Main Fencing Method -> Add a fence device to this level

  Use an existing Fence Device -> fence-apc (APC Power Switch)

  Port: 2

  -> Update main fence properties

• (cluster-axigen) -> Nodes -> Configure -> n3.cl.axilab.local

  Main Fencing Method -> Add a fence device to this level

  Use an existing Fence Device -> fence-apc (APC Power Switch)

  Port: 3

  -> Update main fence properties

• (cluster-axigen) -> Nodes -> Configure -> n4.cl.axilab.local

  Main Fencing Method -> Add a fence device to this level

  Use an existing Fence Device -> fence-apc (APC Power Switch)

  Port: 4

  -> Update main fence properties

• (cluster-axigen) -> Failover Domains -> Add a Failover Domain

  Failover Domain Name: failover-axib1

  Prioritized: [x]

  Restrict failover to this domain's members: [x]

  Do not fail back services in this domain: [_]

  (Failover domain membership)

  • n1.cl.axilab.local

    Member: [x]

    Priority: 1

  • n2.cl.axilab.local

    Member: [_]

  • n3.cl.axilab.local

    Member: [_]

  • n4.cl.axilab.local

    Member: [x]

    Priority: 10

  -> Submit

• (cluster-axigen) -> Failover Domains -> Add a Failover Domain

  Failover Domain Name: failover-axib2

  Prioritized: [x]

  Restrict failover to this domain's members: [x]

  Do not fail back services in this domain: [_]

  (Failover domain membership)

  • n1.cl.axilab.local

    Member: [_]

  • n2.cl.axilab.local

    Member: [x]

    Priority: 1

  • n3.cl.axilab.local

    Member: [_]

  • n4.cl.axilab.local

    Member: [x]

    Priority: 10

  -> Submit

• (cluster-axigen) -> Failover Domains -> Add a Failover Domain

  Failover Domain Name: failover-ldap

  Prioritized: [x]

  Restrict failover to this domain's members: [x]

  Do not fail back services in this domain: [_]

  (Failover domain membership)

  • n1.cl.axilab.local

    Member: [_]

  • n2.cl.axilab.local

    Member: [_]

  • n3.cl.axilab.local

    Member: [x]

    Priority: 1

  • n4.cl.axilab.local

    Member: [x]

    Priority: 10

  -> Submit

• (cluster-axigen) -> Resources -> Add a Resource

  Select a Resource Type: IP address

  IP address: 10.9.9.96

  Monitor link: [x]

  -> Submit

• (cluster-axigen) -> Resources -> Add a Resource

  Select a Resource Type: IP address

  IP address: 10.9.9.97

  Monitor link: [x]

  -> Submit

• (cluster-axigen) -> Resources -> Add a Resource

  Select a Resource Type: IP address

  IP address: 10.9.9.98

  Monitor link: [x]

  -> Submit

• (cluster-axigen) -> Resources -> Add a Resource

  Select a Resource Type: File system

  Name: fs-axib1-data

  File system type: ext3

  Mount point: /var/clusterfs/axib1-data

  Device: /dev/disk/by-uuid/bd537993-d78a-4bf9-acf7-ed0993edbafb

  Force unmount: [x]

  Reboot host node if unmount fails: [x]

  Check file system before mounting: [_]

  -> Submit

• (cluster-axigen) -> Resources -> Add a Resource

  Select a Resource Type: File system

  Name: fs-axib1-dom

  File system type: ext3

  Mount point: /var/clusterfs/axib1-dom

  Device: /dev/disk/by-uuid/4407d04d-f48a-456b-b3f4-11a8d0f6e254

  Force unmount: [x]

  Reboot host node if unmount fails: [x]

  Check file system before mounting: [_]

  -> Submit

• (cluster-axigen) -> Resources -> Add a Resource

  Select a Resource Type: File system

  Name: fs-axib1-lq

  File system type: ext3

  Mount point: /var/clusterfs/axib1-lq

  Device: /dev/disk/by-uuid/59efb5e6-bf85-4486-ac75-57e2b40c2e78

  Force unmount: [x]

  Reboot host node if unmount fails: [x]

  Check file system before mounting: [_]

  -> Submit

• (cluster-axigen) -> Resources -> Add a Resource

  Select a Resource Type: File system

  Name: fs-axib2-data

  File system type: ext3

  Mount point: /var/clusterfs/axib2-data

  Device: /dev/disk/by-uuid/fc8a4bae-df23-421a-a6c7-de55fbf99a8c

  Force unmount: [x]

  Reboot host node if unmount fails: [x]

  Check file system before mounting: [_]

  -> Submit

• (cluster-axigen) -> Resources -> Add a Resource

  Select a Resource Type: File system

  Name: fs-axib2-dom

  File system type: ext3

  Mount point: /var/clusterfs/axib2-dom

  Device: /dev/disk/by-uuid/2b1c992b-7385-40c8-bad6-a91dfb85c715

  Force unmount: [x]

  Reboot host node if unmount fails: [x]

  Check file system before mounting: [_]

  -> Submit

• (cluster-axigen) -> Resources -> Add a Resource

  Select a Resource Type: File system

  Name: fs-axib2-lq

  File system type: ext3

  Mount point: /var/clusterfs/axib2-lq

  Device: /dev/disk/by-uuid/f896a8aa-3bbd-43dc-8ea9-35ac2c79359b

  Force unmount: [x]

  Reboot host node if unmount fails: [x]

  Check file system before mounting: [_]

  -> Submit

• (cluster-axigen) -> Resources -> Add a Resource

  Select a Resource Type: File system

  Name: fs-ldap

  File system type: ext3

  Mount point: /var/clusterfs/ldap

  Device: /dev/disk/by-uuid/28a715bb-8b1d-4acd-959f-a67328f04d16

  Force unmount: [x]

  Reboot host node if unmount fails: [x]

  Check file system before mounting: [_]

  -> Submit

• (cluster-axigen) -> Resources -> Add a Resource

  Select a Resource Type: Script

  Name: script-axib1

  Full path to script file: /etc/init.d/axigen-axib1

  -> Submit

• (cluster-axigen) -> Resources -> Add a Resource

  Select a Resource Type: Script

  Name: script-axib2

  Full path to script file: /etc/init.d/axigen-axib2

  -> Submit

• (cluster-axigen) -> Resources -> Add a Resource

  Select a Resource Type: Script

  Name: script-ldap

  Full path to script file: /etc/init.d/ldap

  -> Submit

• (cluster-axigen) -> Services -> Add a Service

  Service name: service-axib1

  Automatically start this service: [x]

  Enable NFS lock workarounds: [_]

  Run exclusive: [x]

  Failover Domain: failover-axib1

  Recovery policy: Relocate

  -> Add a resource to this service

  Use an existing global resource -> 10.9.9.96 (IP address)

  -> Add a child

  Use an existing global resource -> fs-axib1-data (File system)

  -> Add a child

  Use an existing global resource -> fs-axib1-dom (File system)

  -> Add a child

  Use an existing global resource -> fs-axib1-lq (File system)

  -> Add a child

  Use an existing global resource -> script-axib1 (Script)

  -> Submit

• (cluster-axigen) -> Services -> Add a Service

  Service name: service-axib2

  Automatically start this service: [x]

  Enable NFS lock workarounds: [_]

  Run exclusive: [x]

  Failover Domain: failover-axib2

  Recovery policy: Relocate

  -> Add a resource to this service

  Use an existing global resource -> 10.9.9.97 (IP address)

  -> Add a child

  Use an existing global resource -> fs-axib2-data (File system)

  -> Add a child

  Use an existing global resource -> fs-axib2-dom (File system)

  -> Add a child

  Use an existing global resource -> fs-axib2-lq (File system)

  -> Add a child

  Use an existing global resource -> script-axib2 (Script)

  -> Submit

• (cluster-axigen) -> Services -> Add a Service

  Service name: service-ldap

  Automatically start this service: [x]

  Enable NFS lock workarounds: [_]

  Run exclusive: [x]

  Failover Domain: failover-ldap

  Recovery policy: Relocate

  -> Add a resource to this service

  Use an existing global resource -> 10.9.9.98 (IP address)

  -> Add a child

  Use an existing global resource -> fs-ldap (File system)

  -> Add a child

  Use an existing global resource -> script-ldap (Script)

  -> Submit