![]() |
Программный RAID 1 (Зеркальные тома): плюсы, минусы, подводные камни
Какие имеются основные минусы и подводные камни в программном RAID 1?
Пока выяснил 1 явный: долгая синхронизация после внезапной перезагрузки и при этом непонятно, какой статус и сколько осталось еще ждать. Работать можно, но дисковые операции медленнее. p.s. пожалуйста, воздержитесь от рекомендации приобрести аппаратный raid. Меня интересует, что ждать от программного raid'а. |
choodo, у обычного низкоуровневого RAID1 нет никаких "плюсов", и разницы тут практически никакой: что аппаратный, что программный.
|
choodo, при том RAID-1 предназначен не для обеспечения сохранности информации, в для повышения живучести системы при выходе из строя одного из дисков (т.е. сохранность информации обеспечивается лишь косвенно). Например, шифрующему трояну всё равно что шифровать: данные на одиночном диске — или данные на RAID. Точно так же, как и шаловливым ручкам всё равно, где удалять или портить информацию.
|
Цитата:
Разница глобальна - в загрузочном секторе - в случае програмного RAID 1 загрузочный сектор есть только на одном из дисков и если именно он выйдет из строя система стартовать не будет без вмешательства извне... Да - возможно руками его переписать заранее и тогда отличия почти не будет(данные загрузочных секторов синхронизироваться не будут) в плане отказоустойчивости. |
Цитата:
но при разумном подходе результат идентичный |
Цитата:
Учитывая что практически на любой, относительно(до 5 лет), новой матери есть полуаппаратный недорейд который для целей RAID 1 идентичен в поведении с нормальным аппаратным RAID-контроллером. |
Цитата:
- убираю умерший, ставлю новый аналогичный, синхронизация массива - если аналогичного нет беру 2 новых - > новый масив, перенос данных со старого. Если у меня данные на 1 диске, и диск умер, и, Внимание, не сразу, а в течении месяца, и я (такой плохой админ) сразу-то не уследил что диск умирает, как итог получил то что половина данных с него либо не архивировалась - т.к. исходные файлы битые и была ошибка записи, либо данные архивировались, но были уже поврежденные. А был бы RAID 1 (аппаратный, конечно) - ничего такого не было бы. И возвращаясь к вашему посту, у любого RAID, несущего отказоустойчивость, эта отказоустойчисовть и является (ИМХО) плюсом - избавляет от гемора на ровном месте. И когда я читаю ваше мнение, а вы - опытный и неглупый специалист, оно меня сильно удивило. Может я не знаю чего-то, а вы знаете, и у вас такое мнение - просветите меня. Цитата:
- Дополнительный минус - нагрузка на проц компа, т.к. ОС задействует проц компа при вычислениях связанных с RAID. |
choodo,
Главное надо всегда помнить: элементная основа аппаратного/полуаппаратного рейда - диск, элементная основа программного рейда - том. Отсюда и все особенности. |
__sa__nya, это очень наивное заблуждение, что RAID1 заменяет бэкап и компенсирует плохого админа.
RAID1, это в принципе "псевдоотказоустойчивость": современные HDD слишком умные и работают несинхронно, а на уровне массива нет контрольных сумм. Сбой по питанию (а это наиболее частая ситуация для подобных бюджетных решений - кто покупает серверы с двумя БП и два ИБП на дисках не пытаются выкроить лишний рубль) приводит к тому, что два диска содержат разные, но консистентные данные. Причём это не детектится: сегодня этот блок прочитали с первого диска, а завтра - со второго. Купить аппаратный RAID контроллер с поддержкой только зеркала нереально. Вот и получается, что мы покупаем контроллер + три диска и делаем на этом зеркало, а третий диск кладём на полочку. Либо покупаем 4 диска меньшего размера и собираем RAID 5e/5ee/6, имеем пересборку массива на лету, полноценную отказоустойчивость и другие приятные плюшки. Цитата:
Но на самом деле при современном уровне виртуализации закладываться на BSOD'ы особого смысла нет: ну завалит 1с гостевую ОС, softRAID так и будет продолжать работать в своём изолированном пространстве. y--, посекторное копирование дисков и загрузчики не нужны: UEFI Цитата:
upd: Цитата:
1. Сделать RAID1 и всё туда засыпать. В случае сбоя делать полную синхронизацию дисков, потом чекать ФС. В случае выхода диска из стоя - втыкать резервный и делать ребилд. 2. Разложить БД на два диска: отдельно данные, отдельно лог транзакций. В случае сбоя только чекаем ФС. В случае выхода диска из строя - втыкаем резервный. Если вышел из строя диск с логом транзакций - просто создаём новый и тут же продолжаем работу. Если с БД - восстанавливаем бэкап, и докатываем транзакции. Это обычно быстрее чем полное посекторное копирование всего диска, Поэтому простой меньше плюс БД работает резвее. Резервирование можно делать на разных уровнях. Если прижиматься и экономить, то более высокие уровни эффективнее, т.к. понимают природу данных. Но отчасти вы правы: подобный подход требует больше |
Цитата:
ЗЫ - все люди хешируются по условию - те кто восстанавливал систему после отказа первого диска из программного зеркала и все остальные... |
Busla, в более чем половине сказанного не согласен с вами, не хочу тратить время на споры. Как говорится - сколько людей, столько и мнений. Видимо у нас с вами опыт использования RAID-массивов и их восстановления отличается.
|
Время: 13:08. |
Время: 13:08.
© OSzone.net 2001-