Одна машина, две философии: что должно быть основанием, хранилище или виртуализация?

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

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

Что здесь означает «основание»

Основание это слой, который продолжает работать, пока вы возитесь с другим. В этом вся разница, и её легко упустить, сравнивая списки возможностей.

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

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

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

Вопрос, который решает на самом деле

Не «что я хочу запускать», потому что оба ответа запускают всё. Спросите иначе: для чего эта машина в свой худший день?

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

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

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

Чего на самом деле стоит каждая сторона

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

Сначала гипервизор. Хранилище приходит деталями, а не готовым изделием. Вы выбираете раскладку, решаете про избыточность, настраиваете проверки и наблюдение, и нигде дружелюбный мастер не предложит «просто сделать общую папку». Гибкость настоящая, и время сборки тоже.

⚠️ Обе стороны делают перезагрузку дорогой, и это удивляет тех, кто думал, что выбор «сначала диски» от этого защищает. Обновление ядра кладёт машину в любом случае, вместе со всем, что на ней. Основание это про то, что переживёт ваши изменения, а не про то, что переживёт перезапуск.

Гибрид и отказ, который он добавляет

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

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

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

Что не решает

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

Что проще установить. Установка бывает один раз. Жить вы будете со вторым годом, когда что-то придётся менять.

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

Что делает Atlas

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

Цепочка ресурсов рисуется от каждой машины до физического диска, поэтому собранная вами схема становится видимой картиной, а не воспоминанием о решении. На стороне массива эта картина подразумевается, потому что массив и есть продукт; здесь её нужно показать, и показать её и есть смысл.

Работа с хранилищем идёт через направляемый поток с предпросмотром операции и путём назад, для ZFS, LVM и Btrfs. Это не выбирает за вас и не должно: это делает сделанный вами выбор проверяемым потом, а именно эта часть решает, каким будет второй год.