Организация RAID (mdadm) + виртуализация. Выбор реализации.
 

Здравствуйте.
Появилась задача собрать простой сервер на обычных комплектующих, т.е. без горячей замены, RAID контроллера и т.п. Предполагается наличие 2 или 3 с организацией отказоустойчивости. Первый простой и бесплатный вариант это mdadm, он же softraid. Для виртуализации нужен гипервизор, но раньше с ними не работал, только VMWare под виндой поиграться и KVM под Linux в продакшене. Попробовал поставить Proxmox в виртуалке, он не умеет в mdadm (и вообще не разрешает делать разметку диска вручную), но умеет в RAID1 on zfs, с чем я не сталкивался и опасаюсь. ESXi, vSphere, Hyper-V пока не пробовал, но подозреваю, что там с soft raid будет все плохо.
Другой вариант вижу, это минимальный ubuntu lts с mdadm + kvm и уже в нем поднимать виртуализацию. С этим вариантом я хотя бы работал.
Что можете подсказать? Может есть еще какие-то решения?

2 или 3 чего? Сервера? И в чём будет выражаться отказоустойчивость, если это обычные десктопы с локальными хранилищами?

2 или 3 HDD в RAID1 или RAID5. Ну и с отказоустойчивостью я тоже погорячился. Просто увеличение шансов сохранить данные + бэкапы в облако по расписанию.

Ужас, если какой-то винт умрет, то при пересборе массива почти со 100% вероятностью вылетит еще один диск и данным труба.
Возьмите на "развалах" какой-то б/у рейд контроллер типа DELL PERC H310 или что-то рядом и на 4 дисках создайте RAID 10. Будет Вам прирост чтения/записи хоть.

Он одному заказчику на хетзнере взяли "сервер" на треадрипере 1950, попросили немцев поставить туда рейд-контроллер и батарейку за отдельную абонплату, поставили туда вмвару 6,7 и все нормально уже год бегает.

Лучше 4 в RAID 10 (быстрее как в плане работы, так и восстановления, также вылет диска практически не сказывается на скорости работы, но гарантирована работа только при вылете одного диска) иди в RAID 6 (чуть медленнее RAID 10 в работе, сильно медленнее восстанавливается из сбоя, но зато гарантирует работу при вылете двух дисков)
Умеет, только надо ставить голый дебиан на mdadm и сверху накатывать проксмокс. Также можно сначала установить pve на один диск и потом преобразовать в массив. Не самые правильные решения, но они работают и гайды есть. А так соглашусь с или любой другой железный контроллер.
ZFS надо много памяти под кэш, очень много. Собственно, его на машинке с менее 32 GB даже не следует ставить, притом что он половину сожрёт.

Вообще рекомендую ставить небольшой RAID1 под систему (тому же проксмоксу за глаза хватит 120 гиг например на зеркале из двух ссд) и отдельный сторедж для виртуалок, а там уже можно играться. Можно даже слепить массив на тухлых SATA 7200, но ускорить его SSD кэшем.

Спасибо за ответы, товарищи. Финансы ограничены, директор жмется на деньги, потому такие извращения приходится терпеть. О 4рех дисках можно не заикаться. Но как показала практика и небольшая нагрузка, пары дисков в RAID1 хватит. Железный RAID контроллер покупать это тоже немного краеугольный камень. Нужна обязательно батарейка + могут быть проблемы, если вдруг сам железный RAID накроется. SoftRAID от железа хотя бы не зависит.
Плюс если получится, то попробую настроить выключение сервера по сигналу от ИБП при отключении питания.
Да, спасибо. Буквально пару дней назад попалась статья, как это провернуть. Скорее всего так и буду делать.

Лет уже много как в контроллерах NVRAM и батарейка не нужна. Разве что откопать совсем старое старьё лет 10+
Ну когда что-то накрывается это всегда проблемы, а так просто меняешь сдохший контроллер на новый, import foreign и едем дальше.

Мониторинг конечно нужен, а то 100500 раз видел случай, когда система месяцами пахала на деградировавшем массиве, потому что никто этого не заметил, а заметил только когда всё окончательно навернулось.

Поставить чистый debian на MDADM. При установке разделить диски на три раздела - под /boot в RAID, под LVM для debian в RAID и под LVM для виртуальных машин в RAID
Далее на debian установить proxmox

Спасибо за ответ. Почти так так и сделал, только разделов два. Один по /boot, другой полностью под pvolume, а в ней LVM для корня самого proxmox и отдельный LVM, который монтируется в папку, а эта папка выступает storage для самого proxmox и там в виде файлов будут лежать виртуалки.

Под хранилище виртуальных машин лучше делать именно отдельное LVM на отдельном разделе. Тогда сами образы дисков будут представлять не "файлы в папке", подверженные сбоям файловой системы хоста, а отдельные разделы LV, с которыми ничего не случится. При этом им можно будет легко увеличивать размер, делать снапшоты, переносить на другие PV и так далее.


Что могу посоветовать.
1. Вывести из RAID один раздел и разделить его на два, в каждом из которых создать новые "деградированные" RAID
2. В большем создать LVM хранилище виртуальных машин и средствами Proxmox сделать перенос дисков в новое хранилище
3. Меньшее подключить к LVM хоста и перенести в него разделы хостовой системы
4. Опустевший RAID уничтожить, и его раздел также разделить на два, которые будут введены в RAID'ы, созданные на п.1

