Обновление proxmox 5 до 6

Введение

Использовать систему в работе удобно и за все время использования она меня не подводила. Начинал использование с 4 версии, но вышла 5 версия с очень удобными и функциональными изменениями. Сразу после выхода новой версии любого программного продукта я не спешу обновляться и всегда жду в районе 3 месяцев, так я избавляю себя от ошибок которые всегда есть при выходе любой новой версии. На сайте разработчика есть инструкции как производить обновление на новую версию. Вариант установки как с готового образа iso так и ручная установки на Debian.

Никогда не устанавливайте и не загружайте систему разными сервисными службами, на которой установлен Proxmox, если не хотите иметь проблем при обновлении! Отдавайте под раздел boot минимум 500 мегабайт если не хотите получать ошибку о нехватке места при обновлении ядра!

В моем случае я как раз нарушил оба этих правила и обновить систему не удалось.

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

Проверяем отправку почты[]

Отправим тестовое письмо с темой proverka в содержании которого будет написано testovoe pismo

echo testovoe pismo | mail -s proverka [email protected]

Контроль SMART HDD

Включение поддержки и просмотр состояния критически важных параметров для дисков sda и sdb:

smartctl -a -s on /dev/sda | egrep "Serial Number|Device Model|Pre-fail"
smartctl -a -s on /dev/sdb | egrep "Serial Number|Device Model|Pre-fail"

Просмотр всех атрибутов SMART

smartctl -a /dev/sda

Описание атрибутов

Настройка уведомлений

cp /etc/smartd.conf /etc/smartd.conf.sample
echo "/dev/sda -a -I 194 -W 4,45,55 -R 5 -m [email protected] -o on -S on -s (S/../.././02|L/../../6/03)" > /etc/smartd.conf
echo "/dev/sdb -a -I 194 -W 4,45,55 -R 5 -m [email protected] -o on -S on -s (S/../.././02|L/../../6/03)" >> /etc/smartd.conf
echo "start_smartd=yes" > /etc/default/smartmontools

Запуск службы мониторинга

/etc/init.d/smartmontools restart

Проверка лога монитора

cat /var/log/syslog | grep smartd

Сенсоры

Выполним поиск датчиков материнской платы

sensors-detect

На все вопросы мастера отвечаем Yes и по окончании выполним

/etc/init.d/module-init-tools start

Посмотреть состояние датчиков

sensors

SNMP

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

mv /etc/snmp/snmpd.conf /etc/snmp/snmpd.conf.example
nano /etc/snmp/snmpd.conf

syslocation Filial1                  # Подсказка по расположению сервера
syscontact “Admin <[email protected]>”  # Контакт ответственного лица
rocommunity public                   # Строка подключения

/etc/init.d/snmpd restart

Настраиваем автозапуск

По умолчанию Proxmox не запускает машины автоматически. Однако это решается довольно просто:
1. Щелкаем по названию интересующей машины.
2. Выбираем вкладку «Опции» ➝ «Запуск при загрузке».
3. Отмечаем галочкой одноимённую надпись.

В итоге, при перезагрузке физического сервера, машина запустится автоматически.

Кроме того, продвинутый администратор может указать дополнительные параметры запуска (они находятся в разделе «Start/Shutdown order»). Вы можете явно указать, в каком порядке надо запускать машины. Вдобавок к этому, вы можете указать время, которое должно пройти до старта следующей машины, плюс время задержки выключения (когда ОС не успевает завершить работу, гипервизор выключит её принудительно через определенное число секунд).

Источник — блог компании Selectel.

iSCSI и LVM

Подобным образом внутри контейнера может быть настроен и обычный tgt-демон, iSCSI будет выдавать значительно бОльшую производительность для операций ввода-вывода, а контейнер будет работать более гладко ввиду того tgt-сервер работает полностью в пространстве пользователя.

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

Пожалуй эти и другие ньюансы я опишу в следующей статье.

UPD: Хочется добавить что помимо NFS-Kernel-Server существует ещё — сервер, который полностью работает в user-space.

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

Установка всё также проста:

Но конфигурация немного отличается, экспорт нужно описать в

Затем выполнить:

Подготовка к обновлению

