Настройка программного raid на работающей системе

Обновлено: 03.07.2024

В этой статье описывается настройка RAID1-массива на уже установленном и запущенном Debian Etch с конфигурацией загрузчика GRUB для корректной загрузки системы даже в том случае, если один из винчестеров поврежден.

Я не даю никаких гарантий того, что это будет работать на вашей системе.

Предварительные замечания

Все действия описаны для Debian Etch, с двумя жесткими дисками одинакового размера: /dev/sda и /dev/sdb. /dev/sdb пока не используется, /dev/sda размечен следующим образом:

/dev/sda1 - /boot, файловая система ext3
/dev/sda2 - swap
/dev/sda3 - /, файловая система ext3

В итоге мы хотим получить следующую конфигурацию:

/dev/md0 (составлен из /dev/sda1 и /dev/sdb1) - /boot, ext3
/dev/md1 (составлен из /dev/sda2 и /dev/sdb2) - swap
/dev/md2 (составлен из /dev/sda3 и /dev/sdb3) - /, ext3

Текущая ситуация выглядит следующим образом:

Установка mdadm

mdadm - это утилита для построения программных RAID-массивов. Установите ее командой

Вам будет задан следующий вопрос:

(далее в тексте ответы на вопросы утилит будут выделяться красным цветом)

Затем подгрузите необходимые модули ядра (чтобы избежать перезагрузки):

И выполните команду

Вывод должен быть примерно следующим:

Подготовка /dev/sdb

Для создания RAID1 нам необходимо подготовить второй жесткий диск (/dev/sdb), скопировать на него все данные с /dev/sda и добавить его в массив.

Сначала скопируем таблицу разделов

Проверим, что оба диска имеют одинаковую таблицу:

Теперь изменим тип разделов на втором жестком диске на Linux raid autodetect

Чтобы быть уверенным, что на /dev/sdb не осталось никаких следов от возможных предыдущих установок RAID-массивов, выполните следующие команды:

Если никаких остатков предыдущих установок RAID не обнаружится, то каждая из приведенных выше команд mdadm выдаст ошибку (не надо беспокоиться) примерно следующего вида:

В противном случае никакого вывода не будет.

Создание RAID-массива

Пришло время для создания самих массивов: /dev/md0, /dev/md1, и /dev/md2. /dev/sdb1 будет добавлен в /dev/md0, /dev/sdb2 в /dev/md1 и /dev/sdb3 в /dev/md2. Разделы на первом диске мы пока не трогаем, так как с него загружена система. Мы будем использовать указатель missing при создании массива:

Проверка состояния нашего массива должна показать, что у нас есть три поврежденных RAID-массива ([_U] или [U_] означает, что массив поврежден, а [UU] означает, что все в порядке):

Теперь создадим файловые системы на массивах

и отредактируем конфигурационный файл /etc/mdadm/mdadm.conf

Он должен выглядеть примерно так (в последних строках расположена информация о наших массивах):

Подготовка и перенос данных

Смонтируем массивы (swap монтировать, естественно, не надо):

и отредактируем файлы /etc/fstab и /etc/mtab. Заменим /dev/sda1 на /dev/md0, /dev/sda2 на /dev/md1 и /dev/sda3 на /dev/md2, чтобы эти файлы приняли следующий вид:

Пришло время для настройки GRUB. Откройте файл /boot/grub/menu.lst и добавьте опцию fallback сразу после default

Это значит, что если первое ядро (нумерация начинается с нуля) не сможет загрузиться, то будет загружено следующее в списке. В конце этого файла расположены блоки, описывающие параметры ядер для загрузки. Скопируйте первый блок, замените в копии root=/dev/sda3 на root=/dev/md2 и root (hd0,0) на root (hd1,0), после чего поставьте полученный блок первым в списке. После редактирования файл должен выглядеть примерно так:

root (hd1,0) ссылается на диск /dev/sdb, который уже входит в RAID-массив. Вскоре мы будем перезагружать систему, при этом система попытается загрузиться с нашего (все еще поврежденного) массива /dev/md2. В случае неудачи загрузка продолжится со следующего по списку раздела /dev/sda (-> fallback 1).

