Rebuild raid 1 что значит
В случае выхода из строя даже 1-го из дисков в RAID -массиве крайне соблазнительным выглядит воспользоваться HotSpare диском, либо же заменить вышедший из строя диск на аналогичный, и насладиться функцией Auto - Rebuild (если таковая есть у RAID -контроллера), или же запустить Rebuild вручную.
Если вам дороги ваши данные – абсолютно неверный путь!
Почему – поясню на примере.
Массив, RAID 6, из порядка 16 HDD , уже пару лет поработавший.
Понятно, что все диски в нем в более-менее одинаковом состоянии.
Выходит из строя 2 диска.
Пока – ничего страшного.
А при запуске процедуры Rebuild – выходит из строя еще 3 диска.
И это – как раз нормальная, типичная ситуация.
Исходя из практики, при выходе из строя диска в массиве, наличии HotSpare -диска и включенной опции Auto - Rebuild можно с вероятностью порядка 20-50% прогнозировать потерю данных, хранившихся на массиве.
Каков правильный путь в случае выхода из строя даже 1-го диска в массиве?
1. Останавливаем всякую работу с наиболее ценными данными. По возможности – со всем массивом. Задача – исключить или минимизировать запись.
2. Делаем Backup вначале наиболее ценных данных, затем всех остальных. Backup всех ценных данных разворачиваем и проверяем, что он «не битый», данные действительно корректны. Если удалось сделать полный backup , все данные развернуты на тестовой площадке и корректны – считаем, что крупно повезло.
3.1. Идеально – вынимаем аккуратно каждый диск и делаем его копию на аналогичный. Дале работаем с копией. Если находящаяся на дисках информация ценна, и не удалось сделать ее полноценны Backup – это единственно правильный путь. Не удалось самостоятельно восстановить данные на копии массива – обращаемся в специализированные компании, передавая им оригиналы дисков из массива.
3.2. Если сильно спешим, готовы рискнуть, полного комплекта дисков на замену нет, и успешно выполнился Backup (и проверена целостность данных) – вставляем диск «на замену» и запускаем Rebuild . Если больше ни одни диск не «отвалится» (а мы помним, что диски находятся в плюс-минус одинаковой степени износа) – за относительно короткое время массив будет восстановлен.
4. Если массив удалось восстановить процедурой Rebuild – радуемся, работаем дальше и наблюдаем по SMART за состоянием дисков.
5. Если массив восстановить не удалось – то либо создаем новый и восстанавливаем информацию из backup , либо ждем результатов от специализирующееся на восстановлении данных компании.
Оптимально воздержаться от использования функцией Auto - Rebuild в RAID -массивах, т.к. это крайне небезопасно.
К примеру , в Microsoft Storage Spaces функции Auto-Rebuild нет .
P . S .: Спасибо коллегам, что обратили внимание.
Описанный подход применим к одиночным дисковым массивам,
и не применим к отказоустойчивым дисковым массивам с нулевым окном обслуживания в S LA .
Добрый день. Производил установку дисков в сервере. Случайно задел шнур идущий к диску, после этого загрузился увидел что рейд повреждение. Выключил нашел, где не подсоединен шнур и включил сервер. Там было зеркало. Спустя 2 часа захожу в лог рейд массива и вижу:
Вот такое увидел на ESXI 5.5
Буду благодарен любою помощи, спасибо!
ждите. час - это немного ;)
я тут на адаптеке на 8 винтах решил 6-й рейд на 5-й переделать. всего третий год ребилд идет ;)
Зачем разбирать рейд там же данные. Я думал верну шнур обратно и данные сами перельются и все. но не тут то было((
перед запуском сервера я бы на вашем месте потренировался. Посмотрел бы как идет процесс ребилда, подергал бы винты.
Произошло следующее. Контроллер зафиксировал отключение одного из дисков. На рейд ставится отметка degraded, на винт - offline. При этом работа продолжается - данные пишутся, читаются.
Винт вернулся, стал online, но вот консистентность рейда уже нарушена. Вот контроллер и запустил rebuild. При этом идет синхронизация полностью винта - контроллер не будет разбираться, в каких секторах там есть изменения. Просто копируются данные с исправного члена зеркала.
Конспект вебинара HonorCup E=DC2 для сдачи HCNA Storage.
Что/зачем
Основные решаемые задачи:
Контроллер
Бывают программные и аппаратные RAID контроллеры:
Hot Spare диски
В крупный RAID всегда должен быть включен HotSpare (горячий резерв) диск, на который пойдет автоматический ребилд при падении какого-то из дисков. Hot Spare бывают двух видов: глобальный (резерв под любой массив в системе хранения) и выделенный (выделенный диск под конкретный RAID в системе хранения).
К примеру, конфиг системы хранения: 20 дисков, разбитые на 5 рейдов и 1 диск как hot spare на все.
Статусы работы RAID
1) Создание массива
При создании массива диски записываются нулевыми данными.
Все зависит от массива/контроллера, но в общем случае:
- В массиве не обязательно должно быть четное количество дисков (попарно)
- В массиве не обязательно диски одинакового размера. Чаще всего в таком случае мы просто теряем полезную емкость больших дисков (выравнивание объема по меньшему) и использовать его невозможно под другие задачи. Есть режим JBOD (Just buch of disks), в котором можно использовать всю емкость, но это не RAID.
- В массиве не обязательно диски должны иметь одну скорость, но производительность массива определяется по минимальной скорости.
- Обычно используется один тип дисков.
- Обычно в RAID можно на лету добавить еще диски.
Следующие три статуса работы при отказе одного или несколько из дисков в массиве. Отказ определяется контроллером при попытке записи/чтения с диска.
3) Реконструкция массива (RAID rebuilding/reconstruction)
Так же реконструкция происходит, когда добавляется новый диск в RAID. Зависит от контроллера (в основном можно) можно ли добавлять на лету диск в рейд.
4) Деградация массива
5) Авария массива
Аварией массива считается ситуация, когда отказало одновременно больше дисков, чем позволяет RAID технология.
За что еще отвечают контроллеры
Сохранение данных кэша при отключении питания
Кеш RAID/СХД контроллера обычно хранится в ОЗУ, а не ПЗУ (HDD/SSD). Поэтому при пропадании питания данные кэша могут быть потеряны.
- Традиционным способом защиты данных в кэше контроллера является BBU (Battery Backup Unit) модуль (батарея), обеспечивающий питание ОЗУ контроллера в течение некоторого времени после сбоя при помощи литий-ионного аккумулятора. При запуске сервера после восстановления питания контроллер сбрасывает сохранившееся содержимое кэша на дисковый массив. У BBU есть ряд существенных недостатков, связанных с наличием аккумулятора: ограниченное время защиты после сбоя (обычно не более 72 часов), ограниченный срок службы аккумуляторов (1-2 года), необходимость планирования закупок новых BBU модулей и утилизации вышедших из строя.
- В современных контроллерах используется другой способ защиты RAID кэша — при помощи модуля с флэш-памятью и питанием через суперконденсаторы (ионисторы). При возникновении сбоя батарея ионисторов питает модуль защиты кэша только на время копирования содержимого ОЗУ на флэш-память модуля.
Есть и другие варианты сохранения данных:
Анализ состояния дисков (SMART analysis, Bad sector detection/repair)
pre-copy на hot-spare
В случае обнаружения плохого SMART/сбойный блок на диске, контроллер RAID/СХД копирует данные с потенциально сбойного диска на hot-spare. После замены потенциально сбойного диска данные с hot-spare копируются на новый диск.
Такой подход считается лучше Data reconstruction в случае выхода из строя диска полностью т.к. он более быстрый, меньше влияет на производительность RAID/СХД и более надежен.
ОБЪЕКТЫ ДАННЫХ RAID (Strip, Stripe, LUN)
Контроллер RAID оперирует объектами данных:
В общем случае RAID-контроллер не знает что такое файловая система (не говоря про бюджетные варианты), а создает LUN.
Восстановление данных
Восстановление данных в RAID основывается на replication (mirroring) в случае RAID 1 (и его производных) или на базе булевой функции сложения по модулю (XOR) в случае RAID 3, 5, 6.
Таблица истинности XOR:
ЗАПИСЬ НА RAID
Уровни RAID
Сравнение уровней, есть так же в куче мест: wiki, огромная дока (не только сравнение), небольшая статья на nix. При выборе защиты нужно всегда помнить, что методы защищающие от отказа одного ЖД (RAID 3/5) хороши, но всегда надо учитывать, что вероятность отказа двух дисков (второго диска в момент rebuilding после отказа первого) выше вероятности отказа одного т.к. после отказа одного нагрузка на RAID увеличивается и увеличивается вероятность отказа.
Чаще всего используемые массивы:
У вендоров существует две основных технологии реализации RAID 6:
Комбинации
Читайте также: