Re: [Dovecot] best practises for mail systems
We once try to use similar solution as your first. 3 servers for LVS -HA This master server redirect users for 2 or 3 dovecot backends.. The mail storage were maildir ontop of OCFS2 Our problem were that OCFS2 were too slow. We could not handle many users. So we took an step back and now use only user one server. But still thinking in go back to the first one. with LVS When using LVS try to sticky user to the same backend, LVs can do ths by source ip. Where i work we have problens on testign storage. If you have any advices for testing disk performance, i will be thankfull. I wil be glad to answer anything else. []'sf.rique On Tue, Jun 5, 2012 at 9:59 AM, Костырев Александр Алексеевич < a.kosty...@serverc.ru> wrote: > I think LVS is just fine and it is not a SPOF 'cause it is actually 2 > servers: > active master --> and standby slave. > LVS supports real time replication of connections from master to slave, > so if master dies slave knows which IP was connected to which dovecot > server. > > I'm more worried about right design of mailstorage.. should I use some > cluster fs with all mail of all users > or should I split mailstorage across servers and somehow avoid long > downtime if one of servers goes down. > > > -Original Message- > From: dovecot-boun...@dovecot.org [mailto:dovecot-boun...@dovecot.org] On > Behalf Of Matthias-Christian Ott > Sent: Tuesday, June 05, 2012 11:28 PM > To: dovecot@dovecot.org > Subject: Re: [Dovecot] best practises for mail systems > > On 2012-06-05 05:14, Костырев Александр Алексеевич wrote: > > On each host system we created one VM and passed through 3x2TB disks > into it. > > > > > > > > In guests vms on top of this disks we made XFS and fired up glusterfs > with distributed replicated volumes for our mailstorage. > > > > so it looks like this: > > > > > > > > vm1replicate vm2 > > > > disk1 > disk4 > > > > disk2 > disk5 > > > > disk3 > disk6 > > > > > > > > in each vm we mounted glusterfs and pointed dovecot to that dir for mail > creation (as ltmp) and imap4 user access. > > > > also we use exim as smtp. > > > > > > > > So, with glusterfs as mailstorage we can go for LVS to load balancing > for exim and dovecot. > > > > so wherenever one of host systems (hence one of mail vms) goes down, > users don't notice that > > > > 'cause LVS points them to working smtp and imap4 servers > > > > and they get their mail 'cause of glusterfs. > > [...] > > Cons: > > > > - not quite sure if glusterfs is production ready solution 'cause I've > experienced split-brains during setting it up > > > > - IO performance issue. Though we didn't yet run any io tests, but > glusterfs uses fuse to mount on clients. And guys on #gluster told me > writing to the glusterfs mount will not be strictly local io. > > I'm not familiar with LVS, but from the project description it seems > that you need a "front server" that does the load balancing, so you > either have to run at least two of these servers in parallel or add to > your cons that you introduced a single point of failure. But you > mentioned that you only have two servers, so you really can do this. > > I would rather ensure high availability by running the two servers as > masters and using either IP address takeover or DNS failover (with > dynamic DNS) and either use Dovecot's replication (I haven't tested it > yet and I'm not sure what happens in case of IP address takeover) or a > file system that can handle these kinds of errors (e.g. Coda). You could > do load balancing via round-robin DNS. This only protects you against > the failure of single machine and because IMAP sessions are not > replicated between the servers, connections will get reset if one server > fails, but it's cost-effective and uses software that already exists. > > Regards, > Matthias-Christian >
Re: [Dovecot] Which FTS to use!
So i guess i will just stay with squat until i upgrade to 2.1 and then
move to solr..
And make the cron update daily for active users!
Thanks a lot!
[]'sf.rique
On Fri, Nov 25, 2011 at 2:47 PM, Timo Sirainen wrote:
> On 25.11.2011, at 17.29, Henrique Santos Fernandes wrote:
>
> > Hello, i am currently using squat dovecot, but some users that have lots
> os
> > emails ( 1GB ) are complaining about speed.
> > Iam using dovecot 2.0.13 on debian 6
> >
> > my squat conf is
> > plugin {
> > fts = squat
> > fts_squat = partial=4 full=5
> > }
> >
> > I am thinking in maybe start to use Solr, so any one can help me with an
> > decision?
>
> With v2.0 Solr is the only other choice.
>
> > I am probably gonna update dovecot to 2.1 next year. and them maybe
> change
> > the FTS plugin.
>
> With v2.1 Lucene is another possibility, and it's somewhat easier to
> install than Solr. Also v2.1's Solr backend is improved, so I wouldn't
> really recommend spending a lot of time and disk I/O on v2.0's Solr since
> you'll need to rebuild the index anyway in v2.1 (or keep using "solr_old"
> backend with some missing featues).
>
> > This year i will get 10k disk only to store the dovecot index, rigth now
> > they are saved on the same storage that the mails are and also change
> the
> > "full" parameter to something like 10 or 15 I know i will use more disk
> > space for it, but it will make a lot of differences right? it will match
> > the message without the need of opening it for any search smaller than
> 10
> > character i guess.
> >
> >
> > But this will be enough? or Solr or Lucene still better?
>
> The main problem with Squat is its index updating performance, which sucks.
>
> > Anyway, i am not current updating the indexes automatic, but i am planing
> > on it, just not sure what is better, the command doveadm index or doveadm
> > search... with one is better to do the task?
>
> doveadm index
[Dovecot] Which FTS to use!
Hello, i am currently using squat dovecot, but some users that have lots os
emails ( 1GB ) are complaining about speed.
Iam using dovecot 2.0.13 on debian 6
my squat conf is
plugin {
fts = squat
fts_squat = partial=4 full=5
}
I am thinking in maybe start to use Solr, so any one can help me with an
decision?
I am probably gonna update dovecot to 2.1 next year. and them maybe change
the FTS plugin.
This year i will get 10k disk only to store the dovecot index, rigth now
they are saved on the same storage that the mails are and also change the
"full" parameter to something like 10 or 15 I know i will use more disk
space for it, but it will make a lot of differences right? it will match
the message without the need of opening it for any search smaller than 10
character i guess.
But this will be enough? or Solr or Lucene still better?
Anyway, i am not current updating the indexes automatic, but i am planing
on it, just not sure what is better, the command doveadm index or doveadm
search... with one is better to do the task?
Thanks!
[]'sf.rique
Re: [Dovecot] Performance-Tuning
[]'sf.rique How many servers have access to your maildir on ext4 so that you could > switch from ocfs2 to ext4? > I use ocfs2 in my test environment for four servers (2 MX and 2 IMAP) I used have 3 serves one mailman and 2 imaps.I experence that if take my loadbalancer and takes it all to just one server, itwould go faster becasue of cache. But once thsi server fails, the loadbalaner send it to the other one, but it simple does not work, clients experence timeouts, because the filesystem were too slow. On Thu, Nov 17, 2011 at 7:34 AM, Jan-Frode Myklebust wrote: On Wed, Nov 16, 2011 at 11:53:29PM -0200, Henrique Santos Fernandes wrote: > > > > Wich clustered filesytem do you have? > > We use IBM GPFS, with currently 7 servers working against shared LUNs > from an IBM DS4800. > > > > > My ocfs2 setup had some problems... but still.. > > Some numbers: > > > > OCFS2 > > 1TB of maildir files. > > Full backup 36 Hours > > Incremental 15 hours > > > > Ext4 > > 1TB of maildir files. > > Full backup 16 Hours > > Incremental 1 hour > > Wow, local fs's are fast! > Much faster! I could not run a "du" before, if i did would crash the system, now i can! > We have split the backup process up to run on 6 of the servers, with each > server processing only a part of the filesystem (/a-f, /g-l, /m-p, etc..). > The backup processing time varies quite a bit every day, but are mostly > somewhere between 14-24 hours on each server. This sounds like something > between 1.5x to 2x the incremental-performance you're seeing: > >15 hours/incremental of 1TB ocfs2 = 15h/TB >6x 15 hours for incremental of 12 TB GPFS = 7.5h/TB >6x 20 hours for incremental of 12 TB GPFS = 10h/TB > > All our backups are incremental. > > > -jf >
Re: [Dovecot] Performance-Tuning
Jan-Frode Wich clustered filesytem do you have? I used to have ocfs2 but had problems with performance. So had to get back to ext4 and it solve the performance problem... My ocfs2 setup had some problems... but still.. Some numbers: OCFS2 1TB of maildir files. Full backup 36 Hours Incremental 15 hours Ext4 1TB of maildir files. Full backup 16 Hours Incremental 1 hour Same LUN on storage. []'sf.rique On Mon, Nov 14, 2011 at 4:42 PM, Stan Hoeppner wrote: > On 11/14/2011 4:27 AM, Jan-Frode Myklebust wrote: > > > Agree. A non-clustered fs should give you better performance, and > > probably also be more reliable, if you can live with the SPoF and > > full downtime during patching/upgrades/maintenance. But I would expect > > xfs to be a better choice than ext*. > > Depends on the workload characteristics and how well the XFS filesystem > is tuned to the storage hardware. If setup properly, using many > allocation groups with fast spindles, a decent amount of BBWC, and a > high concurrency maildir workload (dozens to hundreds of delivery and > IMAP operations), XFS will runs circles around EXTx as it can > create/write/read to every AG in parallel. Much of EXT4's operation is > still serialized. This is why XFS outruns all other filesystems in the > highly parallel mail workload benchmarks I posted previously, EXTx by a > factor of 2-3. > > For smaller hosts that don't see parallelism, for example SOHO servers, > XFS will likely be slower than EXTx as the workload will be serialized. > > -- > Stan >