Теперь обновим RAM-диск

И скопируем данные на /dev/sdb

Настройка GRUB

Теперь необходимо установить загрузчик на второй винчестер. Все последующие команды (выделены красным) выполняются в оболочке GRUB (она запускается командой grub):

После этих действий возвращаемся в оболочку, выполняем перезагрузку

Подготовка /dev/sda

Если все прошло нормально, то вы должны увидеть /dev/md0 и /dev/md2 в выводе команды df -h

Вывод cat /proc/mdstat должен быть примерно таким:

Теперь изменим тип разделов на /dev/sda на Linux raid autodetect

Добавим /dev/sda1, /dev/sda2 и /dev/sda3 в RAID-массив

И проверим состояние массива. Вы должны увидеть, что идет процесс синхронизации server1:

Дождитесь окончания процесса синхронизации, после чего состояние массива должно выглядеть примерно так:

Затем отредактируем /etc/mdadm/mdadm.conf, чтобы он соотвествовал новой ситуации.

Теперь он выглядит так:

Настройка GRUB (Часть 2)

Почти все готово. Теперь отредактируем /boot/grub/menu.lst. На данный момент GRUB настроен на загрузку с /dev/sdb (hd1,0). Конечно же, мы все еще хотим, чтобы система грузилась, если /dev/sdb содержит какие-то ошибки. Создадаим копию первого блока с описанием параметров загрузки (в котором описан hd1), вставим ее ниже и заменим в этом блоке hd1 на hd0. Остальные блоки закомментируем. Теперь конфиг загрузчика должен выглядеть примерно так:

Обновляем RAM-диск и перезагружаемся:

Загрузка должна пройти без проблем:

Все работает, мы только что настроили программный RAID-массив первого уровня на работающей системе Debian Etch!

Тестирование

Давайте попробуем сэмулировать сбой жесткого диска. Абсолютно неважно, как ой из дисков вы выберите для эксперимента. Я выбрал /dev/sdb Для эмуляции сбоя необходимо либо остановить систему и физически удалить второй винчестер (/dev/sdb) из компьютера, либо сэмулировать это на программном уровне:

Выключите компьютер. Если вы физически удаляли винчестер, то поместите на его место новый. Загрузка должна пройти без проблем. Посмотрим статус нашего массива:

Видно, что массив опять поврежден. Состояние разделов должно быть примерно следующим:

Теперь скопируем таблицу разделов с /dev/sda на /dev/sdb (В случае ошибок попробуйте опцию --force)

Удаляем с /dev/sdb предыдущие установки RAID

. и добавляем /dev/sdb в массив:

Если посмотреть на статус массива, то мы увидим знакомый процесс синхронизации server1:

И все! Сбойный жесткий диск в RAID-массиве успешно заменен без потери данных.

Удаление программного (software) массива RAID.

с помощью mdadm был создан массив RAID5 /dev/md0 из 3-х разделов 3-х SATA-дисков;

1. Останавливаем все процессы, которые могут работать с файлами в /var/spool/avreg.

Настраиваем программный RAID на UEFI-системах в Windows

Программный RAID пользуется заслуженной популярностью, позволяя легко создавать отказоустойчивые дисковые конфигурации в недорогих системах, отличаясь простотой создания и управления. Но с переходом современных систем на UEFI появились некоторые особенности, касающиеся процесса загрузки, которые следует понимать и принимать во внимание. В противном случае отказоустойчивость может оказаться мнимой и при отказе одного из дисков вы просто не сможете загрузить систему.

Данная инструкция может кому-то показаться сложной, действительно, для создания программного RAID на UEFI-системах требуется довольно много подготовительных действий. Также определенное количество операций придется выполнить и при замене отказавшего диска, но это тема для отдельной статьи. В связи с этим встает вопрос выбора между программным RAID и встроенным в материнскую плату, т.н. fake-raid.

