Jump to content
Калькуляторы

Перенос POP3/IMAP сервера (Cyrus) на другой сервер Поделитесь опытом

Доброго времени суток, господа и дамы.

 

Нужно перенести "живой" POP3/IMAP сервер на базе Cyrus IMAP Server (под управлением Gentoo) с физического сервера на виртуальный.

 

Ничего сложного, если бы не один момент: существующие почтовые ящики клиентов, занимающие 40+ Гб (около 1000000 файлов).

 

Пофайловое копирование по сети всей структуры ящиков заняло примерно сутки. Создание tar архива, его копирование и разворачивание - даже если займет в 3-4 раза меньше времени, то всё равно прилично.

 

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

 

Наверняка кто-то уже проделывал подобные "переезды" - поделитесь, пожалуйста, опытом.

Share this post


Link to post
Share on other sites

Подмонтировать диск с ящиками в виртуалку ?

Share this post


Link to post
Share on other sites

Или съемный диск. Всяко уж займет принципиально меньше времени. Сначала копируем, потом синхронизируем. И переносим.

Share this post


Link to post
Share on other sites

Подмонтировать диск с ящиками в виртуалку ?

На сервере, кроме Cyrus, есть и другие сервисы. Т.е. остановка Cyrus не означает остановки всего сервера.

 

Или съемный диск. Всяко уж займет принципиально меньше времени. Сначала копируем, потом синхронизируем. И переносим.

Всё равно вы рассматриваете полный перенос: остановили "старый" Cyrus, перенесли все ящики, запустили "новый" Cyrus.

 

А хочется такого: параллельно "старому" запустили "новый" Cyrus, и порциями переносим ящики с одного на другой. Понятно, что именно в такой формулировке звучит бредово - но вдруг есть какие-то средства, чтобы сделать хотя бы что-то приблизительно похожее?

Share this post


Link to post
Share on other sites

Посмотрите imapsync. Синкаете старый на новый в онлайн режиме, когда все работает, сколько надо дней. Потом останавливаете прием писем на старом сервере, выполняете синк еще раз. Он пройдет быстро, т.к. досинкает только новые письма. Готово.

Share this post


Link to post
Share on other sites

Вы только новую файловую систему подтюнингуйте.

А то при "40+ Гб (около 1000000 файлов)" будет куча проблем с производительностью и надежностью.

Share this post


Link to post
Share on other sites

Вы только новую файловую систему подтюнингуйте.

А то при "40+ Гб (около 1000000 файлов)" будет куча проблем с производительностью и надежностью.

А что тюнить там надо в виртуалке?

Share this post


Link to post
Share on other sites

Вы только новую файловую систему подтюнингуйте.

А то при "40+ Гб (около 1000000 файлов)" будет куча проблем с производительностью и надежностью.

А что тюнить там надо в виртуалке?

 

О, еще и в виртуалке.

Ну, запасайтесь вазелином, будут зверские тормоза.

Share this post


Link to post
Share on other sites

ну наверное ссделать rsync несколько раз (не забыть что нужно удалять пропавшее), опустить службу на старом, еще раз рсинк и запустить на новом ?? достаточно стандартный метод переезда фаловой помойки, в незаисисмости от того что над ней накручено. Вот если хранилище в 1 файле то да.. тогда ой. рсинк конечноу умеет файлы частями досинкивать, но по скорости это не очень вречатляет.

 

а будет или нет тормозиить, это больше от нагрузки зависит чем от занятого места. Занятое место может уже занято 100 лет и там и не ходит никто..

Share this post


Link to post
Share on other sites

rsync на большом кол-ве файлов будет работать долго.

Использовать только imapsync и только для maildir.

Share this post


Link to post
Share on other sites

ну наверное ссделать rsync несколько раз (не забыть что нужно удалять пропавшее), опустить службу на старом, еще раз рсинк и запустить на новом ?? достаточно стандартный метод переезда фаловой помойки, в незаисисмости от того что над ней накручено. Вот если хранилище в 1 файле то да.. тогда ой. рсинк конечноу умеет файлы частями досинкивать, но по скорости это не очень вречатляет.

