Deployment Scenarios
********************

Depending on the target use of Cyrus IMAP, different features and
architectures may be used to make optimal use of the Cyrus IMAP
features. This chapter briefly touches different deployment scenarios.


Single Server Deployments
=========================

In a deployment scenario with a single server, use this checklist to
make sure you get the right scalability and functionality;

* In the foreseeable future, might this deployment run for multiple
  domain name spaces?

* Is this deployment going to close in on it's maximum capacity?

* Is high-availability required?

If the answer to all of these questions is a consistent no, then
please continue with the Installation Guide.


Multi Server Deployments
========================

A variety of options are available to scale up the deployment of Cyrus
IMAP beyond a single server. Each of them has their own set of
features, advantages, disadvantages and consequences on day-to-day
administration, migration and capacity planning and support. Please
consider a deployment that requires scaling up carefully.


Cyrus IMAP Murder
-----------------

A Cyrus IMAP Murder groups Cyrus IMAP servers together, allowing the
addition and removal of individual Cyrus IMAP servers to and from the
group. Functionally, a Cyrus IMAP Murder consists of the following
three components;

* one or more frontends, receiving the connections from the clients,
  authenticating them and depending on the type of Cyrus IMAP Murder,
  referring the client to the correct backend server, or proxying the
  connection.

* one or more backends, holding the actual mailbox spool(s).

* a master update server, where the information on the location and
  Access Control of the mailboxes is kept.

In a Cyrus IMAP Murder, access to mailboxes, regardless of which
backend they reside on, is transparent to the user. As such, this
particular type of deployment would be recommended for organizations
that;

* (are likely to) grow a single Cyrus IMAP server beyond the capacity
  of said server,

* require shared mailboxes and user mailboxes to be shared regardless
  of any limitations to whether or not they reside on the same backend
  server,

Different types of Cyrus IMAP Murder deployments exist. Please see
Cyrus_IMAP_Murder for a review of your options.


IMAP Proxy
----------

An IMAP proxy like NGINX could sit in front of a number of stand-alone
Cyrus IMAP servers, proxying client connections through to the correct
stand-alone Cyrus IMAP server for a user.

Note that in this type of setup, it is the user authentication that
directs the proxy to the correct stand-alone Cyrus IMAP server. As
such, shared mailboxes can only exist on the stand-alone Cyrus IMAP
server to which the user is proxied -- in other words, on which the
user's own mailbox is supposed to exist.


Cyrus Murder: Server aggregation
********************************


The Discrete Murder
===================

A *discrete* murder - also known as a standard murder -
characteristically uses separate frontend and backend servers. At the
time of this writing, this is the recommended type of Cyrus IMAP
Murder for deployments that require;

* load-balancing and/or high availability of their Cyrus IMAP
  deployments,

* the ability to take frontends out of rotation, and bring frontends
  (back) in to rotation without impact on the availability of mailbox
  spools.

* Authentication to take place before a connection is created or
  proxied to servers with data, such as would be the case of a
  perimeter network proxy,

* Have very large numbers of mailboxes, (this one's because of the
  mupdate RAM consumption)

It is worth noting that in a *discrete* murder, backends only know of
the mailboxes that reside in their local mailbox spool(s). Since the
user's subscription database is kept on the backend server that hosts
their mailbox, should the deployment require that all users can
subscribe to all mailboxes that they have permission to in the murder,
the setting "allowallsubscribe" needs to be set to "true" (1). This,
however, allows users to subscribe to non-existent mailboxes.


The Unified Murder
==================

A *unified* murder characteristically joins the functional aspects of
a server being frontend and backend together onto one single Cyrus
IMAP server. A Cyrus IMAP server in a unified murder can thus perform
both as a frontend as well as a backend. All backends would thus have
all information on all mailboxes on all other backends.

At the time of this writing, but subject to change in the near future,
a participating node in a Cyrus IMAP Unified Murder cannot be made a
dedicated frontend. This creates a disadvantage over a *discrete*
murder, as the frontend function cannot be taken out of rotation
without also losing the backend function.

Because in using mailbox creation and transfer routines a
participating node cannot be excluded from selection for or
availability of the (new) location of the (new) mailbox, no guarantee
can exists the participating node does not hold any mailboxes. Short
of a deployment specific interface to creating and transferring
mailboxes that provides such guarantee, as a logical consequence, to
shoot a participating node in a Cyrus IMAP Unified Murder in the head,
all mailboxes must be transferred to other backends prior to service
shutdown, or the availability of the mailboxes is impacted.

The unified murder also has some great advantages. Since all backends
know about all mailboxes in the murder, administrators can choose to
not permit subscriptions to non-existent folders. In a discrete
murder, where backends know only of the mailboxes in the local mailbox
spool(s), such permission is (often) required.


The Shared Murder
=================

*To be written*


Cyrus Replication
*****************

*To be written*


Hosted Environments
*******************

*To be written*