Если брать вопрос производительности, то сегодня он абсолютно неактуален, тем более что вся обработка данных так или иначе осуществляется силами CPU. Основным аргументов в пользу встроенного RAID служит простота его использования, но за это приходится платить совместимостью. Собранные таким образом массивы будут совместимы только со своим семейством контроллеров. К счастью, сейчас уже нет того зоопарка, который был еще лет 10 назад, но все равно, собранный на базе платформы Intel массив вы не запустите на AMD-системе.

Также вы можете столкнуться с тем, что несмотря на то, что массив собрался, система не может загрузиться, так как не имеет в своем составе драйверов для новой версии контроллера, это может быть актуально для старых ОС на новых аппаратных платформах. Кроме того, все операции по замене дисков, расширению и ресинхронизации массива вам придется делать в оффлайн режиме, загрузить систему с массива в состоянии обслуживания вы не сможете.

Программные массивы лишены этих недостатков, все что им требуется - это поддержка со стороны ОС. Операции обслуживания также можно выполнять без прерывания работы системы, естественно принимая во внимание тот факт, что производительность дисковой системы в это время будет снижена. Но есть и обратная сторона медали, динамические диски Windows имеют ряд неприятных особенностей, например, ограниченные возможности по управлению дисковым пространством и обслуживанию. Штатные инструменты имеют только базовые функции, а из коммерческого софта работу с данным типом дисков обычно поддерживают только дорогие корпоративные версии.

Также есть другая особенность, вытекающая из архитектуры программных RAID массивов, если некритически отказал тот жесткий диск, с которого осуществляется загрузка, то система не будет автоматически загружена со второго, исправного HDD, вы получите ошибку (или BSOD) и вам потребуется вручную изменить порядок загрузки для восстановления работы системы.

Но несмотря на определенные недостатки и ограничения, программный RAID на основе динамических дисков пока остается единственной возможностью обеспечить отказоустойчивость системы, не прибегая к аппаратным средствам.

Конфигурация разделов Windows-систем с UEFI

Прежде всего рассмотрим стандартную конфигурацию разделов, автоматически создаваемую Windows с UEFI, приведенный ниже пример соответствует последним версиям Windows 10 и Windows Server 2016/2019, у более ранних версий Windows разметка может несущественно отличаться.

Windows RE - NTFS раздел со средой восстановления, в последних версиях Windows имеет размер в 500 МБ, при создании ему присваиваются специальные атрибуты, препятствующие назначению буквы диска и удалению раздела через консоль управления дисками. В тоже время данный раздел не является необходимым для работы системы, среда восстановления может находиться на системном диске и даже может отсутствовать. Вынос среды восстановления на отдельный раздел преследует две цели: возможность работы на зашифрованных системах и защита от некорректных действий пользователя.

EFI - раздел специального типа с файловой системой FAT32, который содержит загрузчик, вызываемый микропрограммой UEFI. Данный раздел должен находиться в основной таблице разделов и не может быть расположен на динамическом диске. В Windows он ошибочно называется зашифрованным, имеет критическое значение для нормальной работы системы. В современных Windows-системах имеет размер в 100 МБ.

MSR (Microsoft System Reserved) - служебный раздел с файловой системой NTFS, является обязательным для GPT-разметки, которая не позволяет использовать скрытые сектора диска, используется для служебных операций встроенного и стороннего ПО, например, при преобразовании диска в динамический. Является скрытым и не отображается в оснастке управление дисками. Его размер в современных системах - 16 МБ.

Windows - самый обычный раздел с системой, фактически под ним следует понимать любую пользовательскую разметку. Никаких особенностей он в себе не таит.

Производители ПК могут добавлять дополнительные разделы, например, с резервным образом системы для отката к заводским настройкам или собственными инструментами восстановления, чаще всего они имеют специальные GPT-атрибуты, как и у раздела Windows RE.

Подготовка к созданию программного RAID

Будем считать, что вы уже установили операционную систему на один из дисков, в нашем примере будет использоваться Windows Server 2019 установленный на виртуальной машине. Если мы откроем оснастку Управление дисками, то увидим примерно следующую картину:

Первым идет раздел Windows RE, размером в 499 МБ, а за ним раздел EFI, который ошибочно именуется шифрованным. Но как мы говорили выше, данная оснастка не дает полного представления о структуре разметки, поэтому запустим утилиту командной строки diskpart и получим список разделов:

