Назревает апгрейд дисковой системы для почтохранилища, распределенной ФС-пока не будет, такая только в планах. Впорос, что будет быстрее для такой задачи? Впринципе линейная скорость не высокая, основной упор на iops Какой тип рейда 1+0 ? 6 ? ? Какой делать strip size ? 16k,32k,64k,128k,256k ? Какую ставить FS? Впринципе некоторые мысли есть на этот счет, но хотелось бы послушать варианты, не высказывая свои, дабы не сбивать народ с мыслей заранее. PS: в предыдущем письме сломались кодировки, перепостил. -- GSA-RIPE
On Mon, Nov 03, 2008 at 08:05:58PM +0200, Sergey A. Gribchenko wrote:
Назревает апгрейд дисковой системы для почтохранилища, распределенной ФС-пока не будет, такая только в планах.
Впорос, что будет быстрее для такой задачи?
Впринципе линейная скорость не высокая, основной упор на iops
Какой тип рейда
1+0 ?
Похоже, другой альтернативы нет, если не считать ZFS с его raidz/raidz2... Но афигенно стрёмно, ибо что-то с восстановлением данных после человеческих ошибок - грабли, да и просто варианты у народа с немонтируемостью пула встречались (баги ядра) - короче, к ней бэкап нужен :|, но зато всё прочексумлено и выживает при потере 1-2 дисков с гарантированной целостностью, можно сжатием баловаться (экономит iops, процы кушает все сразу, зависит от метода сжатия - можно gzip -9 сделать :) )... "побочные эффекты" - если файл битый, то его не прочтёшь (ну - кажись если только CRC выключить). "бесплатный бонус" - хорошо работает, когда файлов в каталоге вагоны - то есть этого почти не заметно. Может, конечно, что-то и стало лучше за последний год...
6 ? Как я поизучал вопрос - так оно потормознее 5 будет при записи...
Какой делать strip size ? 16k,32k,64k,128k,256k ?
Какую ставить FS? Ну - наверно ту же ext3 надо "как-то" готовить, а вариант типа exim срывает крышу от локальной доставки, безотносительно к ФС - то ну ео нафиг (несколько тыщ процессов что-то пытаются доставить в один maildir - cpanel+exim, на фре такой нагрузки не встречал).
Вобщем - я б смотрел в первую очередь на "железо" - типа SSD/DRAM-based drives... -- Best regards, Paul Arakelyan.
я бы ставил RAID5 из 6 моторов на приличном аппаратном контроллере, умеющем хотсвоп. Ну и бэкап на отдельный мотор еженощно.
On Tue, Nov 04, 2008 at 08:25:03AM +0200, Andrew Stesin wrote:
я бы ставил RAID5 из 6 моторов на приличном аппаратном контроллере, умеющем хотсвоп. Ну и бэкап на отдельный мотор еженощно.
При высокой интенсивности запросов на чтение-запись лучше 1+0. http://www.epos.kiev.ua/pubs/nk/rpf_p05.gif -- Kind Regards, Alexander Shikoff AMS1-UANIC
Hi, uanog! On Tue, Nov 04, 2008 at 09:32 +0200, Alexander Shikoff wrote:
я бы ставил RAID5 из 6 моторов на приличном аппаратном контроллере, умеющем хотсвоп. Ну и бэкап на отдельный мотор еженощно.
При высокой интенсивности запросов на чтение-запись лучше 1+0. http://www.epos.kiev.ua/pubs/nk/rpf_p05.gif
Как вариант -- 2 RAID5 собранные в RAID0. Хотя 1+0, конечно, быстрее будет. -- Victor Cheburkin VC319-RIPE, VC1-UANIC
День добрий! Tue, Nov 04, 2008 at 03:55:57AM +0200, unisol wrote:
Какой делать strip size ? 16k,32k,64k,128k,256k ?
Какую ставить FS? Ну - наверно ту же ext3 надо "как-то" готовить, а вариант типа exim срывает крышу от локальной доставки, безотносительно к ФС - то ну ео нафиг (несколько тыщ процессов что-то пытаются доставить в один maildir - cpanel+exim, на фре такой нагрузки не встречал).
А в ext3 не так всего много на тему "готовить для скорости". noatime, dir_index, можно журнал вынести на отдельный девайс... В остальном - железо.
-- Best regards, Paul Arakelyan.
-- WBR, pseudo Avalon Project http://avalon.org.ua
Два года назад было.. но тестировалось именно под почту (не мейлдир). http://loopback.com.ua/uanog-RAID.txt On Mon, Nov 03, 2008 at 20:05:58 (+0200), Sergey A. Gribchenko wrote:
Назревает апгрейд дисковой системы для почтохранилища, распределенной ФС-пока не будет, такая только в планах.
Впорос, что будет быстрее для такой задачи?
Впринципе линейная скорость не высокая, основной упор на iops
Какой тип рейда
1+0 ? 6 ? ?
Какой делать strip size ? 16k,32k,64k,128k,256k ?
Какую ставить FS?
Впринципе некоторые мысли есть на этот счет, но хотелось бы послушать варианты, не высказывая свои, дабы не сбивать народ с мыслей заранее.
PS: в предыдущем письме сломались кодировки, перепостил.
-- GSA-RIPE
-- wbr, kden
Tue, Nov 04, 2008 at 08:25:03, stesin wrote about "Re: [uanog] Файлохранилище для Maildir":
я бы ставил RAID5 из 6 моторов на приличном аппаратном контроллере, умеющем хотсвоп. Ну и бэкап на отдельный мотор еженощно.
5 и 6 на произвольно разбросанной записи (а для Maildir будет именно такой шаблон нагрузки) пишут значительно медленнее - им надо для вычисления контрольных сумм прочитать все соседние блоки в полосе. Если контроллер умный и запись параллельно ожидается - это ещё как-то нивелируется, но без нескольких процессов и без AIO, или при тупом контроллере - будет тормозить. Так что мне кажется, 1+0 тут хоть и менее экономно, но в целом полезнее. -netch-
Я бы делал (ц) многоступенчатую систему: входящий smtp, который знает что ящик икс живет на бэкенде ыгрэк и прокси (nginx) который проксирует pop3/imap в зависимости от dst maildir, где уже собственно и живёт поппер. Т.о. мы получаем систему, которая (как вы уже по тестами увидели, ибо чудес не бывает) обладает горизонтальной масштабируемостью до миллиона юзеров активных в месяц спокойно. Этот пример был описан в Berkeley где-то году в 2003-м на уровне абстракта "как это ваще надо делать". Не делайте больших массивов: random производительность raid'а в целом всегда меньше или равно производительности 1 диска. Средний raid хорошо держит 100 random iops. Хотите 1000 ? Окей, 10 логических волумов на каком-то кол-ве серверов. Valentin Nechayev пишет:
Tue, Nov 04, 2008 at 08:25:03, stesin wrote about "Re: [uanog] Файлохранилище для Maildir":
я бы ставил RAID5 из 6 моторов на приличном аппаратном контроллере, умеющем хотсвоп. Ну и бэкап на отдельный мотор еженощно.
5 и 6 на произвольно разбросанной записи (а для Maildir будет именно такой шаблон нагрузки) пишут значительно медленнее - им надо для вычисления контрольных сумм прочитать все соседние блоки в полосе. Если контроллер умный и запись параллельно ожидается - это ещё как-то нивелируется, но без нескольких процессов и без AIO, или при тупом контроллере - будет тормозить.
Так что мне кажется, 1+0 тут хоть и менее экономно, но в целом полезнее.
-netch-
On Tue, 04 Nov 2008, Vladimir Sharun wrote:
Я бы делал (ц) многоступенчатую систему: входящий smtp, который знает что ящик икс живет на бэкенде ыгрэк и прокси (nginx) который проксирует pop3/imap в зависимости от dst maildir, где уже собственно и живёт поппер.
Т.о. мы получаем систему, которая (как вы уже по тестами увидели, ибо чудес не бывает) обладает горизонтальной масштабируемостью до миллиона юзеров активных в месяц спокойно. Этот пример был описан в Berkeley где-то году в 2003-м на уровне абстракта "как это ваще надо делать". Не делайте больших массивов: random производительность raid'а в целом всегда меньше или равно производительности 1 диска. Средний raid хорошо держит 100 random iops. Хотите 1000 ? Окей, 10 логических волумов на каком-то кол-ве серверов.
Ок, А по какому протоколу маунтить в таком случае отдельные volume в главному smtp серверу? -- GSA-RIPE
4 ноября 2008 г. 17:43 пользователь Sergey A. Gribchenko
On Tue, 04 Nov 2008, Vladimir Sharun wrote:
Я бы делал (ц) многоступенчатую систему: входящий smtp, который знает что ящик икс живет на бэкенде ыгрэк и прокси (nginx) который проксирует pop3/imap в зависимости от dst maildir, где уже собственно и живёт поппер.
Т.о. мы получаем систему, которая (как вы уже по тестами увидели, ибо чудес не бывает) обладает горизонтальной масштабируемостью до миллиона юзеров активных в месяц спокойно. Этот пример был описан в Berkeley где-то году в 2003-м на уровне абстракта "как это ваще надо делать". Не делайте больших массивов: random производительность raid'а в целом всегда меньше или равно производительности 1 диска. Средний raid хорошо держит 100 random iops. Хотите 1000 ? Окей, 10 логических волумов на каком-то кол-ве серверов.
Ок, А по какому протоколу маунтить в таком случае отдельные volume в главному smtp серверу?
Вариантов много: smtp, uucp, lmtp+smtp, lmtp+nfs, lmtp+uucp, lmtp+xxx... (lmtp в даном случае тулза, которая принимает по lmtp, а потом пересылает как надо и куда надо)
Denis P. Khripun wrote:
Два года назад было.. но тестировалось именно под почту (не мейлдир). http://loopback.com.ua/uanog-RAID.txt
Стрёмное у Вас предложение однако: Write Cache Setting : ENABLE ALWAYS Write Cache Status : Active, not protected, battery not present -- Mykola Dzham, LEFT-(UANIC|RIPE) JID: levsha@jabber.net.ua
On Tue, Nov 04, 2008 at 19:25:02 (+0200), Mykola Dzham wrote:
Denis P. Khripun wrote:
Два года назад было.. но тестировалось именно под почту (не мейлдир). http://loopback.com.ua/uanog-RAID.txt
Стрёмное у Вас предложение однако:
Write Cache Setting : ENABLE ALWAYS Write Cache Status : Active, not protected, battery not present
Ключевые слова тут "ENABLE ALWAYS" и "Active". А то, что "battery not present" - лечится. Это же я показал тесты, а не продакшн. В продакшн (таких бэкендов несколько) "бетари" не тольско стала "пресент", но и есть ЗИП (контроллер+батарея).
-- Mykola Dzham, LEFT-(UANIC|RIPE) JID: levsha@jabber.net.ua
-- wbr, kden
participants (11)
-
Alexander Shikoff -
Andrew Stesin -
Denis P. Khripun -
Max A. Krasilnikov -
Mykola Dzham -
Paul Arakelyan -
Serge Negodyuck -
Sergey A. Gribchenko -
Valentin Nechayev -
Victor Cheburkin -
Vladimir Sharun