Frequently asked questions about Clustering in ITA Secure Messaging What is clustering? What are the key concepts? How do I setup clustering? What are the requirements for the clustering? What happens if the master server goes down? What happens if one of the slaves go down? Where are the quarantined emails stored? Which machine do I connect to access the Admin Console What is clustering? Clustering in ITA Secure Messaging provides scalability and high availability by utilizing more than one physical machines that act as one. This type of configuration is suitable for large enterprises and ISPs getting millions of messages on daily basis. Refer to the picture below. In this example four machines accept incoming emails for the enterprise. Although emails are filtered at four different locations, all of them can be administered through one central management console that runs on the "Master" server. Key Concepts Cluster - Master One of the machine in the cluster must run as a Master. This is the machine that administrators and users connect to through ITA Secure Messaging Admin Console. You can check the staus of every other machine within the cluster from this machine. If you change a rule in the Master that change is pushed to every slave server automatically. Besides keeping track of activities on other slave server, a master server can also accept and send emails to the Internet. Cluster - Slave Slave server process inbound and outbound messages and send statistics to the master server. Typically, you don't connect to a Slave servers Admin Console as every thing is done through the master. When a slave server comes up, it pulls the rules from the master server and starts accepting inbound emails. The actual processing of the message is done at the slave server. All quarantined email messages are also saved on slave's hard disk. However, the file names are sent to the master server, which get displayed through View Messages on the master. How do I setup Clustering Follow the steps below to setup clustering Install ITA Secure Messaging on ALL the machines that will take part in the cluster Designate one machine as master and the rest as slaves Log into Admin Console and click on "Cluster Mgmt" Select "Enabled - Master" on the master machine and "Enabled - Slave" In case of Master, the phrase "Bind IP" refers to the IP address which will be used by slave machines to connect to In case of Slave, provide the IP address of the master server Once done, click the "Switch Configuration" button What are the requirements for the clustering High speed network between the cluster machines. We recommend at least 10 mbs Minimum 512 Ram on the master, 2 GB recommended. Any operating system including Windows, Linux, Solaris, Max OS X, FreeBSD and others. What happens if the master server goes down? If the master server goes down for any reason slaves stay up and keep processing emails normally. However, every slave sends data to the master for reporting purposes. This data will sit in a queue until the master comes back up. Slaves will automatically detect the master when it comes back up and will flush its queue. What happens if one of the slaves go down? In this case the master server simply unregisters the dead slave and continues working with other slave machines in the cluster. The dead slave will automatically connect back to the master once it comes back up. Where are the quarantined emails stored? Every message regardless of its category are stored on the individual slave machines. However, the file names are sent to the master server. Messages are fetched on demand by the master when a user wants to look at its contents. Which machine do I connect to access the Admin Console? There are different type of configuration in ITA Secure Messaging. Refer to the table below to see how these settings are changed. Configuration Type Location Explanation Server configuration Individual Servers Every configuration parameter that is accessible via "Modify Configuration" menu is a server wide configuration. This is where you define IP address and ports for your corporate email server and other settings. The reason why these settings are not handled by clustering is to allow you to configure each individual slave differently, which gives a lot more flexibility than configuring every machine identically. Rules modification Master only Any settings that is accessible through "Modify Filters" screen should only be accesses through the master server. When any rule is modified, the master synchronizes these rules with every slave server running within the cluster. You should never modify rules on a slave server. View/Restore Messages Master only Regardless of which slave server the original email is sent, master server will always know about it. Therefore, you should always connect to the master server to view messages. Run Reports Master only Similar to view/restore messages, all report data is collected by the master server. Therefore, you should run reports only on the master server. Running reports on a slave may not return correct data.