Scribd
Upload
36 views4 pages

Technical Details

A Carbonio infrastructure is composed of multiple functions split across virtual machines for security, redundancy, and horizontal scaling. It requires services like a directory server, service discovery, Kafka, and PostgresSQL running on cluster servers. A service mesh controls communication and provides load balancing, encryption, and failure recovery. Resources scale vertically by upgrading hardware or horizontally by adding virtual machines.

Uploaded by

Rajitha Jayasooriya
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
36 views4 pages

Technical Details

A Carbonio infrastructure is composed of multiple functions split across virtual machines for security, redundancy, and horizontal scaling. It requires services like a directory server, service discovery, Kafka, and PostgresSQL running on cluster servers. A service mesh controls communication and provides load balancing, encryption, and failure recovery. Resources scale vertically by upgrading hardware or horizontally by adding virtual machines.

Uploaded by

Rajitha Jayasooriya
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 4

Technical details

A Carbonio Infrastructure is composed by multiple functions split on multiple Virtual Machines for
security, redundancy and to easily scale horizontally.

To operate properly, a multi-server Carbonio infrastructure requires different services like: Directory
Server, Consul Service Discover, Apache Kafka, Postgres SQL.
Those services are grouped on three or more VMs called “Cluster Services”.
Balancers are required in front of services that should be always on, the balancer is not a part of
Carbonio, an Opensource or commercial balancer can be used, it must support per port TCP balancing.
Most of the internal services runs in a service mesh mode, Carbonio Mesh manages security and
provides fault-tolerant routing between nodes of a Multi-Server installation.
The HA feature requires a shared Object Storage to be connected to Application Servers, Carbonio
supports: OpenIO, S3, Swift, Scality, Ceph, Alibaba.

A Service Mesh Network is a dedicated infrastructure layer that controls service-to-service


communication over a network. It enables separate parts of an application to communicate with each
other. Common features provided by a service mesh include: service discovery, load balancing,
encryption and failure recovery.
Carbonio implements a Service Mesh network using Consul to balance multiple services, one of this
service is the Outgoing MTA, both MTA servers are used when sending message, in case the outgoing
server is not reachable it will be automatically excluded.
The following services can be installed in redundant mode to increased reliability:

• Carbonio directory server: Master/Replica or Multimaster mode.


• Service Mesh (Consul Service Discover): 3 nodes cluster quorum supported
• Postgres: Master/Replica or Master/Replica with auto promote
• Carbonio DB connectors: Multiple instances behind service mesh
• Carbonio MTA (OUT): Multiple instances behind service mesh
• Carbonio Files: Multiple instances behind service mesh
• Carbonio Docs: Multiple instances behind service mesh

A Carbonio infrastructure includes Prometheus, an open-source software used for the monitoring of
computer systems. It collects data over time (time series) from multiple sources that allow to
understand when and why to scale services adding or even removing VMs or changing their hardware
specs.
Sizing
This paragraph is dedicated to the estimated hardware requirements to implement a Carbonio
infrastructure.
All sizes are expresses in GB and calculated to full quota usage, if an external Email Security solution is
used size and numbers of MTA servers could change.
Detail for VMs:
• Ubuntu 22.04 without snap and auto updates disabled
• A static IP address or reservation on dhcp
• Fully Qualified Domain Name (FQDN) configured in the hosts file
• FQDN resolved by a dns server
• Free access to Internet to http/https ports
• No firewall enabled
• Primary volume mounted on /opt/zextras for Mail & Calendar Services
• Volume mounted on / expanded to the size indicated in the Primary Storage volume in the
following table for Cluster Service and Video Server VMs

The following table show estimated sizing for:


• 5000 mailbox
• 5 GB quota
• Main usage based on webmail and/or mobile app
• Files
• Collaborative editing
• S3 storage support
• AS/AV functions enabled

Please note:
• Carbonio allows to define backup feature per user, the space required for backups could be
lower than the one specified in the tables above because it depends on the number of account
the feature is enabled on.
• The number of VMs could change after deep analysis on infrastructure, usage and mail flows.
• There is no redundancy for Carbonio roles
For realiability it’s suggested to implement redudancy for Carbonio components, roles and VMs can be
installed later without service downtime.
The estimated resources for a redudant Infrastructure are reported in the following table.

Scaling

The number of accounts is a base parameter to estimate the resources required by a Carbonio
infrastructure but they also depends on the usage like the number active connections or the protocol
used. For example we can consider that a single account can connect from multiple devices or can use
different protocols or features.
The numbers presented above are based on statistics collected from test and production environments
but they are not absolute. The monitoring system included with Carbonio and based on Prometheus
helps admins to understand when and what kind of resources to add (New VMs or simply RAM).
A Carbonio infrastructure can be scaled:
• Vertically, by increasing CPU cores, memory (RAM), or storage capacity.
• Horizontally, by creating additional VMs with the same role or split services running on the
same VM to multiple ones.
The following table shows an estimated sizing with the only difference of the number of accounts used
(moved to 25000 accounts).
The process to scale can be gradual per the needs of the infrastructu

You might also like