Первая команда запускает утилиту, вторая выбирает первый диск (диск 0) и третья выводит список разделов.

Здесь присутствуют все существующие на диске разделы, включая MSR, размером в 16 МБ. Теперь нам нужно воспроизвести аналогичную разметку на втором жестком диске. Будем считать, что вы еще не вышли из утилиты diskpart, поэтому выберем второй жесткий диск (диск 1) и очистим его:

Внимание! Данная команда полностью удалит все данные с указанного диска. Убедитесь, что вы выбрали нужный диск и что он не содержит никаких данных!

Преобразуем диск в GPT:

При преобразовании на диске будет автоматически создан MSR раздел, нам он пока не нужен, поэтому удалим его командой:

После чего убедимся, что диск не содержит разделов.

Теперь можно создавать разметку. Разделы должны идти в том же порядке и с тем же типом, что и на первом диске. Поэтому первым создадим раздел восстановления, он не является обязательным и не влияет на работу системы. В принципе его можно даже не форматировать, но во избежание каких-либо недоразумений в дальнейшем мы рекомендуем создать раздел с теми же атрибутами, что и оригинальный раздел восстановления.

На всякий случай явно выберем диск и создадим на нем раздел размером в 499 МБ, который отформатируем в NTFS:

Затем зададим ему нужные GPT-атрибуты:

Идентификатор de94bba4-06d1-4d40-a16a-bfd50179d6ac задает тип раздела как Windows RE, а атрибут 0x8000000000000001 препятствует назначению буквы диска и помечает раздел как обязательный для работы системы, во избежание его удаления из оснастки управления дисками.

Следующим шагом создадим раздел EFI:

Если все сделано правильно, то вы должны получить следующую схему разметки, которая будет полностью повторять (за исключением системного раздела) разметку первого диска.

После чего систему обязательно следует перезагрузить.

Создание программного RAID

Прежде всего преобразуем диски в динамические, это можно сделать в оснастке Управление дисками:

или утилитой diskpart:

Затем добавим зеркало к системному диску через графический интерфейс

или с помощью diskpart:

После чего следует обязательно дождаться ресинхронизации данных, в зависимости от скорости и объема дисков это может занять некоторое время.

Настройка загрузчика EFI и его копирование на второй раздел

Снова запустим утилиту diskpart и присвоим буквы EFI разделам на дисках, но перед этим уточним расположение нужного нам раздела:

Как видим интересующий нас раздел имеет номер 2, выберем его и присвоим букву:

Повторим аналогичные манипуляции со вторым диском:

Выйдем из утилиты diskpart (команда exit) и перейдем в EFI раздел первого диска:

Для просмотра текущих точек загрузки выполните:

Вывод команды покажет нам единственную запись диспетчера загрузки (на текущем EFI-разделе) и две записи загрузчика Windows, на каждом из зеркальных томов. Нам потребуется создать второй экземпляр диспетчера загрузки:

Из вывода данной команды нам потребуется идентификатор, скопируем его для использования в следующей команде.

В фигурных скобках должен быть указан идентификатор, полученный на предыдущем шаге.

После чего экспортируем BCD-хранилище загрузчика:

И скопируем содержимое EFI-раздела на второй диск:

Ошибка при копировании активного экземпляра BCD-хранилища - это нормально, собственно поэтому мы и сделали его экспорт, вместо того, чтобы просто скопировать. Затем переименуем копию хранилища на втором диске:

и удалим ее с первого:

Осталось удалить буквы дисков EFI-разделов, для этого снова запустим diskpart:

Теперь можно перезагрузить систему и в загрузочном меню BIOS выбрать Windows Boot Manager 2, затем Windows Server - вторичный плекс - это обеспечит использование EFI-загрузчика и системного раздела второго диска. Если вы все сделали правильно - загрузка будет удачной. Таким образом у нас будет полноценное зеркало системного раздела на динамических дисках в UEFI-системе.

Все, описанные ниже действия, вы делаете на свой страх и риск. Мы не несем ответственности за потерю или повреждение данных.

