Является ли трехсторонний RAID1 с использованием mdadm хорошим решением для обеспечения устойчивости любых двух дисков без сбоя RAID? Я знаю, что это требует дополнительных затрат в смысле возможности использовать только 1/3 дискового пространства (1 из 3 дисков), но что насчет этого?
Чтобы иметь один массив, способный к отказу двух дисков, у вас есть два варианта:
Какой лучший выбор? Это зависит от того, чего вы пытаетесь достичь.
Замечание о снижении производительности RAID1: да. не зависят от перегрузки шины, а скорее от того, как на среднее время поиска на диск влияют множественные записи. Время поиска диска состоит из двух разных частей: искать задержку (время, необходимое для достижения правильного угла головы) и задержка вращения (время, необходимое для поворота диска в правильное положение).
Когда задействовано несколько дисков, это несколько идентичных записей, задержка вращения, измеренная хостом, будет наихудший всех задействованных дисков. С другой стороны, время поиска должно быть относительно одинаковым для дисков с RAID1. В конечном итоге это означает, что массивы RAID1 будут иметь несколько более низкие значения IOPS записи по сравнению с одним идентичным диском.
В mdadm Linux есть интересное положение, позволяющее минимизировать влияние латентности различных дисков. Например, прочтите справочную страницу о "обратной записи" и "в основном записи":
-W, --write-преимущественно последующие устройства, перечисленные в командах --build, --create или --add, будут помечены как «в основном для записи». Это действительно только для RAID1 и означает, что драйвер 'md' будет избегать чтения с этих устройств, если это вообще возможно. Это может быть полезно при зеркалировании по медленной ссылке.
--write-behind = Укажите, что режим отложенной записи должен быть включен (действительно только для RAID1). Если аргумент указан, он устанавливает максимальное разрешенное количество невыполненных операций записи. Значение по умолчанию - 256. Для использования режима отложенной записи требуется растровое изображение с намерением записи, а попытка отложенной записи выполняется только на дисках, отмеченных как предназначенные для записи в основном.
Обратите внимание, что это снизит производительность IOPS при произвольном чтении (поскольку некоторые диски будут эффективно использоваться только для записи), так что будьте осторожны, выбирая яд.
Да, вы можете добавить столько зеркал к RAID1, сколько захотите, и вы можете допустить отказы всех устройств, кроме одного. Если добавить 10 устройств, можно допустить отказ 9 устройств.
Не забывайте, что для этой настройки будет штраф записи. Все данные должны быть записаны на каждое устройство. Как правило, это должно быть довольно незначительно, но если все устройства находятся на одном контроллере / шине, вы можете начать замечать задержки, поскольку ваши данные записываются на каждое устройство. Например, с 3 устройствами для записи 1 МБ данных в массив требуется, чтобы контроллер / шина фактически записал 3 МБ на диск.
Другое решение - raid 6 с 3 дисками. См. Этот пост:
Минимальное количество дисков для реализации RAID6
Raid 6 также позволит удвоить емкость, добавив четвертый диск. У меня было 2 сбоя диска в массиве и не потеря данных.
Я всегда был большим поклонником аппаратного RAID 5. Я обычно использую Ubuntu Linux в качестве сервера, если это позволяет запланированное использование. С аппаратным RAID-массивом Ubuntu (как и любая другая операционная система) не имеет проблем при загрузке с массива RAID-5 на большинстве современных серверов. Еще я использую несколько резервных копий. Первое резервное копирование - это ежечасное резервное копирование на сервере на внешний диск с использованием функции Back-In-time для обеспечения резервного копирования на месте каждый час в рабочее время. Резервное копирование второго уровня - это еженощное резервное копирование общих сетевых дисков с помощью другого компьютера под управлением Ubuntu и Back-In-Time. Ночные резервные копии также делаются на портативные USB-накопители, и по крайней мере один хранится за пределами предприятия. Диски меняются ежедневно в течение рабочей недели. Резервное копирование третьего уровня выполняется на удаленный компьютер с Windows Vista под управлением Ubuntu Linux, настроенный аналогично конфигурации сервера, где каждую ночь файлы сервера синхронизируются с системой резервного копирования с помощью утилиты Linux rsync. RAID-5 (с горячим резервом) был хорош в последние несколько лет, когда случались отказы дисков. Неисправный диск (с возможностью горячей замены) заменялся в каждом случае без прерывания сетевой активности. RAID-5 не помогал, когда на сервере происходил серьезный сбой, вероятно, из-за сбоя материнской платы или памяти. Что действительно помогло, так это резервный сервер резервного копирования, на котором были синхронизированные файлы после закрытия бизнеса предыдущей ночью. У меня есть небольшой сценарий, который я запускал для переноса конфигурации сервера на резервный сервер, который переносит все учетные записи пользователей и компьютеров, превращая резервный компьютер во временный основной контроллер домена. Пару часов ушло на то, чтобы собрать еще один вышедший из эксплуатации компьютер с Windows, чтобы сделать новую резервную компьютерную систему и запустить ее. Я решил заменить более дорогой сервер Proliante ML350 на более скромный сервер Proliant ML10. Я буду настраивать новый сервер с RAID-1 как 3-дисковое зеркало с горячим резервом. Заказанный мной сервер ML10 использует программный RAID-контроллер, который должен быть настроен как AHCI вместо RAID для загрузки Ubuntu. Общая стоимость сервера и четырех дисков емкостью 1 ТБ примерно равна стоимости одного диска емкостью 300 ГБ в ML350. Это второй раз за 25 лет управления серверами. RAID-5 не помог (первый раз, вероятно, был отказ RAID-контроллера). Оба случая - это не проблема RAID, а проблема, возникающая в результате использования технологии.
Главное, что я хочу сказать, - это быть готовым к сбоям вашего сервера и иметь хороший план резервного копирования. Чтобы составить хороший план резервного копирования, вы должны действительно протестировать процедуры резервного копирования и восстановления. В случае самого последнего сбоя, к общему времени с момента, когда мне позвонили, заставили встать с постели, одеться, быстро перекусить, выйдя за дверь, поехать на место (10 минут езды), диагностировать проблема (включая попытку перезапуска сервера), а подключение резервного сервера к сети заняло 52 минуты.
Вы можете обсудить, какая из возможностей RAID лучше. Просто имейте в виду, что могут выйти из строя не только жесткие диски. Используйте тот тип RAID, который, по вашему мнению, лучше всего подходит для вашего использования, но спланируйте восстановление из-за сбоя оборудования или атаки вредоносного ПО или вируса.
Во-первых, я считаю важным отметить сценарий использования и качество используемых компонентов. Это не то же самое, если вы используете настольные жесткие диски и дешевые рейд-контроллеры или используете полноценное корпоративное оборудование.
Если единственное, что вы делаете, - это репликация между жесткими дисками (RAID1), вы можете позволить себе потерять n-1 жестких дисков и при этом сохранить все данные нетронутыми.
Но я действительно хотел бы знать, каков ваш сценарий использования и выбор оборудования, что вас так беспокоит потеря двух дисков одновременно?
Недавно я установил веб-сервер для интернет-провайдера. Сервер имел 6-портовый RAID-контроллер. Итак, я установил RAID 60 как хороший компромисс между скоростью и безопасностью.
Советую прочитать это ссылка на сайт
Что касается вашего разъяснения, я настоятельно рекомендую выбрать RAID 5 или RAID 60 ... В качестве альтернативы, если проблема в цене, будет достаточно простого RAID0 с двухуровневым резервным копированием за пределами площадки.
Мои ссылки - это мой собственный опыт настройки множества серверов в самых разных сценариях использования.