Умер софтовый RAID-1 на gmirror

[Fastman]

пошёл хелп читать...

http://technet.microsoft.com/ru-ru/libr ... S.10).aspx

[Хостинг HostFood.ru]

Тарифы на хостинг в России, от 12 рублей: https://www.host-food.ru/tariffs/hosting/
Тарифы на виртуальные сервера (VPS/VDS/KVM) в РФ, от 189 руб.: https://www.host-food.ru/tariffs/virtualny-server-vps/
Выделенные сервера, Россия, Москва, от 2000 рублей (HP Proliant G5, Intel Xeon E5430 (2.66GHz, Quad-Core, 12Mb), 8Gb RAM, 2x300Gb SAS HDD, P400i, 512Mb, BBU):
https://www.host-food.ru/tariffs/vydelennyi-server-ds/
Недорогие домены в популярных зонах: https://www.host-food.ru/domains/

[Alex Keda]

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

[Fastman]

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

Так это и есть ниша таких решений. По крайней мере при правильном бубне все воркает прилично.
В остальных случаях - сорри.. данные стоят денужек

[rambomax]

Это неверный вывод.
RAID != бэкап. RAID стоит в цепочке локализации точек отказа совсем в другом звене, и предназначен для создания избыточности информации в мгновенный/краткий период времени. А так же для увеличения производительности дисковой системы(IOPS/Линейные операции/Паралелльный доступ). Никогда и никакой RAID не заменит бэкапа.
По поводу софтового решения зеркалирования дисков. Если вы решите купить контроллер за деньги 300-400 долларов, то вы потратите их зря, и по надежности это решение будет ровненько с софтовым рейдом, а чаще - и того хуже. Конечно, для того чтобы обеспечить отказоустойчивость программными средствами - необходимы умение и понимание того что вы делаете.

Спасибо за комментарий к моим выводам!
Я полностью согласен с вами, более того, всё это азбучные истины.
В моём конкретном случае ключевые пункты следующие:
1) Компания маленькая
2) Решения дешёвые
3) RAID софтовый
Ключевой вопрос: что можно сделать за небольшие деньги, чтобы существенно увеличить надёжность сервера.
На Windows серверах я ставлю софтовое зеркало с помощью бесплатного Symantec Veritas Storage. Цена вопроса - две тыр на второй винт. Результат - практически удвоение скорости чтения (замерено тестом), увеличение надёжности хранения данных. Т.е. очень яркий результат за малые деньги.
С FreeBSD такого не получилось. Файловая система не журналируемая, поэтому потеря данных от разрушения файловой системы что с софтовым RAID-ом, что без него одна и таже. diskinfo -t /dev/mirror/gm0 говорит о том, что никакой прибавки скорости я не получил. Получается, что я не вижу смысла усложнять систему ещё одной точкой отказа. За малые деньги я не получаю никакого ощутимо положительного результата. Более того, с учётом того, что маленькая компания может позволить себе потратить пару часов на восстановление данных из традиционного бакапа, нет никакого смысла покупать и дорогой аппаратный RAID.
Задача сервера - файловое хранилище, E-MAIL, instant messaging, DNS, DHCP, VPN, WWW-proxy, маленький корпоративный WWW. Получается что для такого зверька вроде софтовый RAID бессмысленен. Теперь мне даже кажется что и 4Гб памяти я не понимаю зачем туда воткнул, вроде достаточно 2 и тогда более надёжная 32-битная ОС.

Уважаемые пользователи gmirror на FreeBSD! Пожалуйста, напишите, каков на ваш вгляд эффект от внедрения софтового райда и при каких условиях этот эффект проявляется (какова эффективная область применения этого решения).

[Alex Keda]

от разрушения файловой системы никакой журнал не спасёт.
так, к сведению.
=======
что касается журнала

Код: Выделить всё

man gjournal

у меня работает, в частности, прям на этом сервере

Код: Выделить всё