Установка утилиты mdadm

Для настройки и управления программным RAID-ом в Linux используется утилита mdadm. Установим ее:

MD arrays needed for the root file system: all

Загрузим необходимые модули ядра:

Для того чтобы удостовериться, что все необходимые модули и компоненты установлены, выполним следующую команду:

Если Вы видите что-то подобное, значит все хорошо.

Оба диска в массиве должны иметь абсолютно одинаковое разбиение. В зависимости от используемого типа таблицы разделов (MBR или GPT) необходимо использовать соответствующие утилиты для копирования таблицы разделов.

Жесткий диск с таблицей разделов MBR

Для жесткого диска с MBR используем утилиту sfdisk:

Удостоверимся, что все верно:

На следующем шаге изменим тип трех разделов жесткого диска /dev/sdb на Linux raid autodetect:

Жесткий диск с таблицей разделов GPT

Для жесткого диска с GPT используем утилиту sgdisk из GPT fdisk:

Проверим, что разделы созданы:

Изменим тип трех разделов жесткого диска /dev/sdb на raid:

Очищаем суперблоки RAID на разделах /dev/sdb, в случае если этот диск уже использовался в RAID-массивах:

Создадим три RAID-массива: /dev/md0, /dev/md1, /dev/md2. Раздел /dev/sdb1 будет входить в /dev/md0, /dev/sdb2 в /dev/md1, /dev/sdb3 в /dev/md2. Разделы жесткого диска /dev/sda, на данном этапе, в RAID-массивы включены быть не могут, так как они используются системой. Используем опцию missing при создании массивов:

На вопрос о создании массивов отвечаем утвердительно:

Используя команду cat /proc/mdstat, просмотрим информацию о массивах:

Создадим файловые системы на только что созданных составных дисках /dev/md0 (/boot), /dev/md1 (swap), /dev/md2 (/):

Запишем информацию о созданных массивах в конфигурационный файл mdadm.conf, предварительно сделав резервную копию:

Конфигурационный файл примет следующий вид:

Подготовка системы для работы с RAID-массивами

Подмонтируем /dev/md0 и /dev/md2 в нашу систему (монтировать раздел подкачки- /dev/md1, нет никакого смысла):

Подправим файл /etc/mtab подобным образом:

Пришла очередь настройки загрузчика GRUB2:

Так как мы изменили файл /etc/fstab на использование обычных названий устройств вместо их UUID, сообщим об этом загрузчику:

Пришло время перенести систему с диска /dev/sda на составные устройства /dev/mdx. То есть содержимое раздела /dev/sda1 на /dev/md0, а /dev/sda3 на /dev/md2. Напомню, что массивы /dev/md0 и /dev/md2 у нас подмонтированы в /mnt/md0 и /mnt/md2 соответственно. Раздел подкачки переносить не будем.

Настройка загрузчика GRUB2 (часть 1)

Установим загрузчик на оба жестких диска:

Проверяем, что загрузка с /dev/md0 возможна:

Подготовка диска /dev/sda

После загрузки системы проверяем все ли загрузилось и работает:

Жесткий диск /dev/sda с MBR

Изменим тип разделов диска /dev/sda на Linux raid autodetect:

Жесткий диск /dev/sda с GPT

Изменим флаг разделов на raid:

Добавляем разделы /dev/sda в RAID-массивы:

Проверяем, что массивы синхронизируются:

По окончанию процесса синхронизации увидим следующее:

Осталось совсем немного. Подправим файл /etc/mdadm/mdadm.conf, восстановив его предварительно из резервной копии:

Его содержимое станет приблизительно таким:

Настройка загрузчика GRUB2 (часть 2)

Удалим файл /etc/grub.d/09_swraid1_setup:

И обновим конфигурацию загрузчика:

Обновим загрузчик на обоих жестких дисках:

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

Организация единого дискового пространства — задача, легко решаемая с помощью аппаратного RAID-контроллера. Однако следует вначале ознакомиться с особенностями использования и управления таким контроллером. Об этом сегодня расскажем в нашей статье.

