The consequences of having your communication systems disrupted, even for a short period of time can have a significant impact on your business. If your Fax Server is unavailable the business users and applications cannot send faxes and you are unable to receive faxes from the outside world.

Alerts
Alerts and server management tools are critical to ensuring an immediate decision can be made when a server, a board or the Telco lines fail. Is the failure permanent or is it just a temporary network problem outside the server’s control?

MESSAGEmanager provides a large range of alarm and alert mechanisms to monitor the health of the system and its network connections. SNMP and SCOM can be used to monitor these same conditions.

Virtual Solutions
One of the most important benefits of virtualisation is the mobility of virtual machines. An entire application and operating system environment can be encapsulated in a virtual machine and then moved from machine to machine, migrated without downtime and replicated to disaster recovery sites.

With MESSAGEmanager Fax Server Software in a virtual environment such as Hyper-V, VMware, Cisco Unified Computing System Express and Citrix XEN you can automate Fax Server High Availability (HA) and Disaster Recovery Fault Tolerance (DR) processes. This ensures rapid and cost-effective resolution of Fax Server outages by configuring the virtual environment to automatically relocate the IP Fax software from one host to another should an outage occur.



Where there is a single data centre and HA is available, only one licensed copy of MESSAGEmanager is necessary for the server to be immediately replicated on failure.

Where there are multiple data centres, the MESSAGEmanager licensing and DR architecture depends on the clustering, replication and availability between the data centres. No additional license fee is required in DR Fault Tolerant Configurations for the secondary and subsequent instances of MESSAGEmanager provided they are only used for archival or backup purposes.

Non Virtual Environments
In fax board configurations virtual availability and disaster recovery processes are not available.

MESSAGEmanager data structures are stored in SQL databases containing transmission and receive files and details. User information is obtained from corporate databases such as Active Directory or the Notes Address book. This avoids having to synchronise or maintain user information in the MESSAGEmanager SQL user database which is available as an alternative.

MESSAGEmanager can be configured with multiple Fax Servers in geographically separate locations to provide an Active/Active Disaster Recovery, Redundancy/Failover option and Load Balancing. Alternatively sites can use a single active server with a “cold” standby server providing Active/Standby Disaster Recovery and Redundancy.

To mitigate hardware failures, resilient PC hardware options such as RAID, should also be considered.

In a DMZ environment there is limited network access for the MESSAGEmanager Servers so they must run independently of a network that supports clustering or SAN (unless provided specifically for the MESSAGEmanager Servers). In this environment the SQL databases are replicated across the servers.

Architectures
Messages submitted to MESSAGEmanager are stored in the outbound queue with a pending status. When the message has been sent or the retries have been completed, the message status is updated with sent or failed and the reason for the failure.

When the message is completed, the archive database is updated with the details. Queue data is purged after the optional purge period and archive data is usually purged over a much longer period.

If the queues and archive databases are stored locally, the information may be lost if the server hosting the service is lost. To avoid this, we recommend mirroring, replication to another server or storing the databases on the network on a high availability server such as a clustered server or a storage area network (SAN). Should the server hosting the service fail, another server (active or standby) can take over its message queues, whilst the failed server is rebuilt.



Configurations

Active/Active
Active/Active architecture is where each server operates equally as a production server in separate networked locations with the Global Routing Module managing Load Balancing and Least Cost Routing. In case of failure, the alternative server(s) continue(s), albeit at reduced capacity and new messages are only delivered to the working server(s).

• Capacity is reduced by the number of channels on the failed server.
• Global Routing will ensure no messages are delivered to ‘down server’ and the administrator is notified of the server’s problem.
• The IP Gateway will detect the failure and not route any inbound calls to that server. If all channels are busy on the remaining server, a busy error will be received by the gateway.
• Depending on the sending application, failover can be automatic.
• The archive database should be shared on a remote SQL server and is not affected by outage – all results are posted as they occur. If a server goes offline the archived information is still available.
• The queue databases may be affected as follows:
• Queues on a local SQL server: If the hard disk with local queues is lost, then unnotified messages will need to be requeued by the users/application. Unrouted received messages will need to be manually routed from the archive database by the administrator. A record of completed outbound and received messages is available in the archive database and users can query on those messages.
• Queues on an external SQL server: If the queues are stored on a remote SQL server, the working server can take over the messages from the failed server. Note that if the queues are accessed over the network, MESSAGEmanager will be unable to accept, send or receive fax messages if the network is inaccessible or the external SQL server fails.

• The standby server must be manually “enabled” to take over the function of the failed active server, for example, switched on or services started up.
• The archive database should be shared on a remote SQL server and is not affected by outage – all results are posted as they occur. If a server goes offline the archived information is still available.
• The queue databases may be affected as follows:
• Queues on a local SQL server: If the hard disk with local queues is lost, then unnotified messages will need to be requeued by the users/application. Unrouted received messages will need to be manually routed from the archive database by the administrator. A record of completed outbound and received messages is available in the archive database and users can query on those messages.
• Queues on an external SQL server: If the queues are stored on a remote SQL server, the standby server can take over the messages from the failed server. Note that if the queues are accessed over the network, MESSAGEmanager will be unable to accept, send or receive fax messages if the network is inaccessible or the external SQL server fails.
• When the Active server is restored to normal operation, the standby server must be “disabled”.