hosting$ mount
/dev/mirror/gm0s1a on / (ufs, local, soft-updates)
devfs on /dev (devfs, local)
/dev/mirror/gm0s1f.journal on /home (ufs, asynchronous, local, noatime, nosuid, gjournal)
/dev/mirror/gm0s1d on /usr (ufs, local, soft-updates)
/dev/mirror/gm0s1e on /var (ufs, local, soft-updates)
/dev/ad7s1d on /backup (ufs, local, soft-updates)
procfs on /proc (procfs, local)
tmpfs on /tmp (tmpfs, local)

[Fastman]

На Windows серверах я ставлю софтовое зеркало с помощью бесплатного Symantec Veritas Storage. Цена вопроса - две тыр на второй винт. Результат - практически удвоение скорости чтения (замерено тестом), увеличение надёжности хранения данных. Т.е. очень яркий результат за малые деньги.

Вот это мне непонятно. Тут теорию даже читать не нужно.
Ну не может зеркалирование увеличивать скорость чтения/записи. При зеркалировании как правило наблюдается ухудшение производительности, за счет избыточности. Надо ведь успевать записать данные не только на один HDD но и на второй, а после сравнить их и убедиться что все верно.
И еще, пока все это беспредметно пока вы не укажете какой тип доступа к данным и тип самих данных (файлы/мультимедия/база данных). От этого много зависит очень.
И не сочтите за это за понты/перегибание... Надежность данных - стоит денег. Чем больше важность данных тем больше нужно ноликов к сумме добавлять.
В вашем случае ключевая ошибка - сразу выбор инструмента без создания политики и аудита хранения/надежности/бэкапа данных.
Советую:
1. Понять точки где отказ неприемлим.
2. Сроки допустимого простоя в этих точках.
3. Вероятность потери данных в зависимости от типа избыточности.

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

[ev]

Ну не может зеркалирование увеличивать скорость чтения/записи.

может - ведь читаться информация может одновременно в разных винтов

[Fastman]

Ну не может зеркалирование увеличивать скорость чтения/записи.

может - ведь читаться информация может одновременно в разных винтов

Да, может. Софтовые решения почти все умеют чтение с чередованием. Аппаратные контроллеры - не все умеют TwinStor.
Только все это херня. RAID1 - для избыточности и надежности.
и вообще, RAID работает не так как вы думаете, а так как он работает

[E-Wind]

Уважаемые пользователи gmirror на FreeBSD! Пожалуйста, напишите, каков на ваш вгляд эффект от внедрения софтового райда и при каких условиях этот эффект проявляется (какова эффективная область применения этого решения).

Один из двух 750 гигабайтников посыпался.... заменил на новый... rebuild... работает дальше (тук тук тук)
Но какое-то время машина работала на одном диске...

[rambomax]

Поскольку "дохляк" сейчас находится на вскрытии, я провёл эксперимент: дождался, когда массив полностью синхронизуется, а потом вырубил питание. Первый раз всё поднялось, gmirror status сказал COMPLETE. На второй раз массив уже развалился. На третий раз сервер загрузился. На пятый раз разрушение файловой системы не дало зверьку загрузиться.
Железка не подключена к сети, нагрузки на ней нет. Получается, зеркало развалилось в DEGRADE на скачёк напряжения в сети. Если бы сервер стоял под нагрузкой, то со стороны пользователей процесс восстановления зеркала смотрелся бы как страшные тормоза на весь оставшийся рабочий день - 500Гб у меня примерно пять часов синхронизуются.
Уважаемый lissyara!
А введение журнала сделает лечение убитых таким образом файловых систем простым и автоматическим? Ведь основная проблема в лечении, это то, что оно не должно требовать подключать монитор, клавиатуру и т.д. (КВМ нет).

[E-Wind]

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

[rambomax]

Падение файловой системы из-за "электрических" проблем решаются бесперебойником...

