Pull to refresh

Comments 34

Мне бы так сбрасывать баги — «просто не дружат две технологии». У меня «не подружились» микрософтовский NIC teaming в режиме switch independent и свитчи Allied Telesis как два разных устройства. В результате трафик по свитчам просто не ходил. Пришлось в темпе ставить на их место только что снятое оборудование предыдущего поколения. А в чем дело — не знаем до сих пор.
Так, для интереса, а для режима LACP не пробовали настраивать то и другое?
Они же не вместе стоят, чтобы можно было оба порта в один LAG пихнуть на свитче. Два свитча стоят как отдельные (они стек не умеют), сервера одним портом в одном свитче, вторым во втором. С цисками работает, с этими не стало. LACP на интерес включал, тоже без эффекта (может, не так включал? Свитчи друг друга по LACP видели.)
Ссылки в начале поста поправьте пожалуйста, точнее добавьте их.
А про DRAID6 сторвайзовский есть что плохого из практики в плане отказоустойчивости?
По сравнению с RAID5, пржалуй, только скорость. В плане отказоустойчивости нареканий нет
«Так что совет: обновляйте своевременно прошивки и не допускайте разнобоя в версиях.» — Совет — никогда не используйте RAID-5 в продакшене. Никогда.
В данном случае заказчик осознанно шёл на риск, т.к. количество места на сторадже было довольно ограниченным. Ну а в целом полностью поддерживаю. RAID5 под продуктивными средами — дурной тон.
Столько копий сломано на этот счет. Понятно, что 10 идеален, но всё же дороговато. Какой raid, например, стоит использовать для SSD?
Что значит «дороговато»? Дороже или дешевле данных, на нем хранящихся — вот единственный вопрос, который должен интересовать системного архитектора.
Для большей части моих данных да, RAID 10 дороже даунтайма на восстановление из бекапа. Так чем пользоваться то принято в такой ситуации?
Если ваши данные такие дешевые, дешевле одного SSD, то, думаю, из вообще нет смысла защищать (иначе, чем бэкапом, например).
У вас какие-то крайности. Или данные вообще не жалко или отказоустойчивое геораспределённое хранилище.
Да это не у меня крайности. Это вам стоимости второго SSD на надежность хранения данных жалко.
Я как-то упустил, откуда взялся этот самый один второй ssd. Если сравнивать массив из 4 дисков то да, разница между 10 и 5 действительно в один диск. Хотя мне кажется вы просто подразумевали raid 6.
10ка тебе даст 50% шанс на потерю диска из неважной группы. Фактически не лучше RAID-5. Т.е. только RAID-6. Причем из собственного опыта — у меня частенько дохло и по 2 диска в группе за раз и как-то один раз успел вылететь 3 диск. Поэтому шанс в 50% на 2-м диске меня не устраивает.
Сильно лучше за счет более высокой скорости восстановления RAID после сбоя.
Какой же использовать? Только RAID6/RAID60 остаются?

А через время что делать с фрагментацией, которой там только теоретически не бывает?


И, конечно, главный вопрос: если массив развалится, каким софтом в не удастся разобраться, чтобы хотя бы большую часть информации восстановить?


Сам очень люблю zfs, но есть моменты, которые за столько лет так и остались неотвеченными.

А как она проявляется, если она бывает?
Я знаю что FRAG в выводе zpool list — это фрагментация свободного места в пуле. А не, как принято считать, фрагментация файлов.

zfs довольно устойчива к разваливанию. И судя по тому как она хранит данные, то нет особо смысла что-то там восстанавливать при отвалившихся n дисках.

Картинка про то как хранит тут:
github.com/zfsonlinux/zfs/wiki/dRAID-HOWTO

Лично я жду draid в production. Время ребилда будет сильно уменьшено что несомненный плюс.

Я считаю что описанный выше случай с неконсистентностью просто не возможен в zfs by design. В связи с применением «сквозного контроля целостности данных».

Если заполнение диска большое, то фрагментация будет портить жизнь. Кеширования спасают, но не всегда: время поиска у физических дисков все равно никуда не девается.