Надежность и скорость работы дисковых накопителей — вопрос, волнующий каждого системного администратора. Несмотря на заверения производителей о качестве собственных устройств — HDD и SSD продолжают выходить из строя в самое неподходящее время, теряя драгоценные данные. Технология S.M.A.R.T. в большинстве случаев дает возможность оценить «здоровье» накопителя, но это не гарантирует того, что диск будет продолжать беспроблемно работать.

Предсказать выход диска из строя со 100%-ой точностью невозможно, поэтому следует предусмотреть вариант, при котором это не станет проблемой или причиной остановки сервисов. Использование RAID-массивов решает эту задачу. Рассмотрим три основных подхода, применяющихся для этой задачи:

Программный RAID — наименее затратный вариант, но и наименее производительный. Массив создается средствами операционной системы, вся нагрузка по обработке данных «ложится на плечи» центрального процессора.
Интегрированный аппаратный RAID (еще его часто называют Fake-RAID) — микрочип, установленный на материнскую плату, который берет на себя часть функционала аппаратного RAID-контроллера, работая в паре с центральным процессором. Этот подход работает чуть быстрее, чем программный RAID, но надежность у такого массива оставляет желать лучшего.
Аппаратный RAID — это отдельный контроллер с собственным процессором и кэширующей памятью, полностью забирающий на себя выполнение всех дисковых операций. Наиболее затратный, однако, самый производительный и надежный вариант для использования.

Внешний вид

Мы выбрали решения Adaptec от компании Microsemi. Это RAID-контроллеры, зарекомендовавшие себя удобством использования и высокой производительностью. Их мы устанавливаем, если наш клиент решил заказать сервер произвольной или фиксированной конфигурации.

Для подключения дисков используются специальные интерфейсные кабели. Со стороны контроллера используются разъемы SFF8643. Каждый кабель позволяет подключить до 4-х дисков SAS или SATA (в зависимости от модели). Помимо этого интерфейсный кабель еще имеет восьмипиновый разъем SFF-8485 для шины SGPIO, о назначении которой поговорим чуть позже.

Помимо самого RAID-контроллера существует еще два дополнительных устройства, позволяющих увеличить надежность:

Это особенно важно, когда включен режим отложенной записи кэша (Writeback). При пропадании электропитания содержимое кэша не будет сброшено на диски, что приведет к потере данных и, как следствие, штатная работа дискового массива будет нарушена.

Технические характеристики

Температура

Вначале хотелось бы затронуть такую важную вещь, как температурный режим аппаратных RAID-контроллеров Adaptec. Все они оснащены небольшими пассивными радиаторами, что может вызвать ложное представление о небольшом тепловыделении.

Производитель контроллера приводит в качестве рекомендуемого значения воздушного потока — 200 LFM (linear feet per minute), что соответствует показателю 8,24 литра в секунду (или 1,02 метра в секунду). Рассчитаны такие контроллеры исключительно на установку в rackmount-корпусы, где такой воздушный поток создается скоростными штатными кулерами.

От 0°C до 40-55°C — рабочая температура большинства RAID-контроллеров Adaptec (в зависимости от наличия установленных модулей), рекомендованная производителем. Максимальная рабочая температура чипа составляет 100°C. Функционирование контроллера при повышенной температуре (более 85°C) может вывести его из строя. Удобства ради приводим под спойлером табличку рекомендуемых температур для разных серий контроллеров Adaptec.

Series 2 (2405, 2045, 2805) and 2405Q	55°C без модулей
Series 5 (5405, 5445, 5085, 5805, 51245, 51645, 52445)	55°C без батарейного модуля, 40°C с батарейным модулем ABM-800
Series 5Z (5405Z, 5445Z, 5805Z, 5805ZQ)	50°C с модулем ZMCP
Series 5Q (5805Q)	55°C без батарейного модуля, 40°C с батарейным модулем ABM-800
Series 6E (6405E, 6805E)	55°C без модулей
Series 6/6T (6405, 6445, 6805, 6405T, 6805T)	55°C без ZMCP модуля, 50°C с ZMCP модулем AFM-600
Series 6Q (6805Q, 6805TQ)	50°C с ZMCP модулем AFM-600
Series 7E (71605E)	55°C без модулей
Series 7 (7805, 71605, 71685, 78165, 72405)	55°C без ZMCP модуля, 50°C с ZMCP модулем AFM-700
Series 7Q (7805Q, 71605Q)	50°C с ZMCP модулем AFM-700
Series 8E (8405E, 8805E)	55°C без модулей
Series 8 (8405, 8805, 8885)	55°C без ZMCP модуля, 50°C с ZMCP модулем AFM-700
Series 8Q (8885Q, 81605Z, 81605ZQ)	50°C с ZMCP модулем AFM-700