В последний раз у нас в конторе свет вырубали внезапно, без объявления войны. Сначала на три часа. Бесперебойник выдержал. Потом резко выключили и почти сразу же включили. И так два раза с интервалом в десять минут. Итог: сдохло всё - "бесперебойник" и файловые системы на фре.
Журналирование изначально не свойственно фрёвой файловой системе. Значит, стандартный FSCK о нём знать не может. Прикручивание журнала должно обязательно обновлять FSCK. В манах ничего про это не пишут. Неужели магическим образом при включении журналирования ошибки файловой системы исчезнут?

[Fastman]

Падение файловой системы из-за "электрических" проблем решаются бесперебойником...

В последний раз у нас в конторе свет вырубали внезапно, без объявления войны. Сначала на три часа. Бесперебойник выдержал. Потом резко выключили и почти сразу же включили. И так два раза с интервалом в десять минут. Итог: сдохло всё - "бесперебойник" и файловые системы на фре.
Журналирование изначально не свойственно фрёвой файловой системе. Значит, стандартный FSCK о нём знать не может. Прикручивание журнала должно обязательно обновлять FSCK. В манах ничего про это не пишут. Неужели магическим образом при включении журналирования ошибки файловой системы исчезнут?

Еще раз рассказываем....
Вы хотите защиту от катастроф ??? Это стоит денег если покупать. Если своими силами - то стоит немного меньших денег+ваши знания.
Никакие журналы ни на какой файловой системе не спасают от от выключения питания/бросков напряжения. Если выжила файловая - то это просто везение. Или вы думаете что BBU для железных RAID контроллеров стоят как пол-контроллера просто так ?
Журналирование - ПОВЫШАЕТ ВЕРОЯТНОСТЬ сохранности целостности файловой системы. И не несите глупости по FSCK, он работает поверх файловой системы, и если к файловой системе прикручено журналирование - то этого достаточно(он ведь сканирует метаданные файловой системы, если журнал корректно восстановил мету - все будет нормально).

[rambomax]

Вы хотите защиту от катастроф ???

Хотя бы приблизить надёжность фришной файловой системы к NTFS. За всю свою историю мучений с железками (приход в мир NTFS совпал с началом моей трудовой деятельности) я лишь пару раз видел чтобы система не загрузилась из-за битого файла. А вот с FreeBSD это происходит постоянно. Достаточно щёлкнуть выключателем или нажать на ресет.
В нашей конторе я единственный шаман, который знает про консоли и FSCK. А мне очень хочется иногда в отпуск. Очень обидно бывает ехать куда-то в выходной, потому что какой-нибудь ...ный /tmp не смонтировался из-за внезапной перезагрузки. Особенно обидно читать в инете, что в линухе туча файловых систем и такого не бывает и никакие fscк не требуются.
Сейчас как раз внутренности железки зависят только от меня. Природная лень и небольшая нехватка времени останавливают меня от перехода на неубиваемый линукс. Если можно хоть как-нибудь приблизится к желанному результату (возможно большей вероятности загрузки после выключения без размонтирования ФС), то я поставлю и зеркала и журналы.
Только информация очень противоречивая. Вот тут - http://blog.lexa.ru/2008/12/07/uprazhne ... mance.html и райды и журналы ругают аргументировано. В других местах местах клянут неаргументировано.
Почему-то не нашёл ни одного восторженного отзыва про журналирование - только ругань. Про зеркалирование - у всех всё как у меня.
Если журналирование, как пишут, действительно делает мгновенным fsck при старте, то получается, что для маленькой конторы лучше журнал плюс традиционный бакап.

[Larin]

странный ты.
у меня ничего не падает.

[E-Wind]

В последний раз у нас в конторе свет вырубали внезапно, без объявления войны. Сначала на три часа. Бесперебойник выдержал. Потом резко выключили и почти сразу же включили. И так два раза с интервалом в десять минут. Итог: сдохло всё - "бесперебойник" и файловые системы на фре.

А какой бесперебойник?

[Fastman]

Хотя бы приблизить надёжность фришной файловой системы к NTFS. За всю свою историю мучений с железками (приход в мир NTFS совпал с началом моей трудовой деятельности) я лишь пару раз видел чтобы система не загрузилась из-за битого файла. А вот с FreeBSD это происходит постоянно. Достаточно щёлкнуть выключателем или нажать на ресет.

