MailEnable Enterprise Edition supports clustering of two or more servers. Clustering support is allows you to add additional servers to your configuration as demand for resources increases, and also can allow for hardware failure in a server.
MailEnable stores all system data in a shared storage repository. Server specific information is stored in the Windows Registry (such as details about which IP addresses a service is bound to). This means that it is possible to install multiple server nodes and point them at the same storage repository.
There are two basic configurations for clustering MailEnable servers. These are referred to as a "Controller and Slave Cluster" configuration, and a Shared Storage Cluster".
A "Controller and Slave Cluster" involves a single MailEnable server that hosts a large storage array. This server is configured to share its storage for other "Slave" servers to access. While this configuration spreads the load on the services, failure of the controller will prevent any connected slaves from working.
The second model is referred to as a "Shared Storage Cluster". This cluster
has all MailEnable servers configured to access a shared storage device
(eg: NAS/SAN/DAS), and is the preferred method to clustering the
MailEnable Enterprise and Premium Editions provide a wizard within the MailEnable Management Console that allows you to cluster two or more MailEnable Servers.
Cluster Management can be found within the MailEnable
Management Console under the properties of the Messaging Manager node.
The "Cluster" tab allows you to configure whether an individual
server is a standalone server, cluster controller or a server that is joined to
another cluster controller. This utility will create the necessary file
system share and modify MailEnable’s configuration depending on the mode
selected for the server. MailEnable services will need to be restarted after
making changes to the clustering.
A cluster controller is a server which has a hidden share called MAILENABLE$. This share needs to have both the configuration and data paths as a subdirectory, so the server must not have separate paths set for this. For example, in a default installation of MailEnable, this would be C:\Program Files\Mail Enable. By setting the server as a cluster controller, the hidden share will automatically be created.
A cluster member is a server that points its data and configuration storage at another server that is a cluster controller. By enabling a server as a cluster member, the necessary paths are altered and all the MailEnable services are optionally set to run under the IME_ADMIN Windows user account. The IME_ADMIN users on all servers must have the same password. If you do not know the password for IME_ADMIN, then you can use the MEInstaller.exe application (under the Mail Enable\bin directory) to reset this password on any MailEnable cluster nodes.
To remove the server from a cluster, or to prevent a server from being a cluster controller, select the option for the server to be standalone and apply the changes.
To make the changes, select the option that best describes this server. If the server is member server, ensure that it is configured to point to the appropriate controlling server before clicking the apply button.
A Shared Storage Cluster involves pointing all MailEnable servers at a single storage location. This storage location could be a drive mapped to a SAN, a Shared Storage array or a UNC path to a Network Storage Device.
If the shared storage device is a NAS device, then it will either have its own Network Operating System (Windows or Unix/Samba/NFS) or it can be joined to a security realm or Windows Domain so that you can use accounts to secure directories. It is important that the shared storage allows IME_ADMIN and IME_SYSTEM full control. This typically means configuring these user accounts on the NAS with the same passwords as on all MailEnable member servers.
It is also important that any network paths are mapped via UNC rather than mapping a drive letter within a user session. This is because the drive mapping will not be known by services when they are running under the service control manager (ie: when they are running as services rather than when a user is logged in). A common mistake is to map a drive (for example X:) to a UNC path and then to use that drive when installing MailEnable. In this case, a potential problem is that when MailEnable services run under their system accounts, the X: will not exist.
Install a MailEnable server under this configuration is done by running the installation process. During installation you will be asked for three paths. The first path is to the MailEnable Application Directory. For this you select a local path. This is where the program files will be installed to. The second path asked for is the Configuration Repository. For this path, select a shared storage location. The third path asked for is the Message Store Repository. You should also select the shared storage location for this. Do the same for any other nodes that you add to the cluster. If you have previous installed MailEnable on the server you cannot change the path through installation, you need to use the administration program to select the new configuration and message store path. This is done by running the administration program, right clicking the Messaging Manager icon and selecting Properties from the popup menu.
It is very important that when MailEnable services run that they are able to access the shared volume. As mentioned earlier, you need to consider that MailEnable services run under local Windows accounts (IME_ADMIN and IME_SYSTEM), and both these accounts will need to access the shared storage.
By load balancing and clustering front-end servers (IIS, SMTP, POP, IMAP, etc.) the system can scale out easily from the front-end perspective. Ideally, there would be a single file service (probably network attached storage or a SAN) and point all the MailEnable servers to the same post office/configuration repository. This means that SMTP, POP or MTA servers can be added as required and IP load balancing can be used to provide a clustered IP address. All services can be run on all the servers, as they handle the sharing of the data and configuration files. It is recommended to allow RPC between the servers for IMAP notifications.
The Professional Edition of MailEnable experiences latency issues (for login and message routing) where a single implementation or site contains more than 20,000 users. MailEnable Enterprise Edition overcomes this issue by providing Enterprise Database configuration providers (rather than tab delimited files).
You need a license for each server you are installing the software onto. For ActiveSync licensing you only need the one license for the cluster. Contact our sales persons if you are purchasing two or more Enterprise licenses, as discounts apply.
The most common issue with configuring a clustered environment by far is configuring permissions on shared storage locations, and ensuring that the services running on the members have access to these locations. In order to test whether your cluster is configured correctly, you should use the managment console to create a new mailbox and verify that the mailbox exists when you attempt to access the management console from another server.
Assuming all your cluster members are able to configure the server via the management console, then you should verify that you are able to send and receive messages through MailEnable. If you are not able to do so, then you could run the services in debug mode to verify that the problem is related to the identity that the service under unattended execution. The MailEnable Knowledge Base has details on how to configure services to run in debug mode.
How to configure MailEnable web mail on a different server: Article ME020070
Postoffice connector not delivering messages when using external storage: Article ME020649
|Class:||HOWTO: Product Instructions|
|Created:||19/03/2002 8:18:00 PM|
|Revised:||Tuesday, January 14, 2020|