Не, тут всё в порядке. Одно письмо - один файл.

 

а будет или нет тормозиить, это больше от нагрузки зависит чем от занятого места. Занятое место может уже занято 100 лет и там и не ходит никто..

Почти :)

Большинство ящиков "мертвые", кроме спама туда ничего не падает.

Самописный скриптик раз в неделю проходится по ящикам и прибивает письма старше 30 дней.

 

rsync на большом кол-ве файлов будет работать долго.

Долго отрабатывало первое копирование (еще без rsync).

Затем прошелся "по верху" уже rsync - отработало за приемлемое время.

Использовать только imapsync и только для maildir.

Про imapsync почитал - для pop3 все письма станут "непрочитанными" (т.е. неполученными). Не хотелось бы пугать тех клиентов, которые еще пользуются почтой (все они используют именно pop3).

Поэтому принял решение использовать rsync, и на _все_ файлы, а не только maildir.

Share this post


Link to post
Share on other sites

rsync на большом кол-ве файлов будет работать долго.

Использовать только imapsync и только для maildir.

 

 

ну значит я счастливой обладатель секретной версии рсинка, которая вполне себе вменяема по скорости, на большом количестве не сильно изменяемых файлов. Уж точно это быстрее досинкает файлы чем эти ваши имап синков на 1000+ аканутов.

Share this post


Link to post
Share on other sites

ну значит я счастливой обладатель секретной версии рсинка, которая вполне себе вменяема по скорости, на большом количестве не сильно изменяемых файлов. Уж точно это быстрее досинкает файлы чем эти ваши имап синков на 1000+ аканутов.

 

Опять сферический конь в вакууме.

Делайте репрезентативные тесты и делитесь результатами.

При вычислении md5 файлов чудес не бывает.

Share this post


Link to post
Share on other sites

Какие MD5 на неизмененных файлах ? таймстамп-размер совпадает ? следующий. Не, с дуру можно и кой че сломать конеччно.

 

вот только сегодня 80 гиг разноразмерного хлама, сначала синкалось в сеть упираясь, потом вторая итеррация - 3 минуты на 5 файлов, что поменлись. мы о чем ?

 

синкался полностью вот этот раздел (это на источнике, ДСТ извините, уже упакован для отправки на площадку, по приезду еще раз синкну, могу засечь статистику), посмортрел в кактус, первый синк минут 25 был. Второго на графике к сожалению вообще не видно. ну 2, ну 3 минуты. с секундомером не стоял.

Filesystem          Size    Used   Avail Capacity iused ifree %iused  Mounted on
/dev/mfid0p6        1,4T     81G    1,2T     6%    975k  191M    1%   /www

Share this post


Link to post
Share on other sites

У меня нет обратная ситуация. На больших директориях rsync при анализе овер 20ГБ данных rsync тупить начинает.

Может ему не нравится сво-ва раздела с компрессией и dedup - хз.

Share this post


Link to post
Share on other sites

еще раз. Если файлы не изменялись, то он из не читает. Все закачивается на сравнении времен создания файлов. Может просто диры сканируются долго ? (тупо ls -lar /ПУТь > /dev/null) . Ну тогда да, ЗФСу памяти неплохо бы дать.. потому как в таком случае, даже если цирус и кеширует гдето в своих базах списки писем, и имапсинк не читает диры для выдачи списка пием в ней, то открытие собственно писем в тех дирах будет затыкаться. причем не только при синке но и по жизни.

 

Вообще я дедуп стараюсь не пользовать. на тестах копий на 50 одного и тогоже залитого на диск (для тестов брал /usr/src+/usr/obj) оно начинало ТОРМОЗИТЬ. дико. гдето в районе 9.2 правда тестил. Причем памяти так нормально вроде, толи 24Г толи 48 было. А уж массовое удаление вообще в фризу любой дисковой активности приводило пару раз. до резета.