Мы наверное живем в параллельных вселенных. Я видел много NTFS убитых еще и не таким жестоким образом. Сервера BSD у меня вообще ни разу
не падали в нуль. А при этом на базе BSD у меня построенно свое решение которое работает в режиме 24/7 и занимается кодированием видео !

В нашей конторе я единственный шаман, который знает про консоли и FSCK. А мне очень хочется иногда в отпуск. Очень обидно бывает ехать куда-то в выходной, потому что какой-нибудь ...ный /tmp не смонтировался из-за внезапной перезагрузки. Особенно обидно читать в инете, что в линухе туча файловых систем и такого не бывает и никакие fscк не требуются.

Извините.. но насчет линуксовых файловых систем я просто помолчу... они ровно всей кучкой своей хуже по стабильности. безпричинное пропадание файлов на XFS и запись нулей в открытые(в них даже записи не было..просто открыты были) файлы при пропадании напряжения - это факт не единственный. Работают они вменяемо при защиете фильтрами и упсами серваков.

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

Неубиваемых систем нет. Точка. Исходите из этого.

Только информация очень противоречивая. Вот тут - http://blog.lexa.ru/2008/12/07/uprazhne ... mance.html и райды и журналы ругают аргументировано. В других местах местах клянут неаргументировано.
Почему-то не нашёл ни одного восторженного отзыва про журналирование - только ругань. Про зеркалирование - у всех всё как у меня.
Если журналирование, как пишут, действительно делает мгновенным fsck при старте, то получается, что для маленькой конторы лучше журнал плюс традиционный бакап.

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

[rambomax]

А какой бесперебойник?

IPPON SMART WINNER 1500

[rambomax]

Вы почему то упрямо не хотите получить знания и ищете способы отказаться от BSD. Тут вот народ реально тертый, фанатизмом не страдаем... может прислушаться ?

Напротив, я тут изо всех сил пытаюсь получить знания. А точнее хороший совет: оставить ли gmirror, срубить ли его. Накатить ли gjournal или нет. За это время я уже успел изнасиловать вскрытого зверька всякими возможными способами. Измученное тельце на картинке.
Оказывается, синхронизация софтового райда не всегда занимает пять часов - сегодня после FSCK -y /dev/mirror/gm0 синхронизация прошла за пару часов. Но сам fsck занял почему-то весь мой обед.
Хотелось бы попробовать сделать журнал и потыкать ресет, останавливает одно: нигде не написано, какого размера должен быть раздел под журнал в зависимости от размера журналируемой фс. По умолчанию он гиг. Нашёл только одно упоминание, что гиг слишком мало. Но сколько надо все скрывают...

[Alex Keda]

Код: Выделить всё

HP# grep fsck /etc/defaults/rc.conf
fsck_y_enable="NO"      # Set to YES to do fsck -y if the initial preen fails.
background_fsck="YES"   # Attempt to run fsck in the background where possible.
background_fsck_delay="60" # Time to wait (seconds) before starting the fsck.
HP#   

и он подымется без вас.
=======
а вообще - после прикручивания журанала больше не видел fsck
в мане так вообще написано:

Код: Выделить всё

     Когда gjournal сконфигурирован поверх поставщиков gmirror(8) или
     graid3(8), они также поддерживаются в целостном состоянии, поэтому авто-
     матическая синхронизация после сбоя питания или отказов системы может
     быть на этих поставщиках отключена.

[iZEN]

сегодня после FSCK -y /dev/mirror/gm0 синхронизация прошла за пару часов. Но сам fsck занял почему-то весь мой обед.

У вас отключено Soft-Updates, раз fsck в фоне не может работать. (Естественно, ведь журналирование gjournal и Soft Updates — взаимоисключающие вещи).

Хотелось бы попробовать сделать журнал и потыкать ресет, останавливает одно: нигде не написано, какого размера должен быть раздел под журнал в зависимости от размера журналируемой фс. По умолчанию он гиг. Нашёл только одно упоминание, что гиг слишком мало. Но сколько надо все скрывают...

1. Журнал может располагаться на том же диске, что и файловая система, а может располагаться на отдельном диске — заводить отдельный раздел под журнал на том же диске, где раздел с данными, не имеет смысла. Журнал на отдельном устройстве хранения увеличит производительность.
2. Размер журнала зависит от объёма данных. Например, на 8ГБ разделе под журнал выделяется до 1ГБ пространства — почти 15% объёма!
3. Для журналируемой ФС нужно указывать параметр async при монтировании, так как заботу о целостности данных берёт на себя журнал.

[Alex Keda]

например, у меня на всех серверах fsck в фоне в принципе отключено.

[rambomax]

Итак, приступаю к экспериментам с журналом.
В мане (http://www.freebsd.org.ua/man/gjournal.8.html) написано:

-s размер_журнала
Задаёт размер журнала в случае, если один и тот же
поставщик используется для хранения как данных, так и
журнала. По умолчанию один гигабайт. Размер должен
выбираться исходя из загруженности поставщика, а не его
размера. Не рекомендуется использовать gjournal для
небольших файловых систем (например, размером всего в
несколько гигабайт).

Пишут, что 1Гб недостаточно, обязательно надо увеличивать.
Собираюсь журналировать /usr - примерно 300 Гб и /var - примерно 100 Гб
Сколько выделить под журнал?
Делать буду так:
сейчас едет слив содержимого /usr и /var на другой комп
tar cvfj - /usr | ssh -l user 10.0.1.1 dd of=/home/user/baskup/usr.tar.bz2
потом сделаю
gjournal load
размонтирую /usr
gjournal label /dev/mirror/gm0s1e -s ????
newfs -J /dev/mirror/gm0s1e.journal
смонтирую /usr
mount -o async /dev/mirror/gm0s1e /usr
залью данные
ssh -l user 10.0.1.1 dd if=/home/user/baskup/usr.tar.bz2 | tar xvfj -
Поправлю fstab

Как думаете, выйдет такой способ?

[Alex Keda]

зачем вам /usr такого размера?
я на больших дисках делаю /shares

[rambomax]

зачем вам /usr такого размера?

задачи на сервере ещё не устоялись. Поживёт так какое-то время, наберётся статистика, можно будет что-то решать. Тоже самое и с /var - там почта, сколько её будет пока непонятно.

Прикрутил журнал к /var. Всё прокатило как по писаному. Лог:

Код: Выделить всё

/var: unmount pending error: blocks 8 files 0
GEOM_LABEL: Label for provider mirror/gm0s1d is ufsid/4a0a5ffe76f078cd.
GEOM_LABEL: Label ufsid/4a0a5ffe76f078cd removed.
GEOM_LABEL: Label for provider mirror/gm0s1d is ufsid/4a0a5ffe76f078cd.
GEOM_LABEL: Label ufsid/4a0a5ffe76f078cd removed.
GEOM_LABEL: Label for provider mirror/gm0s1d is ufsid/4a0a5ffe76f078cd.
GEOM_LABEL: Label ufsid/4a0a5ffe76f078cd removed.
GEOM_JOURNAL: Journal 89648588: mirror/gm0s1d contains data.
GEOM_JOURNAL: Journal 89648588: mirror/gm0s1d contains journal.
GEOM_JOURNAL: Journal mirror/gm0s1d clean.
GEOM_LABEL: Label for provider mirror/gm0s1d is ufsid/4a0a5ffe76f078cd.
GEOM_LABEL: Label for provider mirror/gm0s1d.journal is ufsid/4a1fb3b02ff8917e.
GEOM_LABEL: Label ufsid/4a1fb3b02ff8917e removed.

Смущают слова removed - чего он сначала меткой хвалится, а потом её удаляет?
И ещё. Теперь у меня журналируемое зеркало. Как отключить его ребилд?