Я не то чтобы каждый день занимаюсь такими видами работ и ваша инструкция мне понятна, но довольно рискованна. Сервер уже в полупродакшене, потому не хочется все сломать и потом все с нуля восстанавливать. Да и время уже поджимает.
Так же я читал про хранилища lvm, на которых располагается виртуальная машина. Минусом этих способов является невозможность легкого бэкапа виртуалки. Когда она в виде одного файла, ее легко можно скопировать на другой хост.
Даже если виртуальная машина представляет собой отдельный файл, то proxmox позволяет увеличить размер виртуального жесткого диска, а внутри виртуалки достаточно сделать resize2fs.
У меня сейчас 2 md раздела. В первом /boot хоста, второй введен в pvgroup. В этой pvgroup введен один vgroup. В ней один lvm на 30Гб для хоста (proxmox) и второй lvm на 400Гб для proxmox-storage. Этот второй lvm монтируется в папку /pvestorage, а папка является storage для proxmox. Теоретически на все свободное место я могу расширять lmv или создать третий lvm и подключить его как еще один storage.

O'rly?

Когда она внутри LVM, то её ещё легче скопировать куда надо
sudo ddrescue /dev/virtuals/image /внешний_hdd

То есть у вас LVM внутри LVM, в котором всего один логический раздел EXT4, в котором лежат файлы образов дисков?
Тут или один LVM лишний, или лишний логический раздел с файлами.

cnyx, чем рассказывать словами, показали бы вывод lsblk. А то сложно вникнуть, кто на ком стоял.

Что-то думал написал ответ, а по факту не написал. Вот вывод

О, ещё и один раздел под всю систему хост-машины.
Небось ещё, swap в виде файла подкачки, работа с которым будет использовать ресурсы файловой системы этого раздела.
Активные логи вместе с неизменяемыми файлами и полная проверка всей этой красоты при аварийном отключении электропитания.

А целых 4 Гб под /boot - это пять. Планируете использовать 40 разных версий образа начальной загрузки?
Там и 500 Мб за глаза хватило бы.

Это нормально.
Места дофига, а иногда нужно вернуться к старым ядрам, переборчик канеш, гига хватило б, но свободного места реально дофига походу.

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

Может его вообще нет. :) Но тут соглашусь, надо в lvm его. Благо это несложно.

cnyx, насколько вижу, полно места на PV свободного, не нужна чехарда с выводом диска из массива. Просто делаете новый lvm thin pool, подключаете в качестве стореджа и переносите туда виртуалки стандартным дамп-рестором. Пошаговые команды для этого вам нужны или сами справитесь? Покажите кстати вывод команд pvs; vgs; lvs -a

Jula0071, а зачем swap в lvm? - с файлом проще

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

Ага.
Места много, решил не экономить. А то уже доэкономились предыдущие админы, что старые ядра не удаляют, а под новые места не хватает.
Нашел старинный APC, достал через друга родной шнурок, провозился с NUT, который глючил. Поставил apcupsd. Хоть какое-то аварийное завершение будет.
swap в файле. Да. Ну я так решил. На данный момент 2 виртуалки на 6Гб ОЗУ. Всего 16Гб ОЗУ.
Вывод вот.
Насколько я понял, мне надо просто создать LVM раздел, указать его как storage в proxmox и перенести туда виртулки. Сервер в продакшене. На одном samba, резервные копирования, бэкап в облака и Dropbox. На втором Zabbix + pi-hole. Раньше думал поднимать bind для управления NS записями + www + почта. Но так как сейчас NS-ами дают управлять регистраторы доменов, а хостинг с почтой в 5Гб стоит 200р/мес, что выглядит слегка надежнее, чем мой сервак, то от третьей виртуалки я пока отказался.
И вот сижу и думаю, а в чем великий смысл той переделки, что мне предлагаете? Для меня текущий подход слегка прозрачнее. Я в любой момент могу .qcow2 любой виртуалки переписать по сети на другой комп и обеспечить резервирование всей машины на другой физический комп. Лезть в продакшн совершенно не хочется. В силу определенных обстоятельств, если что-то пойдет не так, то придется на работе ночевать, чтобы все это поднять заново.

Цитата:

Цитата Jula0071 зачем дополнительную нагрузку на фс »

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

ровно те же сомнения можно и в адрес lvm выдвинуть: зачем на него дополнительная нагрузка

возможно у "Proxmox" своя атмосфера, но для vmware и hyper-v рекомендуют выдавать диски файлами, а не лунами

Не просто LVM раздел, а LVM thin pool.

Быстрее работает, как raw image, но не теряется функционал снепшотов и thin provisioning. Также меньше риск повреждения образов при сбое.
Точно так же можно скопировать логический том, как любое блочное устройство. В кластере proxmox это всё делается в один клик. Но если у вас нет кластера, а в качестве резервной машины например виндотазик, то ваш подход конечно гибче (и страннее).
Не лезьте.
Ничего там не пойдёт не так, если конечно сами не нарукожопите. Можно даже оставить на какое-то время оба типа стореджа и сравнить, что лучше подходит. Но если не уверены в том, что точно понимаете что делаете, то действительно в прод лучше не лезть.

Proxmox. В отказоустойчивость - умеет. Поддерживает GlusterFS и Ceph (если планируете применять, Gluster нужно сразу подключать дебиановскую репу и ставить последний минорный)
Умеет миграцию Live виртуалок (лучше всего - как раз на сетевых FS или iSCSI, пробовал и то и то).
ZFS бояться не нужно, отлично работает, zmirror умеет (вместо mdadm)
Управление кластером либо мышкой клац-клац либо нормальное из шелла - на выбор.