Share this post


Link to post
Share on other sites
Может просто диры сканируются долго ? (тупо ls -lar /ПУТь > /dev/null)

 

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

Share this post


Link to post
Share on other sites

Это если памяти хватило их там держать.

Хз как линуксе, а во фре этот кеш тюнится.

Share this post


Link to post
Share on other sites

Это если памяти хватило их там держать.

 

Ну, вообще, диры занимают не так уж и много места. Если там, конечно, не дестяки миллионов файлов... :)

 

Хз как линуксе, а во фре этот кеш тюнится.

 

Я не слышал, что бы кто-нибудь его тюнил. Зачем? В линуксе он и автоматом нормально распределяется. Я в свое время экспериментировал на структурах в несколько десятков тыс. каталогов, в которых валялось несколько сотен тыс. файлов. Делал в памяти временный гарантированный кеш, и сравнивал с системным автоматом. Разницы не заметил (после первого прогона реального).

Share this post


Link to post
Share on other sites

однозначно rsync --delete .

еще можете упереться в количество inode (см. df -i ), поэтому при создании fs сразу посмотрите, чтобы их было достаточно.

ext4 должно нормально работать, а также есть положительный опыт с btrfs, но ядро желательно поновее.

Share this post


Link to post
Share on other sites

В свое время всю миграцию Exchange -> Cyrus-IMAPD -> Zimbra выполнил через imapsync. Процесс был не сказать что торопливый, но прошло без перерыва, совершенно прозрачно для клиентов.

Share this post


Link to post
Share on other sites

ну у человека то без смены софта. Понятно что с эксченжда рсинком не съедешь на цирус.

Share this post


Link to post
Share on other sites

однозначно rsync --delete .

rsync -az8P --delete --stats

 

еще можете упереться в количество inode (см. df -i ), поэтому при создании fs сразу посмотрите, чтобы их было достаточно.

ext4 должно нормально работать, а также есть положительный опыт с btrfs, но ядро желательно поновее.

6M+ inodes. Должно хватить :)

Ядро достаточно свежее - декабрь/январь. Делалась виртуалка для других задач, для почты сделал с нее копию.

Только вот в плане fs я, наверное, излишне консервативен, поэтому не ext4, а ext3.

 

Но возникло одно "Но", с которым ковыряюсь уже не первый день :(

Не проходит авторизация pop3 клиента к "новому" серверу. К старому проходит, к новому - нет. md5 паролей хранятся в Мускульной базе (база одна и та же, на отдельном сервере)

Цирус собирался с одинаковыми ключами на обоих серверах (новом и старом)

Уже даже собрал на новом ту же версию, что и на старом - не выходит каменный цветок.

Где-то допустил ошибку - теперь ищу...

Share this post


Link to post
Share on other sites
Я не слышал, что бы кто-нибудь его тюнил. Зачем?

Во фре задаются лимиты на память и прочее, вот их и тюнят.

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

Смысл в том, чтобы можно было ограничить ресурсы для не существенных задач и гарантировать для важных.

Share this post


Link to post
Share on other sites

Не проходит авторизация pop3 клиента к "новому" серверу. К старому проходит, к новому - нет. md5 паролей хранятся в Мускульной базе (база одна и та же, на отдельном сервере)

Цирус собирался с одинаковыми ключами на обоих серверах (новом и старом)

Уже даже собрал на новом ту же версию, что и на старом - не выходит каменный цветок.

Разобрался.

В Gentoo из дистрибутива cyrus-sasl удален патч checkpw.c, как раз отвечающий за хранение в БД хэшей паролей, а не самих паролей.

Та версия, в которой он еще остался, "криво" собирается (ошибок нет, но доступа к БД тоже нет)

Пришлось делать оверлей, в котором "с помощью молотка, напильника и такой-то матери" накатывается нужный мне патч.

Если вдруг кому нужно - вот мой оверлей: https://www.dropbox....verlay.tgz?dl=0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this