Server and Hardware Configuration Considerations
Table of Contents
- Server Roles
- Configuration Options
- Hardware Scaling Approach
- Environmental Considerations
- Additional Configuration Notes
Momentum is deployed as several distinct “roles”, each providing different functionality of the Momentum Solution. The available roles are:
MTA - Supports all Message delivery functionality including Adaptive Delivery. Optionally, also supports Message Generation.
Platform DB - Stores all templates, recipient lists, and generation task data.
Event Hose – Distributes all system events to the Analytics node and Webhook subscriptions.
Analytics DB – Stores aggregated data of all system events delivered by the event hose.
Web User Interface – Provides graphical reporting summaries, template editing and management, recipient list storage management, and authentication key generation and management.
HTTP Proxy Service - Supports all REST API including message generation, administration, and metrics (reporting) functions.
Momentum enables you to create standardized cluster configurations with hardware specifications appropriate for different levels of messaging capacity. You can deploy Momentum in multiple configurations to meet specific performance and operational requirements. Consult with your Message Systems account team to address requirements not covered here.
Although you can deploy hardware capable of processing over five million messages per hour, it is not cost effective to do so if that volume level is not required. This section will provide guidance on deploying the appropriate level of hardware resources to support different volume levels.
Momentum can send very high volumes of traffic; however, it can be constrained by external systems in the deployment environment, such as network throughput. You should consider the impact of Momentum traffic volumes on your environment.
External Network Bandwidth
You must consider the total bandwidth required to support your traffic volumes. A single node can readily saturate a one Gbps Network Interface Card (NIC). This is accounted for in the configurations specified below. It is also important to consider the total volumes of the entire cluster. It is possible to saturate a one Gbps network. It should also be noted that larger message sizes saturate available network bandwidth more quickly than smaller message sizes. Depending upon your expected message size, this can be an extremely important consideration when calculating rough estimates of required network bandwidth.
Momentum’s queuing architecture allows delivery over hundreds or even thousands of parallel connections. Furthermore, Adaptive delivery rules allow for multiple parallel connections to receiving ISPs. Momentum takes full advantage of parallel connections to maximize delivery throughput. Firewalls need to support high connection volumes and bandwidth requirement of the total volume. Additionally, the firewall should not be stateful as firewalls are not able to keep up with the session management.
When sending transactional or SMTP traffic into Momentum, the injection network must match the bandwidth of the external network.
Momentum writes a copy of every message to the spool disk to assure no loss of messages. Sending at high volumes requires sufficient disk IOP capacity, particularly for the spool disk. Message Systems recommends the use of ext4 file systems. You can also use SANs or network attached file systems; however, these storage options introduce additional network IO and latency that can degrade performance. Make sure you account for this additional network traffic or consider a separate network for the storage components.
Momentum is a memory and CPU intensive application. For optimal performance, the system memory must operate at 1866 MHz or faster.
Ensure that you are running on a kernel that is 2.6.18-194 or newer. This will help you avoid bugs that were found in previous Linux kernels related to Broadcom NICs. Also, if you build custom kernels, review RedHat bug numbers 587799 and 581148 for more information.
Momentum does not require the creation, modification or access times on either the data or metadata files to be correct (or maintained). So mounting a volume with the noatime mount option will greatly reduce the number of unnecessary disk accesses. The spool array should be formatted using either the ext2 or ext4 file system. ext2 and ext4 have comparable performance, with ext4 being considered more reliable (because of journaling). ext3 can slow down performance, so is not recommended. Set the following options in your fstab:
LABEL=/var/spool/ecelerity /var/spool/ecelerity ext2 rw,noatime 0 2
LABEL=/var/spool/ecelerity /var/spool/ecelerity ext4 rw,noatime,barrier=0 0 2
RAID Arrays should be configured only in RAID1 or RAID10 configurations. The Momentum software maintains a very high write load that is not suitable for a RAID5 array; therefore, RAID5 is not supported.
Momentum performance testing is executed on physical (non-virtualized) servers. If you run Momentum in Amazon Web Services (AWS) or OpenStack environments, or in other common virtualized environments such as VMware, you should plan for a potential loss of 20% - 30% in performance.