Для начала информация для тех, у кого всё ещё 5-я версия. Обновите её по моей статье — Обновление Proxmox 5 до 6. После того, как сделаете это, возвращайтесь сюда. А мы готовимся обновить Proxmox 6 до 7. Я не буду заниматься самодеятельностью, а выполню то, что указано в официальном руководстве по обновлению — https://pve.proxmox.com/wiki/Upgrade_from_6.x_to_7.0. Если хорошо читаете по-английски, можете сразу переходить туда и делать по нему.

Перед обновлением важно ознакомиться со всеми нюансами:

Версия Proxmox должна быть 6.4.
Перед обновлением Proxmox нужно обязательно обновить Ceph до версии 15.2.
Если используете Proxmox Backup Server, то не обновляйтесь до тех пор, пока не выйдет версия 2.0.
У вас должны быть доступны все хранилища на момент обновления.
На всякий случай должны быть сделаны бэкапы всех виртуальных машин и контейнеров.
Должно быть доступно не менее 4GiB свободного места на корневом разделе.
У вас изменится MAC адрес на сетевых бриджах vmbr. Подготовьтесь к этому заранее.

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

# apt update && apt dist-upgrade
# reboot

Теперь запускаем утилиту pve6to7, чтобы проверить готовность вашего гипервизора к обновлению.

# pve6to7

Я получил одно предупреждение. У одного контейнера отсутствует указанный в конфигурации диск. Это очень старый контейнер, который не нужен. Я просто удалил его. Запустил еще раз утилиту, предупреждений не было. После этого можно двигаться дальше.

Как я уже сказал ранее, после обновления у вас изменится MAC адрес сетевого бриджа vmbr. Если для вас это может сулить проблемы, то заранее укажите постоянный MAC. Для начала посмотрите текущие адреса:

# ip -c link

Затем укажите текущий MAC адрес бриджа в конфигурации сетевых интерфейсов /etc/network/interfaces.

auto vmbr0
iface vmbr0 inet static
    address 10.20.1.2/24
    hwaddress ae:9d:46:49:4d:23
    # ... остальные настройки

Отказоустойчивый NFS-сервер

К сожалению на момент написания статьи Linstor имеет готовую интеграцию только с Kubernetes. Но в конце года ожидаются драйверы и для остальных систем Proxmox, OpenNebula, OpenStack.

Но пока готового решения нет, а старое нам так или иначе не нравится. Попробуем использовать DRBD9 по старинке для организации NFS-доступа на общий раздел.

Тем не менее данное решение так-же окажется не без плюсов, ведь NFS-сервер позволит вам организовать конкурентный доступ к файловой системе хранилища с нескольких серверов без необходимости использования сложных кластерных файловых систем с DLM, таких как OCFS и GFS2.

При этом вы получите возможность переключать роли Primary/Secondary нод просто мигрируя контейнер с NFS-сервером в интерфейсе Proxmox.

Вы так же сможете хранить любые файлы внутри этой файловой системы, так же как виртуальные диски и бэкапы.

В случае если вы используете Kubernetes вы сможете организовать ReadWriteMany доступ для ваших PersistentVolumes.

Форматы виртуальных накопителей

Расскажем подробнее об используемых в Proxmox форматах накопителей:

RAW. Самый понятный и простой формат. Это файл с данными жесткого диска «байт в байт» без сжатия или оптимизации. Это очень удобный формат, поскольку его легко смонтировать стандартной командой mount в любой linux-системе. Более того это самый быстрый «тип» накопителя, так как гипервизору не нужно его никак обрабатывать.
Серьезным недостатком этого формата является то, что сколько Вы выделили места для виртуальной машины, ровно столько места на жестком диске и будет занимать файл в формате RAW (вне зависимости от реально занятого места внутри виртуальной машины).
QEMU image format (qcow2). Пожалуй, самый универсальный формат для выполнения любых задач. Его преимущество в том, что файл с данными будет содержать только реально занятое место внутри виртуальной машины. Например, если было выделено 40 Гб места, а реально было занято только 2 Гб, то все остальное место будет доступно для других VM. Это очень актуально в условиях экономии дискового пространства.
Небольшим минусом работы с этим форматом является следующее: чтобы примонтировать такой образ в любой другой системе, потребуется вначале загрузить , а также использовать утилиту qemu-nbd, которая позволит операционной системе обращаться к файлу как к обычному блочному устройству. После этого образ станет доступен для монтирования, разбиения на разделы, осуществления проверки файловой системы и прочих операций.

