Global Mailbox deployment considerations

When deploying Global Mailbox, you must consider a few items due to various factors such as, limitations of the supported topology and limitations of the components supporting Global Mailbox.

The supported topology, including the specified number of nodes, for Global Mailbox deployment is across two data centers. Deviation from the specified topology might have some major consequences to replica count, consistency levels, and fault tolerance. You must install and configure all data centers and nodes before implementing any operations.
Restriction: To avoid unwanted implications as a result of changing consistency configuration, consistency settings are hardcoded and must not be changed. For more information see, Default consistency settings in Global Mailbox. If there is an unavoidable requirement to change the consistency level, contact IBM support.
Following is a list of items you must consider when deploying Global Mailbox:
  • Cassandra must have an equal number of nodes in each data center.
  • Default replication setting in Global Mailbox is delayed (asynchronous). However, based on your requirements for fault tolerance, performance, and availability, you can modify the replication setting. When you modify the replication setting, the default consistency setting is also modified automatically. For more information, see High availability properties and limitations of Global Mailbox.
  • Immediate and delayed replication types have their own trade-offs. For more information, see Message replication configuration trade-offs.
  • Run Cassandra repairs on a regular basis. There is a window between when something is deleted and when the system actually cleans up the data that is marked for deletion. The compaction process removes the item marked for deletion, but repairs must happen more frequently than compaction. If compaction happens first, deleted objects might come back to life when they must not. If you are reducing the compaction interval, you must run repairs more frequently. For more information, see Maintaining performance with Apache Cassandra.
  • Given that Cassandra is extremely sensitive to time stamps in synchronizing operations across nodes, it is imperative that the time on machines containing Cassandra nodes be kept in tight synchronization. To accomplish this, you must make sure that NTP (network time protocol) is configured and running on each of these node machines. It is most important that the node machine times are kept in sync with each other versus the absolute time. For more information, see Synchronizing time across Cassandra nodes.
  • Ensure data directories for Cassandra and ZooKeeper are on high speed disks and that these disks are used only for the data directories and not the operating system files.
  • Ensure there is a reliable, high speed network between data centers. The network must be able to support the file volume and size expected. If it is not fast enough or has too much latency, replication might not happen fast enough, leading to an increase in processing time.