Перейти к содержимому
Калькуляторы

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

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

 

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

 

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

 

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

Почти :)

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

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

 

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

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Какие 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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

rsync -az8P --delete --stats

 

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

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

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

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

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

 

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Я не слышал, что бы кто-нибудь его тюнил. Зачем?

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Разобрался.

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.