+7 (495) 320-70-49
- Назад
- Телефоны
- +7 (495) 320-70-49
- Заказать звонок
info@proxmox.su
Москва, Бакунинская улица, 69с1
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

Поддержка Fibre Channel (FC-SAN), Proxmox Виртуальная Среда

sys92

Guest

30.05.2025 18:56:00

Есть ли какие-то планы по добавлению полноценной поддержки Fibre Channel (FC-SAN) с возможностью создания снимков и совместного использования хранилища в будущих релизах Proxmox VE? Сейчас можно работать с FC через multipath и LVM, но отсутствие поддержки снимков и настоящей интеграции с общим хранилищем ограничивает его полезность в корпоративной среде — особенно по сравнению с VMware и подобными платформами. Это улучшение значительно повысит конкурентоспособность Proxmox в виртуальных окружениях, где уже присутствует высокопроизводительная SAN-инфраструктура. Буду признателен за любые сведения или информацию о дорожной карте. Спасибо!!!

alexskysilk Guest	#2 0 30.05.2025 19:43:00 Я не представляю Red Hat. Если вам правда интересно, обратитесь в их отдел продаж. А если нет, то это может вам помочь: https://docs.openstack.org/cinder/latest/reference/support-matrix.html

bbgeek17

Guest

30.05.2025 19:18:00

Привет, @sys92, добро пожаловать на форум! Если под "нативной" ты подразумеваешь интеграции FC, специфичные для конкретных вендоров, то нет — в этом направлении планов пока нет. Если же речь идет о нативной поддержке FC внутри Proxmox VE, то любые разработки в этой области, скорее всего, останутся в тестовых или бесплатных репозиториях на неопределенное время — так что пока не рекомендую использовать это в продакшене. VMware полагается на VMFS — проприетарную, кластеризованную файловую систему, специально разработанную для общего FC-хранилища. Прямого сопоставимого, готового к продакшн-использованию аналога в экосистеме PVE пока нет. Proxmox стабильно растет, фокусируясь на своих сильных сторонах и захватывая определенную нишу на рынке виртуализации. Спешка с реализацией сложной функциональности хранилища, особенно той, которая затрагивает основные компоненты, такие как снапшоты и кластерная согласованность, противоречила бы его продуманной философии разработки. Тем не менее, есть производители хранилищ, помимо традиционного "хранилищного картеля", которые поддерживают Proxmox нативно и предлагают надежную функциональность. А пока, возможно, эта статья базы знаний окажется полезной: https://kb.blockbridge.com/technote/proxmox-lvm-shared-storage/ Blockbridge: ультранизкая задержка общего хранилища на базе NVMe для Proxmox - https://www.blockbridge.com/proxmox

LnxBil

Guest

30.05.2025 19:33:00

Я бы даже заменил PVE на Linux в этом предложении, и не вижу, чтобы это произойдет в ближайшее время, если вообще произойдет. Ни один крупный игрок/соратник Linux больше не использует такую устаревшую технологию, и, соответственно, нет ни потребности, ни людей для реализации этого. Мы почти на той точке, когда этот вопрос задают несколько раз в неделю. Может быть, пора создать страницу вроде linuxatemymemory, но для FC-based SAN… типа WhyDoesProxmoxVeNotSupportFcBasedSanWithSnapshotsAndThinProvisioningAndNeverWill.com и перенаправлять туда людей.

alexskysilk

Guest

30.05.2025 19:36:00

Я знаю, что @bbgeek17 слишком скромный, но я почти уверен, что вы сможете получить нужную функциональность, используя blockbridge. Поддержка SAN уровня блоков через API в PVE долгое время не входила в планы, и похоже, что этого не изменится. Linux – не гипервизор. Существует множество гипервизоров на базе Linux, поддерживающих эту функциональность (XCP-NG, RHEV, Openstack и т. д.).

LnxBil Guest	#6 0 30.05.2025 19:38:00 С каким файловой системой для готовой к производству, выделенной, совместно используемой памяти?

LnxBil

Guest

30.05.2025 19:52:00

Я не вижу ни одного драйвера ядра Linux, который бы не был частью Linux, это просто интеграция оборудования от вендора/продукта. Большинство - это драйверы интеграции оборудования, похожие на те, что есть для PVE. Если бы больше вендоров напрямую поддерживали PVE, PVE не всегда бы винили за то, что не интегрируют ту или иную технологию хранения. Это просто не их задача, а задача вендоров. Blockbridge – лучший пример того, как это делать правильно. Поэтому я рекомендую его всем, кто спрашивает меня, что использовать, если CEPH не подходит.

alexskysilk Guest	#8 0 31.05.2025 00:19:00 Точно. Водители в порядке. Да. Вот в чем дело. Это довольно глупое замечание. PVE ни за что не отвечает и поддерживает то, что хочет. Опять же, вот в чем дело. Это не техническое ограничение.

sys92

Guest

01.06.2025 15:40:00

Спасибо всем за разъяснения! В общем, хотя использование LVM на SAN-хранилище с поддержкой мультипутей возможно, по сути это не файловая система для кластеров и не может безопасно поддерживать одновременный доступ из нескольких узлов без дополнительных компонент кластеризации и файловой системы, поддерживающей кластеры, поверх нее. Поэтому в корпоративной производственной среде полагаться только на LVM поверх общего SAN-хранилища без надлежащей кластеризации и файловой системы, поддерживающей кластеры, не считается безопасным или поддерживаемым. Пожалуй, пора изучить решения вроде oVirt или OpenStack или RHV, как некоторые из вас предлагали, ведь я не могу оправдать снос мощной SAN-подсистемы с высокопроизводительными SSD-накопителями.

waltar

Guest

#10

01.06.2025 16:24:00

Забавные проблемы... просто используйте любое внешнее хранилище SAS или FC, забудьте про полноценный LVM, используйте XFS напрямую на томах, экспортируйте по NFS на PVE. Любой переход на другой NFS-хост можно выполнить за секунды скриптами и ctdb. Любой упавший PVE потребуется больше 3 минут, чтобы запустить машины (VM/LXC) на других узлах.

W Пост в треде 'Ожидаемые скорости и производительность PBS' 9 апреля 2025 г.
Отличное решение и довольно хорошие результаты PBS. У нас есть действительно тихое и необычное решение, полностью без vzdump или PBS, на куче даже старого оборудования: PVE на Dell T620, 2x 6-ядерный Xeon E5-2620 @ 2GHz +HT, 32GB, с dr-backup хранилищем 8x4TB HDD как perc p710 raid6 с XFS, pbzip2'ed и duperemove'd, 1x 10Gbit между файлосервером с Rocky9.5 на Lenovo x3650 M4, 1x 4-ядерный Xeon E5-2609 v2 @ 2.50GHz +HT, 128GB, 10x4TB HDD как ServeRAID M5110 raid6 с XFS.

Демонстрация 32GB диска VM vm-158-disk-1.qcow2: Бэкап как reflink 32GB: 0.002s на файлосервере, 32774MB/0.002s = 16 GB/s. Бэкап на хранилище PVE по NFS-copy...

waltar

W Пост в треде 'best-practices für Enterpriseumgebungen' 7 апреля 2025 г.
ls */srv/data/images/146/vm-146-disk-0.raw daily.2025-02-14_0001/srv/data/images/146/vm-146-disk-0.raw daily.2025-03-25_0001/srv/data/images/146/vm-146-disk-0.raw daily.2025-02-15_0001/srv/data/images/146/vm-146-disk-0.raw daily.2025-03-26_0001/srv/data/images/146/vm-146-disk-0.raw daily.2025-02-17_0001/srv/data/images/146/vm-146-disk-0.raw daily.2025-03-27_0001/srv/data/images/146/vm-146-disk-0.raw daily.2025-02-18_0001/srv/data/images/146/vm-146-disk-0.raw daily.2025-03-28_0001/srv/data/images/146/vm-146-disk-0.raw daily.2025-02-19_0001/srv/data/images/146/vm-146-disk-0.raw...