Следует помнить, что все операции ввода-вывода при использовании этого формата программно обрабатываются, что влечет за собой замедление при активной работе с дисковой подсистемой. Если стоит задача развернуть на сервере базу данных, то лучше выбрать формат RAW.
VMware image format (vmdk). Этот формат является «родным» для гипервизора VMware vSphere и был включен в Proxmox для совместимости. Он позволяет выполнить миграцию виртуальной машины VMware в инфраструктуру Proxmox.
Использование vmdk на постоянной основе не рекомендуется, данный формат самый медленный в Proxmox, поэтому он годится лишь для выполнения миграции, не более. Вероятно в обозримом будущем этот недостаток будет устранен.

Удаление кластера

Рассмотрим процесс удаления нод из кластера и самого кластера. Данные действия не могут быть выполнены из веб-консоли — все операции делаем в командной строке.

Подключаемся по SSH к одной из нод кластера. Смотрим все узлы, которые присоединены к нему:

pvecm nodes

Мы получим список нод — удалим все, кроме локальной, например:

pvecm delnode pve2

pvecm delnode pve3

* в данном примере мы удалили ноды pve2 и pve3.

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

systemctl stop pvestatd pvedaemon pve-cluster corosync

Подключаемся к базе sqlite для кластера PVE:

sqlite3 /var/lib/pve-cluster/config.db

Удаляем из таблицы tree все записи, поле name в которых равно corosync.conf:

> DELETE FROM tree WHERE name = ‘corosync.conf’;

Отключаемся от базы:

> .quit

Удаляем файл блокировки:

rm -f /var/lib/pve-cluster/.pmxcfs.lockfile

Удаляем файлы, имеющие отношение к настройке кластера:

rm /etc/pve/corosync.conf

