LINUX.ORG.RU
ФорумAdmin

SSD FreeBSD ufs


0

0

Добрый день Господа, очень приятно получать грамотные ответы на ЛОРе, что шокирует!

Есть такая ситуация: Лохматый сервер FreeBSD, на старой мат. плате Desktop socket 478, сервер является шлюзом, вида: mail, nat, firewall, gw, vpn + ещё очень много чего.

Сейчас там два харда: один под систему Desktop 40g, mail SCSI 60 GB, второго по месту уже не может не хватить, так-как планируется увеличение почтового траффика, в связи с чем хотелось бы повысить надёжность, и увеличить пространство.

Сервер не высоконагруженный, но ДОЛЖЕН быть доступен в режиме 24x7, и данные должны также быть целыми, если с ним что-либо случится мне можно сразу прыгать с крыши.

Хотел поступить так:

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

2: купить аппаратный контроллер PCI raid SATA, но ничего толкового не нашлось, только fake raid прочитав отзывы в Интернет, что дескать это не самый лучший способ, я решил отказаться, толковые контроллеры есть только PCI-e, но это придётся тормозить сервер переводить его на новое железо и настраивать, и если чего будет не так то... Придётся мне натурально убиться.

3: родилась идея попробовать SSD, перевести сразу в такой вид: SSD 256 Gb SATA-II 300 Kingston <SNV225-S2/256GB> 2.5" под mail, и SSD 40 Gb SATA-II 300 Kingston <SNV125-S2/40GB> 2.5" под ОС. http://www.ssdage.com/page/1/ прочитал тут, и вроде как ободрился. Но читав дальше увидел, дескать вот ограничения на кол-во циклов записи и так далее. Но в других местах прочитал что это всё чушь голубая, дескать в SSD есть система которая сама перераспределяет равномерно всё на ячейки и там Автор считал, что это 10 лет потребуется непрерывной записи чтобы израсходовать этот цикл, ну в среднем это 5 млн. раз записать полностью диск и стереть с него... Что практически я считаю не реально.

На сайте того же kingston не нашёл ничего про это.

Кто что думает? Конечно интересен второй вариант, взять поновее железо, купить нормальный Raid контроллер аппаратный, поставить диски нормальные поставить Linux и забыть. Но, что-то я боюсь ибо простой весьма критичен и нету уверенности что смогу перенести почту грамотно. Там адская связка с spamassign exim dovecot clamav, ничего такого нету конечно, но повторюсь простоя нельзя допустить.

А SSD можно по бырому ночью переписать за час простоя сервера и всё будет ок. Надёжности хватит.

Я знаю, что мне надо уже искать крышу повыше, чтобы от меня ничего не осталось... Так-как очевидно, что надо поднимать распределённые бекапы, делать нормальные RAID, переходить на Windows ME и так далее...

В общем кто чего скажет? Стоит ли игра свечь?

★★★★★

gmirror -b «balance» ?

«balance» == load | prefer | round-robin | split — что выбрал?

Под SSD разработана ZFS.

iZEN ★★★★★
()
Ответ на: комментарий от iZEN

Выбрал: round-robin.

Читал рассылки где тестируют различные способы, скорость при всех одинакова низка, а так как в hand book и во всех других источниках выбирают: round-robin, также поступил и я. Я понимаю, «что одна бабка сказала...», я прочитал описание этого метода, в другие особо не вдавался.

Что скажете?

Блин, на ZFS переходить... Да ещё и / переводить... Ох... Боюсь.

DALDON ★★★★★
() автор топика
Ответ на: комментарий от DALDON

round robin это феерически писец, меняй пока не получишь максимума на своём типе загрузки.

По поводу ресинхронизации: так и задумано, если интересно то займись теорией и сам всё поймёшь. Тут только ставить ups. Аппаратные рейды или write-throught делают(и будут феерическим тормозом) или bbu оснащаются.

У линухов есть bitmap(man mdadm) для решения этой проблемы, но это так, для общего развития.

true_admin ★★★★★
()
Ответ на: комментарий от DALDON

> Выбрал: round-robin.

Оно и видно. Я было засомневался...

Блин, на ZFS переходить... Да ещё и / переводить... Ох... Боюсь.