Нашим клиентам не приходится беспокоиться о перегреве контроллеров, поскольку в наших дата-центрах поддерживается постоянный температурный режим, а сборка серверов произвольной конфигурации происходит с учетом особенностей таких комплектующих (о чем мы упоминали в нашей предыдущей статье).

Скорость работы

Для того чтобы продемонстрировать, как наличие аппаратного RAID-контроллера способствует увеличению скорости работы сервера, мы решили собрать тестовый стенд со следующей конфигурацией:

CPU Intel Xeon E3-1230v5;
RAM 16 Gb DDR4 2133 ECC;
4 HDD емкостью по 1 ТБ.

Затем в этот же стенд поставим RAID-контроллер Adaptec ASR 7805 с модулем защиты кэша AFM-700, подключим к нему эти же жесткие диски и выполним точно такое же тестирование.

С программным RAID

Несомненное преимущество программного RAID — простота использования. Массив в ОС Linux создается с помощью штатной утилиты mdadm. При установке операционной системы чаще всего создание массива предусмотрено непосредственно из установщика. В случае, когда такой возможности установщик не предоставляет, достаточно всего лишь перейти в соседнюю консоль с помощью сочетания клавиш Ctrl+Alt+F2 (где номер функциональной клавиши — это номер вызываемой tty).

Создать массив очень просто. Командой fdisk -l смотрим, какие диски присутствуют в системе. В нашем случае это 4 диска:

Проверяем, чтобы на дисках не было метаданных, например, от предыдущего массива:

В случае, если на одном или нескольких дисках будут метаданные, удалить их можно следующим образом (где sdX — требуемый диск):

Создадим на каждом диске разделы для будущего массива c помощью fdisk. В качестве типа раздела следует указать fd (Linux RAID autodetect).

Собираем массив RAID 10 из созданных разделов с помощью команды:

Сразу после этого будет создан массив /dev/md0 и будет запущен процесс перестроения данных на дисках. Для отслеживания текущего статуса процесса введите:

Пока процесс перестроения данных не будет завершен, скорость работы дискового массива будет снижена.

После установки операционной системы и Bitrix24 на созданный массив мы запустили стандартный тест и получили следующие результаты:

С аппаратным RAID

Прежде чем сервер сможет использовать единое дисковое пространство RAID-массива, необходимо выполнить базовую настройку контроллера и логических дисков. Сделать это можно двумя способами:

при помощи внутренней утилиты контроллера,
утилитой из операционной системы.

Утилита позволяет не только управлять настройками контроллера, но и логическими устройствами. Инициализируем физические диски (вся информация на дисках при инициализации будет уничтожена) и создадим массив RAID-10 с помощью раздела Create Array. При создании система запросит желаемый размер страйпа, то есть размер блока данных за одну I/O-операцию:

больший размер страйпа идеален для работы с файлами большого размера;
меньший размер страйпа подойдет для обработки большого количества файлов небольшого размера.

Важно — размер страйпа задается только один раз (при создании массива) и это значение в дальнейшем изменить нельзя.

Сразу после того, как контроллеру отдана команда создания массива, также, как и с программным RAID, начинается процесс перестроения данных на дисках. Этот процесс работает в фоновом режиме, при этом логический диск становится сразу доступен для BIOS. Производительность дисковой подсистемы будет также снижена до завершения процесса. В случае, если было создано несколько массивов, то необходимо определить загрузочный массив с помощью сочетания клавиш Ctrl + B.

После того как статус массива изменился на Optimal, мы установили Bitrix24 и провели точно такой же тест. Результат теста:

Сразу становится понятно, что аппаратный RAID-контроллер ускоряет операции чтения и записи на дисковый носитель за счет использования кэша, что позволяет быстрее обрабатывать массовые обращения пользователей.

Управление контроллером

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

Debian,
Ubuntu,
Red Hat Linux,
Fedora,
SuSE Linux,
FreeBSD,
Solaris,
Microsoft Windows,
Citrix XenServer,
VMware ESXi.

С помощью указанных утилит можно, не прерывая работу сервера, легко управлять логическими и физическими дисками. Также можно задействовать такой полезный функционал, как «подсветка диска». Мы уже упоминали про пятый кабель для подключения SGPIO — этот кабель подключается напрямую в бэкплейн (от англ. backplane — соединительная плата для накопителей сервера) и позволяет RAID-контроллеру полностью управлять световой индикацей каждого диска.

Следует помнить, что бэкплэйны поддерживают не только SGPIO, но и I2C. Переключение между этими режимами осуществляется чаще всего с помощью джамперов на самом бэкплэйне.

Каждому устройству, подключенному к аппаратному RAID-контроллеру Adaptec, присваивается идентификатор, состоящий из номера канала и номера физического диска. Номера каналов соответствуют номерам портов на контроллере.

Замена диска — штатная операция, впрочем, требующая однозначной идентификации. Если допустить ошибку при этой операции, можно потерять данные и прервать работу сервера. С аппаратным RAID-контроллером такая ошибка является редкостью.

Делается это очень просто:

Например, на платформах Supermicro штатная работа диска — зеленый или синий цвет, а «подсвеченный» диск будет моргать красным. Перепутать диски в этом случае невозможно, что позволит избежать ошибки из-за человеческого фактора.

Настройка кэширования

Теперь пару слов о вариантах работы кэша на запись. Вариант Write Through означает, что контроллер сообщает операционной системе об успешном выполнении операции записи только после того, как данные будут фактически записаны на диски. Это повышает надежность сохранности данных, но никак не увеличивает производительность.

Чтобы достичь максимальной скорости работы, необходимо использовать вариант Write Back. При такой схеме работы контроллер будет сообщать операционной системе об успешной IO-операции сразу после того, как данные поступят в кэш.

Важно — при использовании Write Back настоятельно рекомендуется использовать BBU или ZMCP-модуль, поскольку без него при внезапном отключении электричества часть данных может быть утеряна.

Настройка мониторинга

Вопрос мониторинга статуса работы оборудования и возможности оповещения стоит достаточно остро для любого системного администратора. Для того чтобы настроить «связку» из Zabbix и RAID-контроллера Adaptec рекомендуем воспользоваться перечисленными решениями.

Зачастую требуется отслеживать состояние контроллера напрямую из гипервизора, например, VMware ESXi. Задача решается с помощью установки CIM-провайдера с помощью инструкции Microsemi.

Прошивка

Необходимость прошивки RAID-контроллера возникает чаще всего для исправления выявленных производителем проблем с работой устройства. Несмотря на то, что прошивки доступны для самостоятельного обновления, к этой операции следует подойти очень ответственно, особенно если процедура выполняется на «боевой» системе.

Если нашему клиенту требуется сменить версию прошивки контроллера, то ему достаточно создать тикет в нашей панели управления. Системные инженеры выполнят перепрошивку RAID-контроллера до требуемой версии в указанное время и сделают это максимально корректно.

Важно — не следует выполнять перепрошивку самостоятельно, поскольку любая ошибка может привести к потере данных!

Заключение

Использование аппаратного RAID-контроллера оправдано в большинстве случаев, когда требуется высокая скорость и надежность работы дисковой подсистемы.

Системные инженеры Selectel бесплатно выполнят базовую настройку дискового массива на аппаратном RAID-контроллере при заказе сервера произвольной конфигурации. В случае, если потребуется дополнительная помощь с настройкой, мы будем рады помочь в рамках нашей услуги администрирования. Также мы подготовили для наших читателей небольшую памятку по командам утилиты arcconf.

Читайте также: