Настройка программного RAID в Windows

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

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

Давайте рассмотрим аппаратный RAID детально.

Внешний вид

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

• BBU (Battery Backup Unit) — модуль расширения с литий-ионной батареей, позволяющий поддерживать напряжение на энергозависимой микросхеме кэша. В случае внезапного обесточивания сервера его использование позволяет временно сохранить содержимое кэша, которое еще не было записано на диски. Как только электропитание сервера будет восстановлено — содержимое кэша будет записано на диски в штатном режиме. По заявлениям производителя полностью заряженная батарея способна хранить данные кэша в течение 72 часов.
• ZMCP (Zero-Maintenance Cache Protection) — специальный модуль расширения для RAID-контроллера, имеющий собственную энергонезависимую память и суперконденсатор. В случае возникновения сбоя сервера по электропитанию, суперконденсатор обеспечивает микросхемы электроэнергией, которой достаточно для записи содержимого энергозависимой памяти кэша в NAND-память ZMCP. После того, как электропитание сервера восстановлено, содержимое кэша автоматически будет записано на диски. Именно такие модули устанавливаются в наши серверы с аппаратным RAID-контроллером и Cache Protection.

Это особенно важно, когда включен режим отложенной записи кэша (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 ТБ.

В качестве операционной системы будет установлена CentOS 7. Роль серверного приложения возьмет на себя 1C Bitrix24. Вначале мы соберем программный RAID-массив с помощью mdadm и измерим производительность с помощью встроенного в Bitrix24 теста. Каких-либо изменений или дополнительных настроек в систему специально не вносим — устанавливается демо-конфигурация с настройками по-умолчанию. Затем в этот же стенд поставим RAID-контроллер Adaptec ASR 7805 с модулем защиты кэша AFM-700, подключим к нему эти же жесткие диски и выполним точно такое же тестирование.

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

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

/dev/sda /dev/sdb /dev/sdc /dev/sdd

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

mdadm --examine /dev/sda /dev/sdb /dev/sdc /dev/sdd

На всех 4-х дисках должно быть сообщение:

mdadm: No md superblock detected

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

mdadm --zero-superblock /dev/sdX

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

fdisk /dev/sdX

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

mdadm --create --verbose /dev/md0 --level=10 --raid-devices=4 /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1

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

cat /proc/mdstat

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

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

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

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

Первый способ идеально подходит для первоначальной настройки. Вход в утилиту в режиме Legacy (режим для наших серверов по умолчанию) осуществляется с помощью сочетания клавиш CTRL + A при появлении уведомления в процессе инициализации POST. Утилита позволяет не только управлять настройками контроллера, но и логическими устройствами. Инициализируем физические диски (вся информация на дисках при инициализации будет уничтожена) и создадим массив 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.

Пользователям других дистрибутивов Linux также доступны исходные коды драйверов. Помимо драйверов и консольной утилиты ARCCONF производитель также предлагает программу с графическим интерфейсом для удобного управления контроллером — maxView Storage Manager. С помощью указанных утилит можно, не прерывая работу сервера, легко управлять логическими и физическими дисками. Также можно задействовать такой полезный функционал, как «подсветка диска». Мы уже упоминали про пятый кабель для подключения SGPIO — этот кабель подключается напрямую в бэкплейн (от англ. backplane — соединительная плата для накопителей сервера) и позволяет RAID-контроллеру полностью управлять световой индикацей каждого диска. Следует помнить, что бэкплэйны поддерживают не только SGPIO, но и I2C. Переключение между этими режимами осуществляется чаще всего с помощью джамперов на самом бэкплэйне. Каждому устройству, подключенному к аппаратному RAID-контроллеру Adaptec, присваивается идентификатор, состоящий из номера канала и номера физического диска. Номера каналов соответствуют номерам портов на контроллере. Замена диска — штатная операция, впрочем, требующая однозначной идентификации. Если допустить ошибку при этой операции, можно потерять данные и прервать работу сервера. С аппаратным RAID-контроллером такая ошибка является редкостью. Делается это очень просто:

1. Запрашивается список подключенных дисков к контроллеру:

   arcconf getconfig 1

2. Находится диск, требующий замены, и записываются его «координаты» (параметр Reported Channel,Device(T:L)).
3. Диск «подсвечивается» командой:

   arcconf identify 1 device 0 0

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

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

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

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

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

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

Прошивка

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

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

Заключение

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

Программный 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 и получим список разделов:

diskpartsel disk 0list par

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

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

sel disk 1clear

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

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

 convert gpt

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

sel par 1delete part override

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

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

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

sel disk 1create partition primary size=499format quick fs=ntfs

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

set id=de94bba4-06d1-4d40-a16a-bfd50179d6acgpt attributes=0x8000000000000001

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

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

create partition efi size=99format quick fs=fat32

И раздел MSR:

create partition msr size=16

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

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

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

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

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

sel disk 0convert dynamicsel disk 1convert dynamic

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

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

sel vol cadd disk 1

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

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

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

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

sel disk 0list par

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

sel par 2assign letter=P

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

sel disk 1sel par 2assign letter=S

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

P:cd EFIMicrosoftBoot

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

bcdedit /enum

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

bcdedit /copy {bootmgr} /d "Windows Boot Manager 2"

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

bcdedit /set {bb040826-aa5e-lle9-8e9e-8efd93e43841} device partition=s:

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

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

bcdedit /export P:EFIMicrosoftBootBCD2

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

robocopy P: S: /E /R:0

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

rename S:EFIMicrosoftBootBCD2 BCD

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

del P:EFIMicrosoftBootBCD2

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

sel vol premovesel vol sremove

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

22:27 17.08.2019Настраиваем программный RAID на UEFI-системах в Debian и Ubuntu

Программный RAID в Linux на основе MD-устройств успел отлично зарекомендовать себя в работе и пользуется заслуженной популярностью у администраторов, сочетая надежность и простоту создания и управления. Но со все более широким распространением UEFI-систем приходится сталкиваться с некоторыми особенностями. Многие, если есть такая возможность, переключают настройки в режим совместимости, но это неправильно, UEFI — это стандарт для современных устройств и поэтому надо учиться работе с ним.

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

Скажем больше, мы не видим никаких преимуществ у встроенных и недорогих контроллеров перед программной реализацией, особенно на простых массивах, не требующих сложных вычислений (RAID 1 и 10). А учитывая всю гибкость mdadm, программный RAID по многим параметрам будет выглядеть гораздо привлекательнее.

Конфигурация разделов Linux с UEFI

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

EFI — он же ESP (EFI system partition) — специальный раздел с файловой системой FAT32 который содержит загрузчик, вызываемый микропрограммой UEFI, должен находиться в основной таблице разделов и не может располагаться в программных RAID-массивах, томах LVM или пулах ZFS. Данный раздел должен располагаться на каждом диске, с которого предусматривается загрузка.

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

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

Некоторые особенности Ubuntu Server 18.04

Начиная с версии 18.04 Ubuntu Server по умолчанию предлагается с новым инсталлятором Subiquity, который очень просто отличить по обновленному внешнему виду:

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

Также легко можно отличить дистрибутивы по наименованию, образ с Subiquity содержит в наименовании слово live (ubuntu-18.04.3-live-server-amd64.iso).

Создание программного RAID при установке системы

Все дальнейшие действия мы будем производить на системе Debian 10, однако все сказанное будет справедливо для любой основанной на Debian системе, а с некоторыми поправками и для любого дистрибутива Linux.

Прежде всего создадим в начале каждого диска системный раздел EFI размером в 499 МБ (по умолчанию Debian и Ubuntu используют близкие к этому размеры разделов).

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

В итоге каждый диск содержит три раздела: ESP, будущие разделы Linux RAID и разделы подкачки. Порядок следования разделов и размер разделов для RAID должны быть одинаковы на обоих дисках. После того, как первоначальная разметка выполнена соберем программный RAID 1 из разделов для данных, в нашем случае sda2 и sdb2:

Теперь разметим созданный массив, создав там корневой раздел. Помните, что один программный массив Linux (md-устройство) может содержать только один раздел, если вам нужно несколько разделов, то потребуется создать несколько массивов.

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

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

Перед тем как настраивать загрузчик нам потребуется получить некоторые данные, в частности идентификаторы (UUID) разделов, их можно получить командой:

lsblk -o +uuid

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

Они разные, в то время как UUID RAID-разделов совпадают. Чтобы понять, что это означает и какие может иметь последствия откроем /etc/fstab:

Как видим, разделы монтируются по идентификаторам и в случае выхода из строя первого диска вы не сможете загрузиться со второго, так как система не сможет смонтировать EFI-раздел. В некоторых источниках советуют изменить строку монтирования, используя вместо UUID явное указание устройства, например, /dev/sda1. Да, если мы отключим первый диск, то второй превратится в sda и система загрузится, но если диск выйдет из строя, физически определяясь в системе или на его месте будет новый диск без разметки, то такой фокус не сработает.

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

Для работы с разделами FAT32 нам потребуется установить дополнительные утилиты:

apt install dosfstools

После чего выполним:

mkdosfs -i 2396BE56 /dev/sdb1

Где 2396BE56 — идентификатор первого EFI-раздела (/dev/sda1), его следует указывать в одну строку без пробелов и тире, а /dev/sdb1 — второй EFI раздел.

Теперь получим список текущих загрузочных записей EFI:

efibootmgr -v

Здесь нас интересует запись под номером 5 — debian, которая отвечает за загрузку системы и указывает на первый жесткий диск. Запомните или запишите путь к EFI-образу для загрузки системы: EFIdebianshimx64.efi.

Создадим аналогичную запись для второго диска:

efibootmgr -c -d /dev/sdb -p 1 -L "debian 2" -l "EFIdebianshimx64.efi"

Немного поясним назначение ключей команды:

• -c (—create) создать новую запись
• -d (—disk) диск, на котором находится системный раздел EFI
• -p (—part) номер раздела EFI
• -L (—label) метка(наименование) для загрузочной записи
• -l (—loader) путь образа EFI для загрузки

Так как наш EFI-раздел располагается в /dev/sdb1, то в опциях -d и -p указываем /dev/sdb и 1 соответственно, а в качестве пути указываем данные из первой загрузочной записи, которые мы получили на предыдущем шаге. Обратите внимание, что при указании пути к образу EFI используется обратный слеш.

Еще раз убедимся, что запись выполнена правильно:

efibootmgr -v

Обе строки должны отличаться только меткой и GUID раздела (уникальный GPT-идентификатор, который позволяет микропрограмме UEFI найти нужный раздел).

Если обнаружена ошибка, то запись следует удалить и создать заново, для удаления используйте команду:

efibootmgr -b 6 -B

Ключ -b (—bootnum) указывает на номер записи, а -B (—delete-bootnum) предписывает удалить ее.

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

mount /dev/sdb1 /mnt

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

cp -R /boot/efi/EFI/ /mnt

После чего отмонтируем раздел:

umount /dev/sdb1

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

read more at Записки IT специалиста

rss2ljИспользуемые источники:

• https://habr.com/post/449312/
• https://interface31.ru/tech_it/2019/07/nastraivaem-programmnyy-raid-na-uefi-sistemah-v-windows.html
• https://interface31.livejournal.com/74443.html