%BOOK_ENTITIES; ]> The Kolab Groupware Server consists of the primary components outlined in . Each of these components allow scaling up and down both horizontally as well as vertically. This chapter outlines a high-level overview of your options. Kolab Groupware stores the groupware information in IMAP folders. Contacts, events and other groupware related information is stored as an attachment to a mail message. A folder is annotated to indicate the type of groupware content stored in that folder. Kolab Systems recommends the use of Cyrus IMAP as the IMAP storage backend, as is the default that comes with Kolab Groupware. Cyrus IMAP is fast, efficient, scalable. The mail transfer agent (MTA) is used to send and receive messages between nodes in the Kolab Groupware environment and to exchange mail with external applications, other groupware environments and the outside world. Kolab Systems recommends you use Postfix as the mail transfer agent, as is the default that comes with Kolab Groupware. Postfix represents great flexibility, integration, security and scalability. The authentication (authn) and authorization (authz) database holds all user and group information, as well as, at your option, the global address book. Included in the category of server components are 3rd party applications integrated with the Kolab Groupware solution, such as the web mail interface, or XMPP services.

A traditional Kolab Groupware deployment starts out with one Kolab server, which has all of the primary components installed. As the Kolab Groupware environment is used more extensively and/or more 3rd party applications are integrated with Kolab, the environment scales through attaching one or more slave nodes. This type of scaling is illustrated in . There is a number of constraints to this type of scaling architecture which impact its feasibility for larger environments, such as redundancy, high-availability and load-balancing capabilities. That is not to say the traditional model does not perform or is not sustainable. Typically, a traditional deployment of a Kolab Groupware environment –provided sufficient processing, memory and disk, of course– can scale up to serve thousands of users without problems.

However, if any of the keywords listed in occur as prerequisites in the project planning, please refer to . High-availability Load-balancing Disaster Recovery Site-reliability Cold/Warm/Hot Standby Failover Storage Tiers

Large scale Kolab Groupware deployments require the ability to scale up one of the components listed in separate from the other components. This further reduces cost, maintenance overhead and overall environment architecture complexity. To that effect, Kolab Systems recommends considering the environment architecture illustrated in , which shows the following characteristics; All components can, individually, be scaled up and down both horizontally as well as vertically, Relevant components are split up so they can be positioned in the appropriate network segment, Individual components are load-balanced across nodes, implicitly achieving some level of high-availability, Each node can be taken out of rotation and serviced without impact to service availability Note that while service availability would not be impacted, service performance may be degraded during this service window. , Individual components can be made highly available to a certain degree of saturation, Individual components can be positioned to use different tiers of virtualization, storage and network,

Each of these components can be scaled up and down at your discretion, while the architecture allows for improved capacity planning, better monitoring, management and overall sustainability. In this document, all individual components are zoomed in to separately, so that options and consequences in terms of sceurity, scalability, high-availability and load-balancing can be taken into account.