Pull to refresh

Comments 29

Странно, в моих инсталляциях PVE, включая ядро почему-то на Debian'е основан.
Ядро PVE основано на ядре проекта OpenVZ, которое, в свою очередь, основано на RedHat-ядре.

root@srv01-vmx:~# zless /usr/share/doc/pve-kernel-`uname -r`/changelog.Debian.gz

А основа системы — да, Debian.
А по моему у них чистое RH ядро, когда были проблемы с bouding на серверах после обновления ядра, косяк оказался в патчи от RH. Хотя я тут не эксперт, просто на форуме как раз проблему обсуждали и как то врезалось в память.
Они используют ядро от OpenVZ, которое слегка патчат.
OpenVZ берут RedHat-ядро, которое серьезно патчат :)

В /usr/share/doc/pve-kernel-`uname -r`/changelog.Debian.gz все написано.
winduzoid, не только вам, но и остальным собравшимся.
Ядро с дистрибутивом не путаете?
Из первых уст: «ядро RH cлишком глючное, чтобы его использовать в Proxmox, но допилить его было проще. Как только появится время, поделки RedHat будут полностью исключены». «Проще» исходит из того, что KVM под крылом RedHat, не более
Я вас не понял :)
Ядро с дистрибутивом не путаю.
UFO landed and left these words here
Вот разработчики что говорят на самом деле.
Скажите, я вот немного не понял. Зачем вам GFS?
Так же не понятно с multipath. У нас проавда не iscsi а fiberchannel и много машин.
Все машинны видят массив общий с FB, а уже при создании самих виртуальных машин используется LVM Group.

Руки добраться до GlusterFS и Ceph, так и не дошли :)
Все машинны видят массив общий с FB, а уже при создании самих виртуальных машин используется LVM Group.

Кластерная файловая система обычно нужна для того, чтобы можно было диспетчеризовать записи на общее хранилище. Иначе как все доступающиеся к данныи на общем сторадже системы узнают, что одна из них изменила байт в совместно используемых данных?
GFS2. Потому что он работает. И потом, при наличии под рукой работающего RedHat-кластера самое логичное — задействовать их же файловую систему :)

Что вас смутило в multipath? Если у нас есть один и тот же iSCSI-таргет, приходящий по двум разным интерфейсам — грех не задействовать их оба :) Да, без multipath можно было бы обойтись. Но реализация была бы сложнее. Для балансировки нагрузки на хранилище часть машин пришлось бы цеплять на один интерфейс, часть — на другой. К тому же, хранилище умеет при выходе из строя одного из контроллеров переключать его нагрузку на выживший контроллер. В этом случае multipath сильно поможет не упасть всему кластеру.
Я как то проще сделал.

У нас MSA 2000, FB, Куча машин подключенных к ним. Каждый кластера видит все разделы на MSA — присоединим его LVM GROUP, и уже раздел задействуем для виртуальных машин.

Зачем надо и самое главное ГДЕ? использовать GFS2 я ка кто не могу понять.
storage с тестовой машины.
Вы используете OpenVZ в вашем окружении?
нет. Хотя у меня только мысль сейчас проскользнула, что наверно для openvz :)
Да я как всегда по диагонали :)

И как GFS2? Просто года 2 назад, мы отказались от нее в пользу ocfs2. Было с gfs2 очень много проблем, в частности с журналом.
Нам нравится. Проблем с журналом не наблюдали. Ну и за два года очень много всего изменилось. GFS2 сейчас признана стабильной RedHat-ом. Они декларируют ее поддержку в RHEL.

ocfs2 мы пока не трогали. В Proxmox ее нет, а пересобирать ядро специально для нее пока не хочется. Но пробовать будем.
Думаю не надо. У OCFS для RH все осталось как и два года назад. :)
oss.oracle.com/projects/ocfs2/files/RedHat/RHEL5/x86_64/1.4.9-1/

Такой подход мне не очень нравится.

Я вот думаю все же осилить и сделать ceph (proxmox его официально планирует поддерживать) и glusterfs — его можно попробовать с proxmox связать через nfs :)
Ну мы начали с gfs2 потому что она единственная, по сути, без бубна поддерживает работу со standalone-хранилищем. Для всего остального нужны более сложные схемы (серверы журналов, полноценные ОС на стораджах и пр.).

Мы сейчас начинаем раздумывать над реплицируемым между датацентрами хранилищем. Ну и параллельно еще копаем в стороны. :)
И я думаю правильно сделали. Хотя с OCFS2 кроме как смена ядра, проблем особых не было.

Ну самый лучший способ репликации, это средствами самого MSA. Правда насколько я помню, MSA не умеет делать snapshot куда то во вне, для этого лучше подходит EVA. Eva вообще вкусная штука.

Еще как вариант у GFS есть возможность делать репликации между ЦОД, умеет ли ceph не знаю.
Если работаете в основном с OpenVZ, то у них есть своя ФС для контейнеров. В последних версиях они научились мигрировать состояние сетевых сокетов итд итп. В общем очень много плюшек.
> Eva вообще вкусная штука.
Это если не пробовать ничего слаще морковки :)
Да, мы поэтому пока на ocfs2 и не смотрели. Там все так же до сих пор, мне кажется.
Мне кажется для такого проекта как Proxmox освоить технологию «ocfs2» всё же нужно.
Ведь потенциального пользователя proxmox может устраивать всё, кроме работы с дисковыми хранилищами.

Ещё вопрос в тему: Скажите, а поддержка DRBD есть? Если есть и она работает нормально, то где можно почитать о том, как всё это работает вместе с «fenceing» и как настроена защита от SplitBrain. Спасибо.
Там проблема в том, что Оракл перестал поддерживать RedHat-ядра. Из-за этого работа в Proxmox с ocfs2 затруднена.

Поддержка DRBD есть. Мы не пробовали.
Вот здесь написано про fencing в связке c DRBD: pve.proxmox.com/wiki/Two-Node_High_Availability_Cluster
Или вы спрашиваете, зачем нам вообще кластерная FS?
Они вообще все такое кластерное и не только выпилили из ядра, оставили только GFS2, модифицированные corosync, cman и drbd.
На все вопросы на форуме отвечают: «извините, у нас другая концепция, мы будем ее придерживаться, и этот модуль мы включать не будем».
Так что если у вас proxmox, ничего другого и не выйдет ))

ploop очень радует, не пробовали его? Его бы еще запилить для ceph, было бы счастье. Для kvm ceph неплохо уже работает.

Нет, ploop пока не пробовали. Но в ближайших планах есть.
Ну так проблема в том, что они используют ядро от openvz, а они от RH. Почти, что игла.

Сейчас на сайте openvz — proxmox ставится как bare metal решение openvz.
Only those users with full accounts are able to leave comments. Log in, please.