Да, это описано в документации zfs и является не багой, а фичей. =)
«Keep pool capacity below 80% for best performance»

Так это для всех ФС справедливо. Вопрос в другом: чем лучше и умнее ФС (а zfs сразу и ФС, и ещё много чего в одном флаконе), тем сложнее восстановить данные, если она сама не справится.


И не вариант сказать "пока не умеет, но лет через дцать научится" — в случае zfs лет прошло много.


Поэтому и говорю: ее использовать прикольно, но нужно заранее подумать над двумя вещами, а именно производительностью (потому что её правильно готовить умеют единицы), и шансом на восстановление.


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


Но вообще, да, zfs неплоха. Жаль, что в Линукс ее привезли не так давно.

По второму случаю и проблеме ничего не понятно. Разве на уровне FC не было настроено зонирование? И сервер с основной площадки просто по идее не должен видеть порты массива на второй площадке, хоть таргеты они, хоть инициаторы? Да и в принципе, под репликацию обычно рекомендуются отдельно выделенные под это порты и отдельные зоны для этих портов между массивами. Без пересечений с вводом\выводом от хостов к массивам.


Если есть понимание, как у вас сервер увидел порты массива на удаленной площадке, то поясните пожалуйста.

Если зонирование было корректным (Linux хост не видел wwn'ы контролеров с РЦОД) и предположим, что репликация была синхронной:
То скорее всего заблокировался ввод вывод для определенных lun'ов — а видимо один из них и использовался злосчастным linux'ом.
Вообщем root cause указанных в статье вызывает много вопросов =)
Действительно, описано не совсем очевидно, поясню. Фабрики между площадками не растянуты, но массивы друг друга видят по определенным портам через LSAN. Направленность репликации ОЦОД -> РЦОД. В репликации участвует множество различных LUN'ов с разными хостами, их использующими. Для Windows хостов и хостов VMware манипуляции с контроллером в РЦОДе остались не замеченными. На Linux хостах же появились блокировки и mpath отстрелил все диски, приходящие по SAN.
Про тергетов и инициаторов тоже надо пояснить, что это не корневая причина, а лишь наша версия корневой причины. В чем конкретно заключается корневая причина до конца не ясно.
Статья похоже на какой-то завуалированный «треш», ни пруф линков, ни ценной выжимки с логов… ни модели этих «злосчастных массивов»…
Похоже на байки подвыпивших СЦ Инженеров в Пив-баре

Кака же интересная у Вас работа… как же я хочу там с вами работать) но я только windows сис админ((

В Сервисном Центре Jet Infosystems есть группа wintel, смело можешь туда.
Ребята адекватные.
Raid 5 под критичные базы данных? Серьёзно? Да месье знает толк в извращениях. Вот не понимаю, чем руководствовались люди, которые внедряли это решение
А разве было бы легче, если контроллер с плохой бажной работал на рейд 10, например?
Для критичных БД нужен большой кеш на контроллере, ббу и надёжность повыше. Рейд 6, например.

Что не так в моих рассуждениях?
А можно детали: что за контроллер, сколько дисков было в raid 5, какой размер сектора в RAID 5, что за бренд у дисков, что за операционка?

И про дисковые пулы непонятно. В них из mdisk собирается ещё бОльший рейд?
Кину копейку… Может и не совсем в тему, но близко. У нас однажды (лет 15 назад) на небольшом, но важном файловом сервере посыпался RAID из-за того, что в нем стояли диски, обладавшие встроенной функцией автоматической коррекции ошибок. Поставлены они были туда из-за ошибочного представления одного специалиста о том, что это обеспечит гораздо большую надежность, чем использование «глупых» серверных дисков, которые к тому же «почему-то» еще и дороже… В результате «наличия такого запаса по надежности» состояние RAID'а не мониторилось никем, и был упущен момент, когда постепенно диски начали деградировать. А встроенная их логика, не имеющая представления о вышестоящем RAID, и логика RAID сошлись в клинче… Так что основной причиной падения RAID'ов, как правило, являются ошибки при проектировании системы хранения данных и(или) игнорирование процедур мониторинга набора дисков и каждого из них.
Sign up to leave a comment.