А ты не бойся. Почитай материала о ZFS в FreeBSD. Систему для начала нужно делать на разделе с UFS2 (классическая ФС), а вот данные можно и на ZFS (лучше на RAID-Z из 3 дисков) положить.

iZEN ★★★★★
()
Ответ на: комментарий от iZEN

> Систему для начала нужно делать на разделе с UFS2 (классическая ФС)

Сейчас она и живёт там, умолчательная.

Почитай материала о ZFS в FreeBSD. Систему для начала нужно делать на разделе с UFS2 (классическая ФС), а вот данные можно и на ZFS (лучше на RAID-Z из 3 дисков) положить.

Т.е. на просто обычные диски? Не морочиться с SSD? Уж больно дорого три диска брать SSD.

По поводу ресинхронизации: так и задумано, если интересно то займись теорией и сам всё поймёшь. Тут только ставить ups.

Спасибо. UPS не проблема.

У линухов есть bitmap(man mdadm)

Трудно вот так вот взять и перейти сейчас на Linux к сожалению.

gmirror - мой способ чтения и записи таков: почтовый траффик IMAP на 80 пользователей, каждый ящик по 600 мб в среднем, некоторые и два гб. есть, способ хранения был выбран mail-box т.е. всё в одном файле, то есть у меня немного чтения, немного записи в различные места на HDD.

Какой способ тут более выгоден? И как тестировать, не на боевой машине? - именно такой способ, я тестировал очень приметивно: cat /dev/mirror/gm0xx > /dev/null - очевидно, что это просто простое поточное последовательное чтение. Я прочитаю про все способы gmirror. Надеюсь станет более очевиднее.

DALDON ★★★★★
() автор топика
Ответ на: комментарий от DALDON

> Систему для начала нужно делать на разделе с UFS2

Разумеется первая ссылка в поиске. http://wiki.freebsd.org/ZFS

It is possible to configure root file system on ZFS as explained here, but it is not possible to boot from ZFS pool.

Страшновато конечно. Не нативная же. Поди раз 50 ядро надо будет пересобирать...

P.S. там FreeBSD 7.2.

DALDON ★★★★★
() автор топика
Ответ на: комментарий от DALDON

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

Обновись хотя бы до FreeBSD 8.0-RELEASE.

iZEN ★★★★★
()
Ответ на: комментарий от iZEN

Да, я прочитал про всё это в англоязычной Wiki. Процесс обновления FreeBSD до 8.0 я выполнял через freebsd-update, но на боевом сервере я боюсь, если чего будет не так, мне начальник гроб самолично закажет, и я получил прямой запрет на обновление ПО на этом сервере (можно конечно откопировать сервер через gmirror забрать диски и попробовать обновление, но блин... Это ж ужас право...).

Если не zfs, то есть ли ещё выход из ситуации? gmirror и SSD я всё ещё рассматриваю.

DALDON ★★★★★
() автор топика
Ответ на: комментарий от iZEN

Такс.

Вот чего прочитал:

split    Split read requests, which are bigger than or equal to slice size on N pieces, where N is the number of active components. This is the default balance algorithm.

-s slice    When using the split balance algorithm and an I/O READ request is bigger than or equal to this value, the I/O request will be split into N pieces, where N is the number of active components. Defaults to 4096 bytes.

И пример:

gmirror label -v -b split -s 2048 data da0 da1 da2.

Всё это из мануала, я прочитал это и сначало, но раз рекомендуют другой метод, я решил идти на поводу у всех.

А ведь тут сказано, что gmirror будет распаралеливать запрос больше определённого размера или ему равного (параметр -s), на N дисков которые находятся в массиве. 2kb как раз то, что нужно, меньшие запросы нету смысла паралелить и тратить процессорное время на это. В общем попробую этот алгоритм. На реальном тестовом железе, если скорорость чтения будет выше чем один диск или даже равна буду это пробовать, благо с gmirror не трудно «соскочить» всегда.

Пробовать буду так: dd if=/dev/mirror/gm0 of /dev/null bs=2k

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

И буду пробовать: dd if=/dev/ad0 of /dev/null bs=2k посмотрим кто выиграет.

DALDON ★★★★★
() автор топика
Ответ на: комментарий от DALDON

