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

Нет, это нереально. Попробуйте обратиться к этой статье базы знаний: https://kb.blockbridge.com/technote/proxmox-lvm-shared-storage/ Blockbridge: ультра-низкая задержка, хранилище общего доступа на базе NVMe для Proxmox - https://www.blockbridge.com/proxmox

Может, попробовать что-то вроде этого? https://cstan.io/en/post/2024/01/proxmox-und-ocfs2-shared-storage/

Похоже, этот вопрос задают каждый день. Не знаю, кого отметить, но было бы неплохо запостить что-то вроде закрепленного сообщения. Да, см. https://pve.proxmox.com/wiki/ISCSI_Multipath для настройки мультипути. Что касается настройки пула хранилища, у вас есть 2 варианта (3, если учитывать CFS, но это не поддерживается никем). Прежде чем продолжить обсуждение вариантов, пожалуйста, ознакомьтесь с https://pve.proxmox.com/wiki/Storage для полного обсуждения того, какую встроенную поддержку предоставляет набор инструментов PVE.

Вариант 1: использовать LUN в качестве пула хранилища. Согласно руководству пользователя: обратите внимание, что поддерживается только LVM-Thick, поэтому снимки не будут доступны.

Вариант 2: использовать LUN в качестве диска, подключенного к гостевой ОС. Этот метод потенциально может быть более производительным, чем LVM, поскольку он не подвержен многократному конфликту инициатора (при использовании для нескольких дисков ВМ), но главное преимущество – его область действия ограничена одной гостевой ОС. Это делает практичным использование аппаратных снимков хранилища, которые доступны только одной гостевой ОС для управления выключением, но потребуется ручная организация снимков. Недостаток в том, что из-за отсутствия синхронизации между PVE и хранилищем, управление LUN приходится выполнять вручную для каждого диска — это мучительно и имеет больший потенциал для ошибок.

Вариант 3: использовать Cluster-aware файловую систему (CFS). Есть два известных варианта, которые "работают" на Debian: gfs2 и ocfs2. Ни один из них не поддерживается хорошо, и нет интеграции или оркестровки, встроенной в PVE. Фактически, вы предоставите управление и монтирование CFS на ваших узлах и используете метод "Directory" для предоставления пула хранилища. Все вышеперечисленные варианты предоставляют возможность безопасного подключения к кластеру.

Как упоминалось выше, если вы используете вариант 1, вы будете использовать LVM поверх iSCSI. Thin-LVM использовать нельзя. ZFS поверх iSCSI — это особый случай, который применим к решениям хранения, которые используют ZFS в качестве хранилища И предоставляют API, для которого в PVE предоставлен плагин (ssh+zfs tooling). Этот вариант позволяет использовать API, предоставляемый вашим хранилищем для управления созданием Zvol, снимками и т.д., что фактически обеспечивает интеграцию для развертывания типа вариант 2. Если вы не знаете, какой тип целей используется вашим хранилищем, этот вариант, вероятно, не жизнеспособен. Если вас достаточно мотивированы, возможно, вы сможете написать свой собственный плагин для конкретного решения хранения — на форумах есть примеры людей, которые это делали.

"Предпочтительный" – это нагруженный термин. Простой ответ — нет, но это действительно зависит от сценария использования и ожиданий оператора. Почти любое решение, которое предоставляет целевой объект с плагином (см. 3) И предоставляет доступ по SSH с достаточными разрешениями для выдачи команд ZFS и целей, будет работать. Windows Server не является открытым исходным кодом, и нет того, что я бы назвал поддерживаемым вариантом ZFS для Windows.

Мультипути обрабатывается демоном (multipathd), который является стандартным программным обеспечением Linux. Интеграция C&C в PVE, насколько я знаю, отсутствует. Смотрите https://manpages.debian.org/bookworm/multipath-tools/multipathd.8.en.html для получения дополнительной информации.

В прошлом году, из-за инцидента с электропитанием, мы потеряли два Dell EMC PowerStore 1000T (оба контроллера и весь массив на каждом узле вышли из строя), а вместе с ними – все ВМ на них и один из двух Brocade-коммутаторов. Все эти устройства работали на базе виртуализации ESXi. Электропитание обеспечивал APC Symmetra PX мощностью 160 кВт, но это не помогло. Пришлось восстанавливать всё из бэкапов и вытаскивать старые системы хранения из запасов, чтобы вернуть ВМ обратно. Вывод: чем больше узлов, на которые распределена система хранения данных, тем лучше.

P.S.: После этого инцидента я больше не доверяю "сверхнадёжным" системам хранения данных от вендоров.