[Dovecot] Multiple locations, 2 servers - planning questions...

[Adam Szpakowski]

On 27.02.2012 19:21, Charles Marcus wrote:
> On 2012-02-27 12:59 PM, Adam Szpakowski <as at 3a.pl> wrote:
>> I do have a basic question... How many users will be in this new,
>> remote location? Will the traffic be so vast, that 1GbE link will not
>> be enough, or are you using two servers for reliability?
>
> Yeah, I guess I should have mentioned this...
>
> Each location is an entire floor of a 6 story building. The remote
> location has the capacity for about 60 users, the new location about
> 100. We only allow IMAP access to email, so if everyone is using email
> at the same time, that would be a lot of traffic over a single Gb link I
> think...
I'm not sure that the bandwidth will be a problem. One of our clients is 
a civic design office. Around 60 people and lots of multi megabyte files 
in multiple copies. Autocad 3D files are flying all around ;). All 
accounts are IMAP ones, there is also local SAMBA service. The server 
has 1GbE connection to almost all workstations and the bandwidth 
utilization is low, very low, on average much less then 1%. We are 
talking about over 50 heavy duty users.

>> The simpler the configuration, it is almost always the better. Maybe
>> you can stay with one server in yours primary location?
>
> I had considered this, but like I said, this is not purely for 
> performance - I'd also like to get redundancy in the deal (up until 
> now, we haven't had any - admittedly - knock on wood - we haven't 
> needed it, but I'd still like to implement it).
IMHO use something simple for redundancy such us DRBD in active/passive 
mode in single location. Manual migration to do not have to deal with 
split brain problems. As a additional layer of security against local 
cataclysm (fire in the building) use nightly backup to the second office.
You will not have automatic, 99.999% reliability, but for most clients 
it is ok. They do not need this. The market for highly available, 
redundant services is quite small.

-- 
Adam Szpakowski