This chapter describes how to plan for installing the Oracle Communications Messaging Server Cassandra message store.
Apache Cassandra is a free and open-source NoSQL database designed for:
Large amounts of data
Use on commodity Linux servers
Continuous read/write availability
High availability with no single point of failure
Multiple data centers to ensure constant uptime
For more information, see the Apache Cassandra documentation.
In Messaging Server, the Cassandra message store consists of keyspaces. A keyspace, in a NoSQL data store, is a namespace that defines data replication on nodes. (It resembles the schema concept in Relational database management systems.) The Messaging Server Cassandra message store consists of the following keyspaces:
ms_msg: Contains the email message content. It can be very large.
ms_mbox: Contains user and mailbox metadata. It is relatively small and has a lot of mutations.
ms_cache: Contains cache tables for converted message content.
After Messaging Server has been installed and configured, the Cassandra message store keyspaces are created on one or more data centers once the Messaging Server stored processes start for the first time. When deploying the Cassandra message store, the recommendation is to use multiple Cassandra clusters. See "Understanding the Cassandra Message Store Architecture" for more information.
Apache Cassandra is the database platform hosting the Cassandra message store and Elasticsearch is the indexing and search engine.
The following component is Oracle extensions to Elasticsearch , which is open source software. This extension is packaged and with Messaging Server:
Indexed Search Converter (ISC): Deployed as a standalone web application, the ISC processes the entire message body—headers, attachments, and plain text body—and generates plain text content for each of the message parts. It stores this converted content in a persistent Cassandra cache table, which is later indexed in Elasticsearch cluster. The cache enables the ISC to avoid processing the same contents and attachments multiple times (for example, when there are multiple recipients, email forwards, and so on).
You must deploy the ISC on the message access tier hosts.
Email messages have two paths to the Cassandra message store:
Messages that arrive through LMTP are processed by ISC in the message access layer. The ISC pre-converts the header, body and attachments to plain text and stores them in cache. This is also referred to as "pre-conversion". This data is then indexed in Elasticsearch cluster.
Messages that arrive in the store through the IMAP APPEND command or the imsrestore command are to be processed by ISC on the message access tier host(s). In this scenario, the indexing is triggered twice:
In the first trigger, all email fields, except the body and header, are immediately indexed. The body conversion and indexing happen asynchronously.
The second trigger happens after the message is converted and cached.
See the topic on planning your Messaging Server installation in Messaging Server Installation and Configuration Guide for general planning information. You must consider the following items before installing Cassandra message store:
Cassandra software: You must have Apache Cassandra as the database for the Cassandra message store.
Operating system: You must install Cassandra nodes on Linux. Solaris OS is not supported for Cassandra nodes.
Messaging Server version: Cassandra nodes and message access tier hosts must run Messaging Server 8.1. Front-end hosts must run at least Messaging Server 8.0.1. Additionally, you must use Messaging Server Unified Configuration to administer message access tier hosts. Legacy configuration is not supported on these hosts.
Store protocol: You must use Local Mail Transfer Protocol (LMTP) on the message access layer to deliver messages into the Cassandra message store.
Notifications: You must use Event Notification Service (ENS) for notifications on the message access tier hosts. (Support for Java Message Queue (JMQ) is deprecated.)
Store delivery: You must configure store affinity groups by using the proxy:mailhost.storehostlist Unified Configuration option for robust Cassandra message store delivery.
Message store storage: Use of solid-state drives (SSDs) is recommended for nodes running Cassandra. For actual storage requirements, see "Hardware Requirements".
This section contains system-level planning topics you must consider before installing Cassandra message store:
Cassandra database is designed to be highly available with no single point of failure. Thus, you do not need to install additional cluster software to create a high availability solution for the message store itself.
When planning for disaster recovery, consider deploying Cassandra across multiple data centers in different geographic locations. Cassandra enables replicating and synchronizing data across multiple data centers. You can use different data centers as a live backup, or as a failover site.
Load balancers balance network connections uniformly or by algorithm across multiple servers. You cannot use load balancers on the message store or directory masters. You can use them for connections to MMPs, Oracle Convergence, MTAs, directory consumers, and with the MTA's use of anti-virus and anti-spam products.
Cassandra uses data replication to stores copies (replicas) of data on multiple nodes to ensure that data is not lost if the system crashes, hardware fails, and so on. Nevertheless, backing up and restoring data is an important administrative task for your Messaging Server deployment. To back up the Cassandra database, use the snapshot feature, which can back up all keyspaces, a single keyspace, or an entire cluster. For more information, see the Cassandra backup and restore documentation.
You can secure your Messaging Server infrastructure by first determining your firewall or DMZ architecture. You can also configure Secure Sockets Layer (SSL) on Messaging Server front-end hosts. You must also protect Messaging Server individual components.
For Cassandra message store, keep the following security items in mind:
Messaging Server does not use SSL or authentication for the Cassandra Query Language (CQL) connections from the message access tier (the IMAP/LMTP-server/store-CLI-tools) to Cassandra. Instead, keeping those hosts together on a physically secure network that blocks external access to CQL is recommended.
To secure data at rest on Cassandra nodes, refer to Apache Cassandra for more information.
You can optionally secure the connection from the LMTP server to the Indexing Search Convertor (ISC) with SSL.
ENS can be secured by using SSL and authentication support that was introduced in Messaging Server 8.0.1.
For more information, see the discussion on secure installation and configuration of Messaging Server in the Messaging Server Security Guide.