Zimbra Server

The Zimbra server is a dedicated server that manages all of the mailbox contents, including messages, contacts, calendar, and attachments. Messages are received from the Zimbra MTA server and then passed through any filters that have been created. Messages are then indexed and deposited into the correct mailbox.

In addition to content management, the Zimbra mailbox server has dedicated volumes for backup and log files.

Each Zimbra mailbox server in the system can see only its own storage volumes. Zimbra mailbox servers cannot see, read, or write to another Zimbra server.

In a Zimbra single server environment, all services are on one server, and during installation the computer is configured to partition the disk to accommodate each of the services.

In a Zimbra multi-server environment, the Zimbra LDAP and Zimbra MTA services can be installed on separate servers. See the Multi-Server Installation Guide.

The MTA server, receives mail via SMTP and routes each mail message to the appropriate Zimbra mailbox server using LMTP. As each mail message arrives, the Zimbra server schedules a thread to have Lucene index it.

Disk Layout

The mailbox server includes the following volumes:

Message Store. Mail message files are in opt/zimbra/store
Data Store. The MySQL Database files are in opt/zimbra/db
Index Store. Index files are in opt/zimbra/index
Backup Area. Full and incremental backups are in opt/zimbra/backup (Network Edition only)
Log files. Each component in the Zimbra Collaboration Suite has log files. Local logs are in /opt/zimbra/log
Note: The system logs, the redo logs, and the backup disk should be on separate disks to minimize the possibility of unrecoverable data loss in the event that one of those disks fails.

Message Store

The Zimbra Message Store is where all email messages reside, including the message body and any file attachments. Messages are stored in MIME format.

The Message Store is located on each Zimbra server under
/opt/zimbra/store. Each mailbox has a dedicated directory named after its internal Zimbra mailbox ID.

Note: Mailbox IDs are unique per server, not system-wide.

Single-Copy Message Storage

“Single copy storage” allows messages with multiple recipients to be stored only once in the file system. On UNIX systems, the mailbox directory for each user contains a hard link to the actual file. In multi-server configurations, where recipients may be in different Message Stores, one copy exists per server.

Hierarchical Storage Management

Hierarchical Storage Management (HSM) allows you to configure storage volumes for older messages. To manage your email storage resources, you can implement a different HSM policy for each message server. Messages and attachments are moved from a primary volume to the current secondary volume based on the age of the message. The messages are still accessible.

Data Store

The Zimbra Data Store is a MySQL database that contains all the metadata regarding the messages including tags, conversations, and pointers to where the messages are stored in the file system.

Each account (mailbox) resides only on one server. Each Zimbra server has its own standalone data store containing data for the mailboxes on that server.

The Data Store contains:

Mailbox-account mapping. The primary identifier within the Zimbra database is the mailbox ID, rather than a user name or account name. The mailbox ID is only unique within a single mailbox server. The Data Store maps the Zimbra mailbox IDs to the users’ OpenLDAP accounts.
Each user’s set of tag definitions, folders, and contacts, calendar appointments, filter rules.
Information about each mail message, including whether it is read or unread, and which tags are associated.

Index Store

The index and search technology is provided through Apache Lucene. Each message is automatically indexed as it enters the system. Each mailbox has an index file associated with it.

The tokenizing and indexing process is not configurable by administrators or users.

The process is as follows:

1.
The Zimbra MTA routes the incoming email to the Zimbra mailbox server that contains the account’s mailbox.
2.
The mailbox server parses the message, including the header, the body, and all readable file attachments such as PDF files or Microsoft Word documents, in order to tokenize the words.
3.
The mailbox server passes the tokenized information to Lucene to create the index files.

Note: Tokenization: The method for indexing is by each word. Certain common patterns, such as phone numbers, email addresses, and domain names are tokenized as shown in the Message tokenization figure below.

Figure 3: Message tokenization

3 Zimbra Servers.3.1.1.jpg

Backup

For the Network Edition, Zimbra includes a configurable backup manager that resides on every Zimbra server and performs both backup and restore functions. You do not have to stop the Zimbra server in order to run the backup process. The backup manager can be used to restore a single user, rather than having to restore the entire system in the event that one user’s mailbox becomes corrupted.

Redo Log

Each Zimbra server generates redo logs that contain every transaction processed by that server. If an unexpected shutdown occurs to the server, the redo logs are used for the following:

To ensure that no uncommitted transactions remain, the server rereads the redo logs upon startup.
During restore, to recover data written since the last full backup in the event of a server failure.

When the current redo log file size reaches 100MB, the current redo log rolls over to an archive directory. At that point, the server starts a new redo log. All uncommitted transactions from the previous redo log are preserved. In the case of a crash, when the server restarts, the current redo log and the archived logs are read to re-apply any uncommitted transactions.

When an incremental backup is run, the redo logs are moved from the archive to the backup directory.

Log

A Zimbra deployment consists of various third-party components with one or more Zimbra mailbox servers. Each of the components may generate its own logging output.

Selected Zimbra log messages generate SNMP traps, which you can capture using any SNMP monitoring software. See Monitoring Zimbra.

Jump to: navigation, search