The Carbonio architecture is primarily focused on services, which render nodes stateless, redundant, and clustered by design. The Mailstore is the sole stateful service, because to its critical function in storing metadata, binary blobs, and connection cache.
While this arrangement might constitute a single point of failure, a Carbonio replica mechanism can be implemented to significantly improve the availability of the Mailstore service.
How it works.
Active Replica is the cornerstone of the HA technique mentioned above; it is an account-based, real-time replication mechanism that enables Carbonio to maintain numerous instances of a mailbox across various Mailstores.
The Replica portion is in responsible of encrypting and transmitting all account transactions to an event-streaming queue. The Replica processes the events, which are then ingested by one or more agents at the destination Mailstore. Active signifies that the destination Mailstores are active nodes, which reduces the requirement for dedicated resources to store the cluster’s passive node. This also helps the overall performance of the promotion stage, as the service is already operational.
Active Replica Requirements
There are two requirements for installing the Active Replica.
Carbonio subscriptions must contain the HA module. The HA is licenced “for enabled accounts”. The licence may be confirmed using command.
All of the mailbox’s principal volumes must be set for Centralised Storage.
Enable Active Replica.
To activate Active Replica, set the endpoints of all streamer nodes, using either their IPs or FQDNs, to expose port 9092, which should be accessible from all other Mailstores.
To ensure that the settings have been applied and that the service is operational, run the commands listed in the Active Replica Troubleshooting section below.
Active Replica Usage
Routine actions with the Active Replica may be performed using a variety of CLI commands, including initialisation, monitoring, promotion, and deletion.
Limitations of Commands
The commands listed in this section do not support:
Regular expressions in the account name: john.doe@example.com is supported, however john*@example.com or?ohn@example.com are not
Distribution Lists
Replica Initialisation
To duplicate a mailbox to another Mailstore, use the setAccountDestination command, which requires as arguments
the target Mailstore’s FDQN (for example, mailstore1.example.com).
Node priority. If the same account has been copied more than once, this information can be utilised to determine which account was used first. A lower number indicates a higher importance.
the account to be replicated. Multiple accounts are also supported, either comma separated on the command line or via an input file, with one account per line. In the remainder, we call this file /tmp/accounts. It consists of two lines:
john.doe@example.com
jane.doe@example.com
Valid commands include: The Global Administrator will get notification after replica initialization is complete.
Replica Monitoring
To check the status of a replica, use the getAccountStatus command and refine the output by using one of the following parameters:
mailHost, to confirm the status of all replicated accounts active in the source mailstore.
replicaServer, to confirm the status of all accounts replicated on a certain mailstore.
replicaStatus, to display only accounts with an available or unavailable replica on the destination Mailstore.
With no parameters, the tool will display the status of all accounts set for the Replica. For each account, the output reports:
Replica Promotion
The design of Active Replica enables the swift promotion of a replica at any moment. Indeed, because all metadata is synchronously replicated in the event queue and blobs are stored in a centralised volume, the Administrator can initiate the promotion even if the source Mailstore is unavailable.
To promote an account, Administrators can use the promoteAccounts command and filter the output by specifying one of the following options.
accounts to promote one or more (comma separated) accounts, using the first replica (lowest priority).
input_file, to promote accounts for a file (one per line), using the first replica (with the lowest priority)
source_mail_host is used to promote all accounts hosted by a certain Mailstore.
Examples of acceptable commands include:
Promote accounts.
Promote accounts saved in a file.
Promote all accounts in a mailstore.
Global Admin will be notified as soon as the replica promotion is done.
Replica Deletion
The Administrator can erase the duplicated information at any time using the removeAccountDestination command with one of the following parameters:
destination, to select the Mailstore from which you wish to remove the duplicate.
accounts, as well as multiple (comma separated) accounts or an input file (containing multiple accounts, one per line), to define which account metadata should be erased.
Active Replica Troubleshooting
The following commands might be useful for verifying the status of the service.