waltar

floh8

Guest

#11

01.06.2025 17:28:00

Нет. Это верно для lvm-thin, но не для общего lvm. Прочитайте документацию под заголовком "storage" и здесь, на форуме. Это уже отвечали сотню раз. Но ваш исходный вопрос касался разработки поддержки pve для общего блочного хранилища со снапшотами: ответ в том, что Proxmox работает над решением, подобным Ovirt. Посмотрите на этот пост: https://bugzilla.proxmox.com/show_bug.cgi?id=6096

spirit Guest	#12 0 01.06.2025 17:50:00 Да, снимки на SAN в разработке (с qcow2 поверх LVM, как в oVirt, в общем). Работаю над этим, надеюсь закончу к PVE9.

alexskysilk

Guest

#13

01.06.2025 18:15:00

Действительно, но с этим можно жить, всё зависит от вашей приверженности работе в PVE в производственной среде и наличия DevOps-специалистов.

Способ 1: LVM Thick+Hardware snapshots. Если у вас есть хранилище с внутренней тонкой провизией и поддержкой снапшотов (у многих она есть), можно организовать рабочие процессы qm-freeze storage-snap qm-thaw. Вы получаете фактическую тонкую провизию через хранилище и доступ к снапшотам. Недостаток в том, что снапшоты будут состояниями LVM, то есть восстановление — это все или ничего, без какой-либо детализации, что ограничивает их полезность. Это подводит нас к способу 2: direct mapped LUN к ВМ. Это устраняет необходимость в каком-либо управлении томами, поскольку LUN принадлежит гостевой ОС. Тонкая провизия и снапшоты работают как задумано, хотя вам всё равно потребуется организовать их, недостаток в том, что управление хранилищем теперь должно быть в двух разных местах — PVE и SAN, и это может стать громоздким и подверженным ошибкам.

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

sys92

Guest

#14

01.06.2025 18:20:00

Отличные новости! Ты имеешь в виду, что что-то вроде ниже в будущих релизах получит возможности создания снимков и обмена? Или будет реализована какая-то новая файловая система, отличная от xfs/ext4 и прочих, поддерживающая кластеры?

```
# Настройка multipath по всем узлам и затем

# Получение доступного LUN
pvcreate /dev/mapper/<storage path-of-LUN>

# Создание VG
vgcreate <vgname> /dev/mapper/<storage path-of-LUN>

# Создание LV
lvcreate -n data -l 100%FREE <vgname>

# Форматирование LV с любой файловой системой
# какая-нибудь файловая система, поддерживающая кластеры
mkfs.xfs -K /dev/mapper/<storage path-of-lv>

# Монтирование по всем доступным узлам
mount /dev/mapper/<storage path-of-lv> /path/to/SAN-MOUNT
```

bbgeek17

Guest

#15

01.06.2025 23:19:00

Вообще-то это вовсе не файловая система. Это менеджер томов. И это правильно. Программное обеспечение PVE выступает в роли арбитра, чтобы обеспечить безопасность. Схема PVE/LVM не нуждается и не использует отказоустойчивую файловую систему. Можно использовать CAFS вместо LVM или вместе с ним, вне механизмов PVE. Вы публикуете это в форуме PVE. Если вы говорите о PVE — вышесказанное неверно. Если вы имели в виду что-то, что выходит за рамки PVE, то есть общая Linux — вы правы. Blockbridge: ультра-низкая задержка, общая система хранения на базе NVME для Proxmox — https://www.blockbridge.com/proxmox