И буду играться с параметром bs от 1 до 1024 к примеру, посмотрим какая будет разница между просто чтением с одного диска с gmirror и с использованием split gmirror. :)

Кто может подскажет как замутить случайное/псевдослучайное чтение?

DALDON ★★★★★
() автор топика
Ответ на: комментарий от DALDON

способ хранения был выбран mail-box

Возможно, это неудачный выбор на таких объёмах данных. Сам подумай что будет если удалить, например, самое первое письмо.

true_admin ★★★★★
()
Ответ на: комментарий от true_admin

>Возможно, это неудачный выбор на таких объёмах данных. Сам подумай что будет если удалить, например, самое первое письмо.

В том и дело, что неудачный, делал это не я. Это уже делалось всё несколько лет назад и не мной, в том и проблема что теперь перенос всего этого дела - дело весьма не простое.

А чего будет если удалить самое первое письмо?

Ок. Посмотрю postmark.

DALDON ★★★★★
() автор топика
Ответ на: комментарий от DALDON

А чего будет если удалить самое первое письмо?

Он должен быть сдвинуть содержимое файла вверх, а это тормоза на таких объёмах.

Если упадёт питание в момент этой операции то почту вообще можно потерять. Итп.

true_admin ★★★★★
()
Ответ на: комментарий от true_admin

Ууу... Понял. Спасибо. Думаю уже чего делать, нашёл утилиты переконвертации в mail-dir, может чего попробую.

Ох... Спасибо тебе уважаемый!

DALDON ★★★★★
() автор топика
Ответ на: комментарий от DALDON

Попробовал я в geom различные алгоритмы, в общем чуда не случилось.

Разумеется довольно глупо бы наверно его было и ждать: речь о приросте скорости чтения. Скорость чтения остаётся на уровне скорости одного диска. В любом случае. Большего не добиться. - Очевидно что распарелизация запросов aka split последовательная. Что только может снизить нагрузку на все винчестеры массива при чтении, не более.

DALDON ★★★★★
() автор топика
Ответ на: комментарий от iZEN

> Split read requests, which are bigger than or equal to slice size on N pieces, where N is the number of active components. This is the default balance algorithm.

man gmirror.

Эм...

DALDON ★★★★★
() автор топика

>2: купить аппаратный контроллер PCI raid SATA, но ничего толкового не нашлось, только fake raid прочитав отзывы в Интернет, что дескать это не самый лучший способ, я решил отказаться, толковые контроллеры есть только PCI-e, но это придётся тормозить сервер переводить его на новое железо и настраивать, и если чего будет не так то... Придётся мне натурально убиться.

3ware 8006-2LP. Честный хардварный рейд на два диска. ~150 - 200 USD.

Под Линуксом работает, под Фрей тоже должон. Ставится в PCI-X или обычную PCI. У меня работает под Убунтой 8.04.3, с обычной PCI. Единственная проблема - при обновлениях ядра в /boot/grub/menu.lst прописываются неверные UUID. Но это может быть и из-за того, что переносил я систему с одиночного диска на рейд как-то по-варварски, уже не упомню, как.

gaestur
()
Ответ на: комментарий от DALDON

Дык о чем и речь.

Ставится в PCI-X или обычную PCI.


У меня он в десктопе, на котором одно время крутились Cacti, Nagios и прочая. В разъем на материнке входит только часть контактов платы рейда, но - все работает.

gaestur
()
Ответ на: комментарий от DALDON

А если у тебя тупо от старости винты/мать/бп загнется ты тоже прыгать будешь? Делай срочно резервный сервер на новом железе, не важно с рейдом ли из обычных дисков, или с твердотельными, но чем быстрее, тем лучше. Вообще при таких требованиях к доступности надо кластеризованные решения выбирать, с двойной-тройной дупликацией.

heilnull ★★
()
Ответ на: комментарий от DALDON

Надо тестировать на реальном железе.

У меня не было большого опыта работы с gmirror, чтобы что-то советовать однозначно и наверняка.

iZEN ★★★★★
()
Ответ на: комментарий от iZEN

Ну ладненько, пасибо, будем рады тому чего есть.

DALDON ★★★★★
() автор топика
Ответ на: комментарий от heilnull

Да надо бы. У меня таких серверов вагон... :( Сейчас смотрю уже в сторону Xen кластера.

DALDON ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.