01
Сначала запишите требование к восстановлению
Определите модель отказов простым языком: одно устройство, два устройства, контроллер, случайное удаление или весь сервер. RAID устраняет только некоторые отказы устройств. Установите целевое время восстановления для восстановления услуги и целевую точку восстановления для потери данных, затем определите, какое требование может удовлетворить локальный массив, а какое требует репликации или резервного копирования в другом месте.
Также зафиксируйте, должна ли система продолжать принимать запись в деградированном состоянии. Архив с преобладанием чтения, база данных с интенсивной записью и одноразовое рабочее пространство могут использовать одинаковое число дисков, но требуют разных схем. Поэтому эффективность ёмкости — лишь одно из ограничений, а не окончательный вердикт.
02
Сопоставьте компоновку с рабочей нагрузкой и количеством устройств
Зеркала просты для загрузочного или набора данных на двух устройствах и могут подходить для случайного ввода-вывода, где полезны независимые зеркальные группы. Схемы с четностью жертвуют работой записи и сложностью восстановления ради большей емкости. Двойная четность может сохранить дополнительный запас отказа в широком наборе HDD, в то время как RAID 10 жертвует половиной необработанной емкости ради зеркальных пар. Это тенденции проектирования, а не гарантии производительности; контроллер, файловая система, глубина очереди, размер записи и шаблон приложения имеют значение.
Используйте фактическую топологию каталога. Серверы хранения с 12 дисками и 24 дисками позволяют выбирать варианты, недоступные на вычислительном сервере с двумя NVMe. Не включайте отдельную загрузочную пару NVMe в расчёт массива данных и не предполагайте, что одна очень широкая группа предпочтительнее нескольких групп без моделирования доменов отказов и поведения ввода-вывода.
Сопоставьте компоновку с рабочей нагрузкой и количеством устройств| Вопрос о рабочей нагрузке | Схема для оценки | Причина для проверки |
|---|
| Требуются два локальных устройства и непрерывность | Зеркало | Ёмкость одного устройства и простое деградированное состояние |
|---|
| Широкий пул HDD с требованием устойчивости к двум отказам | RAID 6 или RAIDZ2 | Ширина чётности, нагрузка при восстановлении и рекомендации по файловой системе |
|---|
| Случайные записи и несколько пар одинаковых дисков | RAID 10 или зеркалированные vdev | Компромисс емкости и реальная задержка рабочей нагрузки |
|---|
| Одноразовые данные с воспроизводимым источником | RAID 0 может рассматриваться | Потеря любого члена приводит к потере массива |
|---|
03
Выберите один уровень для обеспечения избыточности
Решите, кто управляет структурой: аппаратный контроллер, Linux MD или файловая система, например ZFS. Не объединяйте независимые слои RAID без документированной причины, поскольку состояние работоспособности и замены может стать неоднозначным. Резервирование ZFS выражается через зеркала или vdev RAIDZ и основано на контрольных суммах; потеря vdev верхнего уровня может привести к потере пула, поэтому добавление одиночного нерезервированного устройства в избыточный пул изменяет модель отказов.
Подтвердите идентификацию диска, процедуру замены, поведение при загрузке и то, что операционная система может наблюдать, перед созданием массива. Изменение топологии позже может быть ограничено или вызвать disruption, особенно для схем с чётностью.
04
Спланируйте окно деградации и восстановления
Мониторинг должен различать состояния: исправен, деградирован, реконструкция и проверка согласованности. Linux MD предоставляет такие действия, как resync, recover, check и repair; собирайте прогресс и несоответствия, а не сообщайте только о том, что том смонтирован. Грязный и деградированный RAID 5 или 6 может представлять риск повреждения, поэтому принудительная сборка никогда не должна быть обычным способом восстановления.
Документируйте маршрутизацию оповещений, приобретение запасных частей, идентификацию замены, ограничение рабочей нагрузки и момент, когда восстановление безопаснее продолжения. Никогда не обещайте длительность перестроения без измерения поставленных устройств, нагрузки массива и контроллера.
05
Зафиксируйте выбор и его ограничения
Завершенный проект должен указывать схему, предположения об одинаковых дисках, оценку полезной емкости, допустимые сбои, источник мониторинга и место восстановления. Храните версионные данные в другом домене сбоя и тестируйте восстановление. Ожидаемый результат — это не утверждение, что RAID предотвращает потерю; это массив, поведение при сбоях и ответственность за восстановление которого понятны до поступления производственных данных.
Прямые ответы
Вопросы по этому руководству
Всегда ли RAID 6 является лучшим выбором для большого сервера HDD?
Нет. Оно предлагает устойчивость к двум отказам, но ввод-вывод рабочей нагрузки, ширина vdev или массива, рекомендации по контроллеру или файловой системе, операции перестроения и цель восстановления по-прежнему определяют схему.
Может ли горячий резерв заменить внешнюю резервную копию?
Нет. Резервный диск может сократить время до начала восстановления, но он остаётся в том же сервере и не защищает от удаления, компрометации, повреждения, распространяющегося по стеку, или потери площадки.