sys92 Guest	#16 0 02.06.2025 20:29:00 Спасибо всем за полезные комментарии и разъяснения! Мне удалось запустить два узла с Ovirt с FC-SAN для тестирования. Как только выйдет версия PVE 9 с поддержкой FC, я пересмотрю.

bbgeek17

Guest

#17

02.06.2025 20:54:00

Ты смотрел, как продвигается проект на сегодняшний день? Если правильно помню, последний раз мы обсуждали это вот здесь: https://lists.ovirt.org/archives/list/users@ovirt.org/thread/6Z5CCSNZPSBBG2M3GN5YJBNFEMGEHNEA/ Последний релиз был 12/1/23. Blockbridge: ультра-низкая задержка, все-NVME, общая память для Proxmox - https://www.blockbridge.com/proxmox

sys92

Guest

#18

03.06.2025 17:50:00

Hey everyone! 👋

Just wanted to share a quick update on the project. We're making good progress, but we've hit a few snags. Nothing major, just some minor adjustments needed. 😅

Here's a breakdown of what we've been working on:

* **Feature A:** Implementation is 80% complete. We're just ironing out some edge cases.
* **Feature B:** Encountered a tricky bug with the API integration. Working on a fix now. 🛠️
* **Feature C:** Design is finalized and ready for development.

We're still on track to meet the deadline of October 27th. Your feedback is always appreciated! Let me know if you have any questions or concerns. 🙏

Thanks,
[NikitaDev]
#projectupdate #development #progressreport

alexskysilk

Guest

#19

03.06.2025 18:19:00

Понимаю. На мой взгляд, развертывание продукта, фактически не имеющего поддержки (от кого бы то ни было), – это плохое решение, вне зависимости от бюджетных ограничений. Простои, потеря сервиса или потеря данных обходятся дороже, чем первоначальные затраты. Учитывая ваш набор ограничений, я бы, наверное, присмотрелся к XCP-NG, а не к oVirt, хотя PVE тоже может работать – отсутствие снапшотов не обязательно должно быть критичным для двухнодового окружения. Почему? Вся суть Open Source в том, что ее нельзя "закрыть". Владелец IP может изменить лицензию исходного кода, чтобы сделать ее проприетарной для последующих версий, но это не изменит лицензию для предыдущих релизов; форки возникают регулярно. И да, разработчики могут уйти по целому ряду причин. Это не тенденция, это простая бизнес-реальность, которая всегда существовала как в коммерческом, так и в Open Source пространстве. В случае с oVirt, когда IBM купила Red Hat, они не хотели продолжать инвестировать в RHEV (и, как следствие, в ее некоммерческую версию, oVirt), потому что у них были другие продукты для этой области. Поскольку oVirt был на 100% программным обеспечением Red Hat, удаление всей команды разработчиков означало, что любой, кто хотел бы продолжить поддержку, должен был взять на себя весь проект. Пока что желающих нет. В этом конкретном случае именно ЛИКВИДАЦИЯ корпоративного финансирования убила проект. Но не сомневайтесь, Open Source никуда не исчезнет. Можете быть уверены, что нет никакой "тенденции" и нет опасности "эрозии экосистемы Open Source".

Johannes S Guest	#20 0 04.06.2025 09:33:00 Точно, смотри этот раздел вики, там это описано. Конечно, это не сработает ни в каком сценарии, очевидно, но может быть достаточно для сценария OP. И любое решение на базе KVM (например, ProxmoxVE, Openstack или что-то еще) имеет преимущество в том, что даже в худшем случае (например, разработка этого решения прекратится или стоимость подписки вырастет до уровня VMware) можно будет перенести все на обычную Linux-систему и запускать виртуальные машины оттуда. Это будет не так удобно (из-за отсутствия WebUI), но поскольку KVM (сама технология гипервизора) является частью ядра Linux, ты сможешь запускать все, пока ядро Linux продолжает включать KVM (что вряд ли изменится).

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры