Hello First, most of your questions are not SOGo related, but IMAP and database server related.
That said, let's start :-) You can optimize your setup for either speed, high availability or easy setup. As you seem to go for redundancy and/or speed, you should split up your setup into loadbalancer, SOGo + reverse Proxy, database and IMAP/SMTP server. IMAP: This is independent from SOGo. SOGo is only one other IMAP client like any other. There are different IMAP setups, depending on your needs and available infrastructure. You can have single hardware machines with local SSDs. Those are fast and have really low latencies. But the max storage they can handle is limited to less than 100 TB right now and can get really costly. You can have hardware or VM machines connected with a SAN or NAS for Storage, preferable with local SSD cache. They are slower, but can provide a lot of storage up to PB range for each machine. Last option is to use a shared storage via NFS. With that you have all servers connecting the same storage, but you have to ensure, that only one server is trying to access the same mailbox for writing, which usually means locking. This will slow down your access considerably. Also see caching below. In order to overcome the storage limitation of IMAP servers with local SSD storage, you can use a technique called "sharding". With that you propagate your users across different machines. That means, you can access emails of one user only on one machine, not others. In order to know which user is located on which machine, you need an IMAP proxy/balancer, which has that information either by using a hash or some info stored in authentication source. Beware: If you use "sharding" and sharing of folders between mailboxes, you need a proxy/balancer capable of serving different sources/mailboxes to one authenticated user. Check dovecot-director as example for such a proxy/balancer. In order to get redundancy, you usually synchronize your mailboxes to at least one other machine. Beware, this always comes with a time delay. And there is something called caching, which will store new content in RAM first, then from time to time get it to disk. Because of that you can lose emails, when synchronizing files on disk only. In dovecot you have a built-in IMAP synchronization mechanism, which will synchronize all IMAP transactions to one other machine. This prevents the caching problem. You can set up both machines synchronizing to each other. With that you would have 2 machines providing one mailbox in active-active mode. IMAP sessions are bound to one connection. As long as the connection exists, the session can survive. One connection can provide multiple sessions. There can be multiple connections at the same time. Therefore it is irrelevant which server a session connects, as long as the server doesn't die and all servers have the same content. Database: Independent to SOGo, can be reused for multiple services. SOGo only stores authentication information, settings, address books and calendars in database. Those are tiny compared to emails. For 25,000 users only, no database will get into a sweat. They usually are made for datasets in the hundreds of millions. If you need high redundancy, you can even use a cluster setup, but they are hard to do right and expensive. If you want best speed for authentication, or need integration in some existing Identity Management system, you should use an LDAP/AD in addition. They are made to do authentication. SOGo: How many accounts one SOGo server can serve, depends on the usage. Example: We have split our servers like outlined at the start of this message. We have ~20,000 accounts and provide no ActiveSync. There are roughly 120 parallel, active SOGo sessions per minute in high usage times. Active SOGo session means, that the user clicked at least one time in that minute or accessed any information via DAV. This is served by an 16 core 32 GB RAM 200 GB SSD/HD VM. RAM is the most limiting factor here. Especially for large emails and folders with a lot of emails we had to increase max Limit of RAM per worker SxVMemLimit to 512. Else we had seen a lot of respawned workers after one access. We have 350 workers running. If you want to use multiple SOGo servers (as you are planning for dedicated ActiveSync and web + DAV), you have to use one shared memcached server. You also have to use one shared NFS or cifs server for email composition and encoding storage (SOGoMailSpoolPath + NGMimeBuildMimeTempDirectory). If you don't use those, you will have diverse problems when creating emails or change settings and content. Hope that helps a bit. Kind regards, Christian Mack Am 06.08.20 um 15:20 schrieb Marco (fa...@ruparpiemonte.it): > Hello, > > I read that SOGo can manage at least 25000 mailboxes and more. But I > don't understand how to setup the hosts through an high availability > balancer. > > At the moment I have about 20000 mailboxes accessed through IMAP. Many > mailboxes are large (over 10GB) and very intensively accessed. They are > highly accessed through ActiveSynch too, so I'll setup a separate > installation for this protocol, as suggested on SOGo site. > > I wonder how many mailboxes can manage a single SOGo host. > I would like to know if an IMAP session must stay on a single host, or > if it can land on a random balanced host. > For instance, I remember that Horde can have multiple hosts equally > configured with the same DB (in particular one session table). So it's > not important what balanced host a client contacts: even in the same > IMAP session the host can change. > > I would like to know if you have some hints or best practices how to > configure SOGo in a large environment. For instance, a typical resource > allocation (CPU, RAM) for a single host. > > Let suppose to choose a MySQL DB. Reading at the manual, it seems the DB > is a system global configuration. Can a single DB manage over 20000 > mailboxes? > > Thank you very much for every hints. > > Cheers > Marco > -- Christian Mack Universität Konstanz Kommunikations-, Informations-, Medienzentrum (KIM) Abteilung IT-Dienste Forschung und Lehre 78457 Konstanz +49 7531 88-4416
smime.p7s
Description: S/MIME Cryptographic Signature
