The answers to some of the questions regarding SEG Clustering and the troubleshooting steps to follow in case of an error are listed here.

How to enable SEG clustering?

You can enable SEG clustering while configuring SEG with the Secure Email Gateway Setup Wizard. In the SEG Setup Wizard:

  1. Enter the setup details in the Setup page and select Next.
  2. Enter the configuration settings details in the Configuration page and select Next. The Cluster Configuration page appears.
  3. To know the setup details and configuration settings that must be entered, see steps 1-3 of Configure the Classic Platform with the Setup Wizard.

    SEG Install 16

  1. Select the Enable SEG Clustering check box.
  • Specify the name you want to assign to the cluster in the Cluster Directory Name field.

  • Define the default port for the SEG servers to communicate with each other in the Default Port field.
  • Specify the host name of each SEG server in the cluster in the Node Address field.
  • Select Next when complete.

What is the app cluster directory XML?

The AppClusterDirectory.xml file (located in the same directory as the AW.Eas.IntegrationService.exe service) is created upon successful completion of the SEG setup process when clustering has been enabled. During the initial configuration, the first entry in the AppClusterDirectory.xml file is the master SEG. This file references other servers in the cluster, and is of the form as shown below (change node address, name & port as needed):

                  
                  

<?xml version="1.0"?>

<applicationClusterDirectory name="Secure Email Gateway" port="9090">

<node address="servername1" name="seg@servername1" />

<node address="servername2" name="seg@servername2" />

</applicationClusterDirectory>

The value “name” in the initial applicationClusterDirectory tag reflects the name of the cluster as defined during configuration, and any changes to this will be reflected in different clusters being created. For example, if SEG1 is a member of SEG Cluster name= “SEG1” and SEG2 is a member of SEG Cluster name= “SEG2”, these two SEGs will never initiate communication.

Note:

The value "name" will not be updated if a new SEG server is elected master.

What happens if the master SEG goes down?

If the master SEG goes down, all other SEGs in the cluster initiate a 'voting process' to elect a new master SEG. This process is initiated after the SEGs miss the maximum number of 'heartbeats' from a particular server; in this case the master SEG server. Once a new master is chosen, the cluster has successfully recovered and functionality returns to a steady state for all SEGs that are in active communication.

At this point, though the master SEG is not shown in the first position in the AppClusterDirectory.xml file, the EAS Integration service logs that a new master has been chosen and specify that SEG.

If a slave server goes down, it is removed from the cluster, and the slave server stops receiving or sending updates to the other members of the cluster.

How should the SEGs be re-clustered in the event the cluster breaks?

Clustering issues are typically seen when communication between the SEG servers is broken. In such scenarios, perform the following steps:

  1. Verify if the EAS Integration Service is configured properly for clustering on all servers.

    • EAS Integration Service Config file (\AW.Eas.IntegrationService\AW.Eas.IntegrationService.exe.config):

      • In the configSections section, the cacheConfiguration field should be set equal to 'Clustered'.

      • <clusterConfiguration nodeAddress="servername1" nodeName="seg@servername1" directoryLocation="AppClusterDirectory.xml"
                                         sharedKey="AirWatch"/> <cacheConfiguration cacheType="Clustered" />
                                         
                                         
                                         
                                      
  2. Choose one of the SEG servers to be the master SEG.
    • Verify cluster name and port details of the chosen SEG in the AppCluster Directory.xml
    • Add the node address of the chosen SEG in the AppCluster Directory.xml. This should be the only node listed in the AppCluster Directory.xml.
  3. Restart the EAS Integration Service for the chosen SEG server. This SEG server now becomes the master node.
    • Verification - In the Integration service log file for this SEG server, verify if this server joins the cluster as the Master.
  4. For all the other SEG servers:
    • Verify cluster name and port details in the AppCluster Directory.xml

    • Configure the AppClusterDirectory.xml identical to the master SEG. This means the AppClusterDirectory.xml of other SEG servers should only show the master SEG listed in it.
  5. Restart the EAS Integration Service for the other SEG servers in the cluster.
    •  These SEG servers now act as slave nodes and seeks the master node. The AppClusterDirectory.xml lists the information of the master SEG and the slave SEG servers.
    • Verification:
      • In the Integration service log file for each SEG server, verify if the server joins the cluster as a Slave server.
      • Verify if the AppClusterDirectory.xml is updated with information regarding all servers in the cluster, with the Master node on top of the server list.

Monitoring the cluster

After re-clustering the SEGs:

  1. Monitor if the AppClusterDirectory.xml is identical across all SEG nodes.
  2. Monitor the Integration service log files for each SEG server to check if any errors pertains to the following:

    • Communication errors between the SEG servers.

    • Policy update errors (perform a manual update of policies from the SEG Console or AirWatch Console).

  3. Enter the command netstat -an | find "9090" to return a listener for both TCP and UDP.

What is the best practice for upgrading clustered SEGs?

To ensure the cluster is stable post upgrade, stop the integration service on all SEGs, then start the integration service on each SEG one by one (beginning with the first node in the AppClusterDirectory.xml). After starting the service on each SEG, check EAS Integration Service Logs (Verbose) to ensure the SEG joins the cluster. See How should the SEGs be re-clustered in the event the cluster breaks? for more detail.

Note:

While the integration service is not running, SEG falls back to the default setting in the Web Listener web.config file.

Compare SEG Policies

The Device Policies feature provides troubleshooting of clustered SEGs.

From the SEG Console (localhost), you can download a file listing all devices that the SEG allows for email receipt. You can compare this list between the clustered SEGs to determine if the device policy sets are in line with one another.

  1. Login to the SEG server and navigate to 'http://localhost/segconsole'.
  2. Select Export Device Policies from the Device Policies section. The .csv file gets downloaded to the default location.
  3. Select OK.