rm /etc/corosync/*

rm /var/lib/corosync/*

Запускаем ранее погашенные службы:

systemctl start pvestatd pvedaemon pve-cluster corosync

Кластер удален.

Конвертация виртуальной машины Windows.

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

Теперь переходим непосредственно к конвертации. В консоли хоста Proxmox выполним команду:

Shell

qemu-img convert -f vmdk </path/to/disk.vmdk> -O raw /mnt/pve/hdd1/images/101/disk0.raw -p

1	qemu-img convert-fvmdk<pathtodisk.vmdk>-Orawmntpvehdd1images101disk0.raw-p

В команде, естественно, укажите свои параметры.

Запустится процесс конвертации диска.

После завершения конвертации нужно изменить конфиг виртуальной машины. Для этого открываем в редакторе файл конфигурации ВМ(в нашем случае ВМ имеет ID 101):

Shell

nano /etc/pve/qemu-server/101.conf

1	nanoetcpveqemu-server101.conf

Если узел Proxmox находится в кластере, путь до файла конфигурации будет выглядеть так:

Shell

nano /etc/pve/nodes/<node-name>/qemu-server/101.conf

1	nanoetcpvenodes<node-name>qemu-server101.conf

В строке ide0 укажем наш сконвертированный диск:

Сохраните изменения. Теперь можно запустить виртуальную машину.

Настройка ВМ после конвертации.

После конвертации необходимо проделать следующие действия: удалить VMtools(если они установлены) и установить необходимые драйвера.

Удаление VMtools производится через стандартную оснастку «Программы и компоненты».

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

Для установки драйверов потребуется скачать и подключить к ВМ образ с драйверами. Скачать его можно из официального источника..

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

Это самый простой способ установить необходимые драйвера. Также, не лишним будет установить гостевой агент из папки guest-agent.

Теперь нам нужно переключить системный диск с устаревшего контроллера IDE на Virtio. Для этого выключаем виртуальную машину и вносим изменения в конфиг файл, который мы уже редактировали. Приведем его к следующему виду:

Обратите внимание, что нужно указать первым загрузочным устройством наш системный диск. (Думаю, что загрузочный диск, всё же, лучше разместить на шине 0, поэтому нужно заменить в файле конфигурации virtio1 на virtio0)

Диски, созданные при создании ВМ, теперь можно удалить.

После этого можно включать виртуальную машину и использовать по назначению.

Настройка кластера

Построение кластерной системы выполняется в 2 этапа — сначала мы создаем кластер на любой из нод, затем присоединяем к данному кластеру остальные узлы.

Создание кластера

Переходим в панель управления Proxmox на любой их нод кластера. Устанавливаем курсов на Датацентр — кликаем по Кластер — Создать кластер:

Для создания кластера нам нужно задать его имя и, желательно, выбрать IP-адрес интерфейса, на котором узел кластера будет работать:

… кликаем Создать — процесс не должен занять много времени. В итоге, мы должны увидеть «TASK OK»:

Присоединение ноды к кластеру

На первой ноде, где создали кластер, в том же окне станет активна кнопка Данные присоединения — кликаем по ней:

В открывшемся окне копируем данные присоединения:

Теперь переходим в панель управления нодой, которую хотим присоединить к кластеру. Переходим в Датацентр — Кластер — кликаем по Присоединить к кластеру:

В поле «Данные» вставляем данные присоединения, которые мы скопировали с первой ноды — поля «Адрес сервера» и «Отпечаток заполняться автоматически». Заполняем пароль пользователя root первой ноды и кликаем Присоединение:

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

Готово. Данный кластер можно использовать для централизованного управления хостами Proxmox.

Посмотреть статус работы кластера можно командой в SSH:

pvecm status

Видео обновления кластера proxmox

Помогла статья? Подписывайся на telegram канал автора

Watch this video on YouTube

Онлайн курс «DevOps практики и инструменты»

Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, научиться непрерывной поставке ПО, мониторингу и логированию web приложений, рекомендую познакомиться с онлайн-курсом «DevOps практики и инструменты» в OTUS. Курс не для новичков, для поступления нужны базовые знания по сетям и установке Linux на виртуалку. Обучение длится 5 месяцев, после чего успешные выпускники курса смогут пройти собеседования у партнеров.

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

Создаём виртуальную машину

Чтобы создать ВМ:
1. Определяемся с версией ОС.
2. Закачиваем ISO-образ (заранее).
3. Выбираем в меню «Хранилище» только что вами созданное.
4. Нажимаем «Содержимое» ➝ «Загрузить».
5. Выбираем ISO-образ из списка, потом подтверждаем выбор кнопкой «Загрузить».

В итоге образ отобразится в списке доступных.

Теперь создадим первую виртуальную машину:
1. Следует нажать «Создать VM».
2. Потом необходимо заполнить поочередно параметры: «Имя» ➝ «ISO-Image» ➝ Размер и тип жесткого диска ➝ Количество процессоров ➝ Объем оперативной памяти ➝ Сетевой адаптер.
3. Выбираем желаемые параметры и нажимаем «Завершить». Созданная виртуальная машина отобразится в меню панели управления.
4. Выбираем эту машину и запускаем её соответствующей кнопкой.
5. Переходим в «Консоль» и устанавливаем ОС так же, как и на любой физический сервер.

Если нужно создать ещё одну ВМ, следует повторить вышеописанные операции.

Изменения в Proxmox 6.0

Подробно об изменениях в Proxmox ve 6.0 можно посмотреть в официальном . На opennet сделан перевод основных нововведений. Я внимательно все прочитал, но особо не заметил кардинальных изменений, которые обычно ждешь от новой ветки. Из основных изменений там вот что:

Перешли на кодовую базу Debian 10 Buster.
Все компоненты (QEMU, LXC, ZFS, Ceph и т.д.) обновили до более свежих версий.
Небольшие изменения в gui и некоторого функционала.

Тем не менее, я решил обновить proxmox, чтобы сильно не отставать по версиям. Обычно, если отстаешь по обновлениям, потом все труднее и ленивее наверстывать. Больше шанс, что будут проблемы, если прыгаешь в обновлениях с большей разницей в версиях. Лучше все делать своевременно.

Репликация виртуальных машин

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

Настройка ZFS

Репликация может выполняться только на тома ZFS. Подробная работа с данной файловой системой выходит за рамки данной инструкции, однако, мы разберем основные команды, с помощью которых можно создать необходимы том.

Пул ZFS необходимо создавать из командной строки, например:

zpool create -f zpool1 /dev/sdc

* в данном примере мы создадим пул с названием zpool1 из диска /dev/sdc.

Теперь открываем панель управления Proxmox. Переходим в Датацентр — Хранилище — ZFS:

Задаем настройки для создания хранилища из созданного ранее пула ZFS:

* в данном примере мы создаем хранилище из пула zpool1; название для хранилище задаем zfs-pool, также ставим галочку Дисковое резервирование. Остальные настройки оставляем по умолчанию.

После этого мы должны либо перенести виртуальную машину на хранилище ZFS, либо создать в нем новую машину.

Настройка репликации

Переходим к хосту, где находится виртуальная машина, для которой мы хотим настроить клонирование (она должна также находится на хранилище ZFS) — Репликация:

Задаем настройки для репликации виртуальной машины:

* в данном примере мы указываем системе проверять и реплицировать изменения каждые 15 минут для виртуальной машины с идентификатором 100. Репликация должна проводиться на сервер pve2.

Нажимаем Создать — теперь ждем репликации по расписанию или форсируем событие, кликнув по Запустить сейчас:

Создание виртуальных машин в Proxmox VE

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

~# cd mntdata/template/iso

~# wget https://centos2.hti.pl/8.0.1905/isos/x86_64/CentOS-8-x86_64-1905-boot.iso

Для создания новой виртуальной машины внутри гипервизора необходимо в правом верхнем углу web-интерфейса нажать «Create VM», после чего откроется окно настройки.

Перед вами откроется окно настроек с восемью вкладками и множеством параметров. Рассмотрим основные базовые, вы их можете изменить под свои нужды. Единственный момент, который необходимо учесть при создании виртуальных машин, их ресурсы не должны превышать физические характеристики гипервизора. Логично, что имея физически на боту 16 Gb оперативной памяти, создать виртуальных несколько машин потребляющих суммарно 32 Gb у вас получится, но при превышении ресурсов гипервизор просто «уйдет в себя». Это же касается и емкости жестких дисков

За этим важно следить

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

Node: dedicated
VM ID: 101
Name: CentOS-8
Use CD/DVD disc image file (iso)
Storage: data
ISO image: CentOS-8-x86_64-1905-boot.iso
Type: Linux
Version: 5.x - 2.6 Kernel
Graphic card: Default
SCSI controller: VirtIO SCSI
Bus/Device: VirtIO Block : 0
Storage: data
Disk size (GiB): 120
Format: QEMU image format (qcow2)
Cache: Default (No cache)
Sockets: 1
Cores: 2
Type: Default (kvm64)
Memory (MiB): 4096
Brige: vmbr0
Model: VirtIO (paravirtualized)
Start after created

Сверившись, что все настроено верно, нажимаем «Finish» и ждум загрузку виртуальной машины. Когда она будет запущена, выберем ее и перейдем во вкладку «Console», где увидим окно первоначальной настройки дистрибутива.

Настройка виртуальной машины ничем не отличается от обычной настройки дистрибутива CentOS. Настроив все параметры, сеть, вы сможете подключаться к ней по ssh и работать как с полноценным сервером.

У нас Вы можете арендовать сервер (dedicated server) c поддержкой аппаратной виртуализации, развернуть на котором гипервизор Proxmov VE у Вас не сосотавит труда. Если во время использования инструкции у Вас возникнут вопросы, наша техническая поддержка готова прийти на помощь в любое время.

Ручное перемещение виртуальной машины

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

И так, открываем SSH-консоль сервера, на любой работающем сервере Proxmox. Переходим в каталог qemu-server той ноды, которая не работает:

cd /etc/pve/nodes/pve1/qemu-server

* мы предполагаем, что у нас вышел из строя сервер pve1.

Смотрим содержимое каталога:

Мы должны увидеть конфигурационные файлы запущенных виртуальных машин, например:

100.conf

* в нашем примере у нас запущена только одна виртуальная машина с идентификатором 100.

mv 100.conf ../../pve2/qemu-server/

* где pve2 — имя второй ноды, на которой мы запустим виртуальный сервер.

Командой:

qm list

… проверяем, что виртуальная машина появилась в системе. В противном случае, перезапускаем службы:

systemctl restart pvestatd

systemctl restart pvedaemon

systemctl restart pve-cluster

Сбрасываем состояние для HA:

ha-manager set vm:100 —state disabled

ha-manager set vm:100 —state started

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

После виртуальную машину можно запустить:

qm start 100

Установка Debian 10 на raid

Рассмотрим вариант установки debian на софтовый рейд mdadm. Эта актуальная ситуация, когда вы разворачиваете систему на железе, а не виртуальной машине. К примеру, такая конфигурация будет полезна для установки proxmox. В этой статье я уже рассматривал установку debian на raid1. Но там более старая версия Debian. Так что рассмотрю еще раз эту тему уже на примере Debian 10.

Итак, начинаем установку системы по приведенной ранее инструкции. Доходим до этапа разбивки диска и выбираем режим Manual.

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

Массив raid1, объединяющий оба диска.
/boot раздел прямо на mdadm рейде.
Поверх массива LVM том на всем остальном пространстве, кроме /boot.
Корневой раздел по всему lvm.

В конечном итоге, в конфигураторе это выглядит так:

Последовательность действий для этой конфигурации следующая:

На каждом диске создаете по 2 раздела — один под /boot 500 Мб и второй все остальное пространство.
Объединяете эти разделы в 2 raid1 mdadm. Один массив под /boot, второй под остальную систему.
На массиве под /boot сразу же делаете раздел /boot и файловую систему ext2.
Создаете volume group на весь второй массив, потом в этой группе создаете logical volume под корневой раздел.
В logical volume создаете корневой раздел / и файловую систему ext4.

В итоге у вас должно получиться то же, что и у меня на картинке. Дальше ставите debian 10 как обычно. После установки на raid нужно выполнить несколько важных действий.

Зайти в систему и создать swap.
Установить загрузчик на оба диска. Во время установки он был установлен только на один диск.
Протестировать отказ одного из дисков.

# dpkg-reconfigure grub-pc

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

Смотрим теперь, что с дисками.

Картина такая, как и было задумано. Выключим сервер, отсоединим один диск и включим снова. При запуске, нормально отработал grub, дальше посыпались ошибки в консоль.

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

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

# fdisk -l | grep /dev
Disk /dev/sda: 10 GiB, 10737418240 bytes, 20971520 sectors
/dev/sda1  *      2048   999423   997376  487M fd Linux raid autodetect
/dev/sda2       999424 20969471 19970048  9.5G fd Linux raid autodetect
Disk /dev/sdb: 10 GiB, 10737418240 bytes, 20971520 sectors
Disk /dev/md1: 9.5 GiB, 10215227392 bytes, 19951616 sectors
Disk /dev/md0: 475 MiB, 498073600 bytes, 972800 sectors
Disk /dev/mapper/vg00-root: 9.5 GiB, 10213130240 bytes, 19947520 sectors

Старый диск sda c двумя разделами и новый диск sdb без разделов. Нам нужно на новый диск скопировать структуру диска sda. Делаем это следующей командой.

# sfdisk -d /dev/sda | sfdisk /dev/sdb

Проверяем результат:

# fdisk -l | grep /dev
Disk /dev/sda: 10 GiB, 10737418240 bytes, 20971520 sectors
/dev/sda1  *      2048   999423   997376  487M fd Linux raid autodetect
/dev/sda2       999424 20969471 19970048  9.5G fd Linux raid autodetect
Disk /dev/sdb: 10 GiB, 10737418240 bytes, 20971520 sectors
/dev/sdb1  *      2048   999423   997376  487M fd Linux raid autodetect
/dev/sdb2       999424 20969471 19970048  9.5G fd Linux raid autodetect
Disk /dev/md1: 9.5 GiB, 10215227392 bytes, 19951616 sectors
Disk /dev/md0: 475 MiB, 498073600 bytes, 972800 sectors
Disk /dev/mapper/vg00-root: 9.5 GiB, 10213130240 bytes, 19947520 sectors

То, что надо. Теперь добавляем новый диск в деградированные массивы mdadm.

# mdadm --add /dev/md0 /dev/sdb1

Дожидаемся окончания ребилда массива под boot. Это будет быстро. И возвращаем диск в корневой раздел.

# mdadm --add /dev/md1 /dev/sdb2

Не забываем добавить загрузчик на новый диск.

# dpkg-reconfigure grub-pc

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

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

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

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