sql based mail server (сервер с хранением в БД)

[minder]

Подскажите, существует ли linux open-source почтовый сервер (imap, pop3, smtp) с хранением писем не на локально на ФС, а в БД, кроме проекта dbmail ?
Если кто сталкивался, имеет ли смысл хранить в базе или лучше чем-то в Maildir для использования с большим количеством пользователей (100000)?

[alfss]

1) так делать не стоит
2) информация в sql будете весить больше чем просто на fs
3) при больших объёмах информации будет не выгодно

[Ali[SF]eN]

Postfix - может хранить и в индексах и в базах ( mysql,postgres,oracle ) - при большом количестве пользователей значительно выигрывает в скорости
2alfss
>>2) информация в sql будете весить больше чем просто на fs
>>3) при больших объёмах информации будет не выгодно
мразматический бред сумасшедшего.
Если вы так уверены в своих словах - скопируйте свой пост на форум postfix.ru и ждите ответов.

[alfss]

Укажите пожалуйста на статью где данное описано.

[alfss]

http://dbmail.org/index.php?page=reference смотрю я тут и как-то плохо мне становится ><
* User accounts: 600 ( and growing )
* Size of database: 200 GB
* Slackware Linux 12
* DBMail 2.2.10
* MySQL 5.0.x
* Postifx, Amavis, ClamAV, SpamAssassin
* Roundcube webmail, SMTPs, POPs, IMAPs
* Dell PowerEdge 2900 III
* 2 Processors Intel Xeon E5410 Quad-Core de 2.33 GHz com 2 x 6 MB Cache (1333 FSB) EM64T
* 8 GB RAM (FBD), 667 MHz
* 4 x 300GB SAS de 3.5" 15.000 rpm RAID 5
* Installation date: Feb/2008 and no problems so far. Runs very smooth and processor is idle most of the time.

[pelmen]

1) так делать не стоит
2) информация в sql будете весить больше чем просто на fs
3) при больших объёмах информации будет не выгодно

Postfix - может хранить и в индексах и в базах ( mysql,postgres,oracle ) - при большом количестве пользователей значительно выигрывает в скорости
2alfss
>>2) информация в sql будете весить больше чем просто на fs
>>3) при больших объёмах информации будет не выгодно
мразматический бред сумасшедшего.
Если вы так уверены в своих словах - скопируйте свой пост на форум postfix.ru и ждите ответов.

Я правильно понимаю, что alfss говорит об именно письмах (с чем я согласен), а Ali[SF]eN говорит о почтовых ящиках в бд ?

[minder]

Я правильно понимаю, что alfss говорит об именно письмах (с чем я согласен), а Ali[SF]eN говорит о почтовых ящиках в бд ?

Мне тоже так показалось.

Подозреваю, что придется делать в кластере на распределенной файловой системе в формате Maildir, чтобы не огрести в будущем проблем с вот такой вот не стандартной формой хранения как dbmail.

[alfss]

Есть мысль что можно решить данную проблему без распределенной fs.
Главное хорошо подумать ^_^.
на самом деле тут все просто с SMTP и гораздо все запутаннее с POP3,IMAP.

[minder]

Есть мысль что можно решить данную проблему без распределенной fs.
Главное хорошо подумать ^_^.
на самом деле тут все просто с SMTP и гораздо все запутаннее с POP3,IMAP.

Необходима высокая доступность сервиса, а значит кластер (т.е. несколько хостов), значит единая ФС: NFS или распределенная, первая - не особо надежный вариант на мой взгляд. Может я не прав в чем-то?

[pelmen]

У почтовых систем есть такая фича: mx 10 ip, mx 20 ip... (это я про днс). Можно просто еще один сервак поднять, который будет ловить эту же почту в случае выкл. первого и настроить между ними синхронизацию.

[alfss]

Я уже выше сказал что можно и без . Можно и с распределенной fs.
NFS лучше туда не совать .
Вообще это задача вашего проектировщика)) - пусть он голову ломает ^_^.
Я ничего не скажу конкретного и схему рисовать не стану - это денег стоит.

[pelmen]

Я - проектировщик. Я сломал голову.
Делаем два почтовых сервера, обслуживающих по 2 виртуальных домена каждый. Домены такие: domain.ru, mx1.domain.ru, mx2.domain.ru. MX-записи будут такими: domain.ru mx 10 ip1 и domain.ru mx 20 ip2. Каждый из серверов обслуживает domain.ru + один из дополнительных. Во всех доменах одни и те же почтовые ящики, т.е. user1@domain.ru, user1@mx1.domain.ru, user1@mx2.domain.ru. Физически все письма, которые будут храниться в /var/mail/virtual/domain.ru будут так же храниться и в /var/mail/virtual/mx1.domain.ru (просто символьная ссылка). Письма будут приходить только на user@domain.ru. В алиасах пользователя будет храниться такая запись: user@domain.ru,user@mx2.domain.ru. На втором сервере соответственно user@domain.ru,user@mx1.domain.ru. Таким образом письмо, пришедшее на почтовый сервер (допустим на ip1), будет оставлено в /var/mail/virtual/domain.ru/user/ + отправлено на user@mx2.domain.ru и заляжет там в /var/mail/virtual/mx2.domain.ru/user/, что является символьной ссылкой для /var/mail/virtual/domain.ru/user/. У пользователей user@mx{1,2}.domain.ru алиасов нет, чтоб не вызывать цикл. Если сервер вышел из строя, то письма будут автоматом слаться на mx2.domain.ru, и по такой-же обратной схеме залягут на нем и будут продублированы на user@mx1.domain.ru и будут ждать очереди на отправку, пока сервер не будет восстановлен.

[alfss]

to pelmen
В данном случае это глупость).Этого попросту мало.
Я могу сказать что тут нужно смотреть в сторону round robin DNS ,CARP.

[alfss]

to pelmen
ну вы и навернули)
тока в это схеме нету распределение нагрузки)) есть только резервирование).

[pelmen]

Пусть автор темы ответит. Ему ведь надо. Да, с распределением нагрузки я ни разу не сталкивался и не знаю, как это делать.

[Ленивая Бестолочь]

может я не очень понимаю ситуацию, но....
как вариант:

берете два сервера, настраиваете на них почтарь, который обслуживает ваш домен (один, основной)
настраиваете на них синхронизацию в обе стороны раздела с почтой по drdb и какой-нибудь файловой системы типа ocfs2.
ставите балансировщик нагрузки, назначаете ему айпи, который прописан в днс-ах, вот в общем то и все.

вместо drbd можно использовать сетевое хранилище с помощью nfs или aoe.

[alfss]

и когда данные переваливают за 3 Тера мы нервно курим в сторонке ^_^

[Ленивая Бестолочь]

и когда данные переваливают за 3 Тера мы нервно курим в сторонке ^_^

это вы к моему сообщению?
если да, то я могу сказать, что у меня несколько серверов синхронизируются по drbd, один из разделов в 850gb - ничего, все работает довольно хорошо.
а еще хочется заметить, что обычно компании у которых почтари хранят инфы на 3 тера могут позволить себе нормальное сетевое хранилище.

[minder]

Пусть автор темы ответит. Ему ведь надо. Да, с распределением нагрузки я ни разу не сталкивался и не знаю, как это делать.

Распределение нагрузки, конечно, нужно будет при больших объемах почты.

может я не очень понимаю ситуацию, но....
как вариант:

берете два сервера, настраиваете на них почтарь, который обслуживает ваш домен (один, основной)
настраиваете на них синхронизацию в обе стороны раздела с почтой по drdb и какой-нибудь файловой системы типа ocfs2.
ставите балансировщик нагрузки, назначаете ему айпи, который прописан в днс-ах, вот в общем то и все.

вместо drbd можно использовать сетевое хранилище с помощью nfs или aoe.

как раз об этом я и думал.

SAN с FiberChanel в такой конструкции подразумевается.

Технически, я особо проблем не вижу. Сомнения были (и остаются) в надежности dbmail.org с его СУБД ориентированным методом хранения. А ведь именно на подобное решения меня начальство склоняет..., т.к. откатить базу на любой момент времени куда проще будет из бекапа. Но и завязыватся на одном проекте (программе) не хотелось бы. Вот и ломаю голову.

[alfss]

а каков бюджет на реализацию?сколько в начале будет пользователей?

[minder]

а каков бюджет на реализацию?сколько в начале будет пользователей?

Про бюджет ничего не ясно. если сервис нужен будет, то выделят все необходимое оборудование (системы хранения уже есть в наличие и их можно задействовать), а может выясниться, что все это никому не нужно. Но моя задача планировать по максимуму. По началу, число пользователей будет несколько тысяч на одной машине в виртуальной среде. Далее, видно будет.

[Ленивая Бестолочь]

откатить базу на любой момент времени куда проще будет из бекапа

честно говоря не особо понимаю, почему базу проще откатить из бэкапа.
даже может быть наоборот - представте, что вам нужно не откатывать всю базу, а достать одно потерянное письмо из бекапа - в такой ситуации файловый бэкап имхо намного гибче.
а еще очень разумно делать снепшоты, хотя бы тем же lvm-ом. я так понимаю ресурсы вам позволяют.

[alfss]

Ну так на скорую руку.
Должно быть понятно.

Можно наращивать как количество серверов так и мощность.

[minder]

откатить базу на любой момент времени куда проще будет из бекапа

честно говоря не особо понимаю, почему базу проще откатить из бэкапа.
даже может быть наоборот - представте, что вам нужно не откатывать всю базу, а достать одно потерянное письмо из бекапа - в такой ситуации файловый бэкап имхо намного гибче.
а еще очень разумно делать снепшоты, хотя бы тем же lvm-ом. я так понимаю ресурсы вам позволяют.

