Итак имеем:
Одна дисковая корзина с 4 мя дисками.
https://www.supermicro.com/products/chassis/2U/826/SC826BE2C-R741JBOD
Корзина поключена к двум машинам на каждой из которых установлен Proxmox 5.2
Внутри каждого хоста видно по 4 диска, каждый по 5 ТB
Что нужно получить?
Нужно чтоб диски были объеденены в рейд (1 или 10). При этом каждый из хостов должен уметь обрабатывать события рейда, так чтобы при выходе из строя одного из хостов второй без промедления продолжил работу, зная состояние рейда и имея возможность продолжить все что начал первый хост (если в момент выхода из строя первого хоста, этот первый хост что-то делал с рейдом, например выводил из строя умерший диск или восстанавливал данные на замененный диск). Другими словами нужна система кластерного рейда на двух хостах.
Далее поверх этого рейда нужно создать общий для двух нод проксмоксовского кластера ресурс, где можно будет хранить образы виртуальных машин.
Это можно сделать, например, создав LVM группу и указать ее как общий ресурс для этих двух хостов проксмокса в настройках кластера проксмокса (через веб интерфейс).
Это нужно чтоб виртуальные машины которые будут создаваться как lvm разделы внутри этой lvm группы "жили" на этих двух хостах в HA кластере (High Availability). То есть хранилище образов машин у этих двух хостов одно и то же, и когда на нем появляется образ машины то оба хоста видят этот образ. И в том случае если один из хостов отказывает, то второй просто подхватывает образ машины и продолжает работать.
Это нужно чтоб виртуальные машины которые будут создаваться как lvm разделы внутри этой lvm группы "жили" на этих двух хостах в HA кластере (High Availability). То есть хранилище образов машин у этих двух хостов одно и то же, и когда на нем появляется образ машины то оба хоста видят этот образ. И в том случае если один из хостов отказывает, то второй просто подхватывает образ машины и продолжает работать.
Возможные варианты
Первый и кажущийся самый простой вариант: использование линукс софт рейд - mdadm для создания рейда из имеющихся физических дисков. Далее мы получаем одно устройство в системе /dev/md0 , которое мы добавляем в LVM группу и добавляем в кластере проксмокса как общее хранилище.Второй вариант это использование возможностей самого LVM2. lvm сам умеет создавать рейды, правда рейд там не связан напрямую с физическими устройствами, а работает с группой LVM куда добавлены все физические устройства. Далее LVM разбивает все доступное пространство на логические разделы и делает из них рейд.
В нашем случае т.к. дисков четыре, то скорее всего границы условных разделов совпадают с физическими дисками, но если бы их было три или более четырех, то границы полос которые собираются в рейд располагались бы как попало , на разных дисках.
Но в любом случае избыточность данных обеспечивается.
На выходе мы получаем LVM раздел, который внутри себя содержит рейд.
Но теперь нам нужно создать еще одну группу LVM, добавить туда раздел с рейдом и добавить эту группу в проксмоксе как общую для данных хостов.
Можно использовать хитрую и мощную ZFS для того чтоб спомощью ее создать нужный рейд и получить в итоге директорию на каждом из хостов и добавить ее в проксмоксе как общую для хостов.
В этом случае образы виртуальных маших будут храниться уже как файлы, а не разделы. Что замедляет работу, т.к. включается в работу уровень файцловой системы.
Вариант с использованием mdadm страдает тем, что нет нормальной реализации работы mdadm в кластере. То есть, если на одном из хостов вы решили провести например замену диска, то второй хост об этом ничего не узнает и будет продолжать работать с этим рейдом как с нормально работающим рейдом.
Если диск реально вышел из строя, то оба хоста и их mdadm начнут как-то реагировать на это (помечать диск и сообщать о вышедшем из строя устройстве). Но потом при восстановлении данных, когда диск будет заменен, каждый из хостов будет производить по своему и риск попортить восстанавливаемые даные очень велик. Когда две машины пишут в одно и то же место не договариваясь (а работа с договоренностью и есть работа в кластере), это приводит к непредсказуемым результатам.
В проксмоксе нет поддержки работы mdadm как кластерного софта.
Есть специальные дистрибутивы линуксов, где такую возможность реализовали, но это коммерческие продукты и не совместимые с дебиан системами. Это связано с тем что mdadm используют модули ядра.
Например это реализовали вот в таком дистрибутиве:
В этом случае образы виртуальных маших будут храниться уже как файлы, а не разделы. Что замедляет работу, т.к. включается в работу уровень файцловой системы.
Проблемы
Вариант с использованием mdadm страдает тем, что нет нормальной реализации работы mdadm в кластере. То есть, если на одном из хостов вы решили провести например замену диска, то второй хост об этом ничего не узнает и будет продолжать работать с этим рейдом как с нормально работающим рейдом.
Если диск реально вышел из строя, то оба хоста и их mdadm начнут как-то реагировать на это (помечать диск и сообщать о вышедшем из строя устройстве). Но потом при восстановлении данных, когда диск будет заменен, каждый из хостов будет производить по своему и риск попортить восстанавливаемые даные очень велик. Когда две машины пишут в одно и то же место не договариваясь (а работа с договоренностью и есть работа в кластере), это приводит к непредсказуемым результатам.
В проксмоксе нет поддержки работы mdadm как кластерного софта.
Есть специальные дистрибутивы линуксов, где такую возможность реализовали, но это коммерческие продукты и не совместимые с дебиан системами. Это связано с тем что mdadm используют модули ядра.
Например это реализовали вот в таком дистрибутиве:
https://www.suse.com/products/highavailability/
Так что на чистом проксмоксе невозможно реализовать рейд на базу mdadm, работающий в кластере.
В варианте где используется LVM для создания рейда, тоже не все
Сам LVM умеет работать в кластере использую CLVM (реализация LVM для кластера). Но здесь проблема в том что в той реализации CLVM, которая используется в проксмоксе кластерными создается только первичная группа физических томов. То есть если использовать группу LVM, которая создана как кластерная и затем добавлена в кластер проксмокса как общаяя, то с ней нет никаких проблем. Машины создаются и перемещаются. НО! нам нужен еще рейд!
Когда мы создаем рейд средствами lvm у нас нет возможности указать что это тоже кластерный раздел.
Дело в том что любой раздел LVM созданный внутри кластерной группы LVM уже не считается кластерным и доступ к нему на редактирование разрешен только тому хосту который его создавал. Второй хост может получить к нему доступ только если первый хост выключен и второй хост при этом должен перегрузить свою систему LVM. По сути второй хост должен перегрузиться чтоб получить доступ к разделу созданному на другом хосте.
В этом и есть засада, дальше все надстройки над группой LVM созданной как кластерная не имеют смысла, т.к. они уже не могут быть кластерными.
Вот пример создания рейд10 средствами LVM:
# lvcreate --type raid10 -m 1 -i 4 -L 200G -n myr10vol myvg
Кроме этого в некоторой документации по CLVM прямо пишут что кластерный рейд в LVM не поддерживается.
Вот тут например: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/logical_volume_manager_administration/lv
Использование ZFS само по себе не эффективно, т.к. ZFS требует больше накладных расходов по памяти и процессору, чем описанные выше способы. Кроме того из "коробки" ZFS тоже не умеет работать в кластере.
Кроме этого внешнего инструмента придется использовать еще и pacemaker и pcsd службы для создания кластерной инфраструктуры, которая будет обслуживать ZFS. Эти службы будут взаимодействовать с corosync, которая по умолчанию работает в проксмоксе. Все вышеуказанные службы по факту дублируют службы HA самого проксмокса и в каких то места могут конфликтовать ними. Например они могут претендовать на взаимодействие с dlm службой и не давать другим службам работать с dlm.
Получается что кроме того что сама ZFS не быстрая, она еще требует дополнительных служб и ресурсов.
Для того чтобы она заработала в кластере нужно использовать export import функции ZFS. Есть специальный агент который может отслеживать изменения и делать экспорт и импорт вовремя: https://github.com/skiselkov/stmf-ha/
Но настройка и запуск его весьма не тривиальная задача. Проект весьма сырой и поддрежка его очень не большая. Поэтому не стоит расчитывать что он будет работать надежно.
Возможные решения:
Но все таки даже в такой ситуации есть решения, хотя и не такие простые и прямые как хотелось бы.
Давайте разделим задачу на несколько по функциям:
1. Нам нужно что-то что создает и поддерживает рейд из физических дисков
2. Нам нужно что-то что обеспечивает высокую доступность к общему хранилищу
желательно чтобы общее хранилище давало доступ к блочному устройству
поэтому первый вариант:
В проксмоксе мы создаем виртуальную машину в которую пробрасываем все нужные физические диски и которая создает рейд на этих дисках.
И дальнейшие работы с рейдом производятся на одной этой машине.
Сама эта машина содержит iSCSi сервер и предоставляет доступ к блочному устройству.
Высокую доступность этого хранилища мы обеспечиваем средствами самого проксмокса, при этом образ машины с рейдом лежит на локальных дисках которые синхронизируются или средствами DRBD или средствами GlusterFS.
При выходе из строя одного из хостов проксмокса, кластер HA запускает машину с рейдом на втором хосте и хранилище снова доступно.
Нужно только соблюсти очередость загрузки машин, чтобы те виртуальные машины у которых диски лежат на хранилище , которая предоставляет машина с рейдом, запускались после того как хранилище станет снова доступным.
Вот здесь описано подробно как собрать такую схему:
http://yaricprog.blogspot.com/2018/09/jbod-raid10-proxmox-ve-ha-cluster.html
Еще один вариант
Это тоже отделение процессов от процессов хоста виртуальной машиной или линукс контейнером LXC.
В этом варианте, тоже создаем только уже по контейнеру или машине на каждом хосте. Внутри каждой машины организуем рейд через ZFS и организуем кластер для ZFS описанным выше способом. в этом случае службы кластера не будут пересекаться со службами проксмокса.
в итоге машины тоже выдают на выходе iSCSI ресурс, но только выдают они каждый своему хосту.
В этом случае все изменения на хранилище будут синхронизоваться внутри виртуальных машин и на каждом хосте будут одинаковые данные.
А в случае падения одного из хостов виртуальная машина на оставшемся хосте увидит изчезновение второй машины из кластера и будет обслуживать хранилище сама, до появления второй машины.
В этом случае кластер HA проксмокса запустит все машины которые имели диски на общем хранилище, на втором хосте.
И последний не очень удобный вариант, это использовать обычный LVM и рейд созданный в нем же на каждом хосте и если виртуальных машин, которые будут "жить" на общем большом хранилище не много, то можно просто создавать и обслуживать машины только на одном хосте.
И если этот хост сломался, то на втором нужно перезапустить систему ЛВМ и тогда диски всех машин будут доступны для работы.
Но это уже не совсем HA.