Допустим такая ситуация: нужно откатить состояние почты (или откопать из недр прошлого) на конкретный момент времени, где какое-то письмо было, но в бекапе последнем его нет (оно было удалено), а в предпоследнем теряется все, что было с момента его до этого письма важного. Или письмо не попало в моменты бекапа - было получено и удалено в короткие сроки. СУБД позволяет при инкрементальном бекапе с использованием логов восстановить состояние базы на любой момент времени.
Честно скзать, сомнительное пожелание.
На мой взгляд, rsync здесь - самое то, плюс снапшоты lvm.

Ну так на скорую руку.
Должно быть понятно.

Можно наращивать как количество серверов так и мощность.

Только не соображу зачем еще nginx тут нужен? может для балансировки загрузки?
Я представляю всю систему как на этой ссылке http://www.linuxvirtualserver.org/architecture.html
В качестве Real Server сами сервера IMAP/POP/SMTP. Почти тоже самое в принципе...с возможностью будущего масштабирования как горизонтального, так и вертикального.

[alfss]

pop3 протокол не знает к какому вас серверу направить
так же как и imap

nginx нужен чтобы при обращении на pop.domain.ru он проксировал запрос там где находятся данные.

Лень описывать - но видать придется .

SMTP сервера принимают почту и передают на ту машину где она будет хранится.
Данные где хранится,логин,пас,квота и тд черпаются из SQL.
Почта будет хранится не на всех машинах сразу ,а на одной.
Балансировка нагрузки осуществляется с помощью round robin dns записи.

С машиной на которой хранится почта можно делать уже все по вкусу.
snapshot,rsync,carp - уж как попрет) на все фантазия автора

А вот теперь посмотрим со стороны клиента.
Не думаю что хорошо выдавать каждому конкретный адрес где хранится его почта.
Вот тут как раз и нужен nginx, он буде принимать данные и основываясь на них переадресовывать до нужного хоста.
И мы врятли хотим чтоб 1 бедный сервер загнулся от всех запросов)), поэтому засунем еще парочку для разгрузки если нужно и клиент этого совсем не почувствует).


Для отправки почты вообще лучше выделить отдельные машины.


О том как работает round robin dns
http://www.zytrax.com/books/dns/ch9/rr.html

[minder]

pop3 протокол не знает к какому вас серверу направить
так же как и imap

nginx нужен чтобы при обращении на pop.domain.ru он проксировал запрос там где находятся данные.

Лень описывать - но видать придется .

SMTP сервера принимают почту и передают на ту машину где она будет хранится.
Данные где хранится,логин,пас,квота и тд черпаются из SQL.
Почта будет хранится не на всех машинах сразу ,а на одной.
Балансировка нагрузки осуществляется с помощью round robin dns записи.

С машиной на которой хранится почта можно делать уже все по вкусу.
snapshot,rsync,carp - уж как попрет) на все фантазия автора

А вот теперь посмотрим со стороны клиента.
Не думаю что хорошо выдавать каждому конкретный адрес где хранится его почта.
Вот тут как раз и нужен nginx, он буде принимать данные и основываясь на них переадресовывать до нужного хоста.
И мы врятли хотим чтоб 1 бедный сервер загнулся от всех запросов)), поэтому засунем еще парочку для разгрузки если нужно и клиент этого совсем не почувствует).


Для отправки почты вообще лучше выделить отдельные машины.


О том как работает round robin dns
http://www.zytrax.com/books/dns/ch9/rr.html

Как я и предположил, nginx нужен для балансировки нагрузки (совместно с DNS). Спасибо за разъяснения.
А вот Вы, мне кажется, не смотрели ту ссылку, что я дал. Там за место nginx используется специальный проект Load balanсer.

Меня как раз больше интересует производительность и надежность SQL метода хранения почты - в этом суть вопроса. Хотя думаю, что не буду заморачиваться на нем.

[alfss]

nginx гораздо проще в настройке чем Load balanсer ИМХО.
Притом с ним знакомо очень много людей)

А насчет надежности я уже сказал, можете с хранилищем делать что хотите и как хотите.
Можно автоматизировать подмену на случай выхода из строя.
Тут главное представлять как это работает и как еще можно дополнить.

С тем что я на калякал.
Можно начинать с 1 машины.
Добавлять доп машины очень просто - для этого не надо на них производить каких либо серьёзных настроек.

Выбор за вами).

Проведите тестирования.

[skor]

Допустим такая ситуация: нужно откатить состояние почты (или откопать из недр прошлого) на конкретный момент времени, где какое-то письмо было, но в бекапе последнем его нет (оно было удалено), а в предпоследнем теряется все, что было с момента его до этого письма важного. Или письмо не попало в моменты бекапа - было получено и удалено в короткие сроки. СУБД позволяет при инкрементальном бекапе с использованием логов восстановить состояние базы на любой момент времени.
Честно скзать, сомнительное пожелание.
На мой взгляд, rsync здесь - самое то, плюс снапшоты lvm.

Эммм... Любой почтовый сервер умеет делать копию входящей почты. После этого что хочете с этой копией, то и делаете - храните, сжимаете, солите, коптите... Не плодите лишние сущности.