Pull to refresh

Comments 40

Активно юзаю, как выйдет стейбл думаю стоит обновиться. Я бы сказал так — это система для тех кому стало лень настраивать руками то что они уже умеют.
Или еще можно перефразировать так — те, кто что то не умеют, могут подсмотреть как это реализованно в Proxmox )
Печально, что Proxmox заточен под Debian. Мне больше нравится CentOS. Но, не критично.
В любом случае он ставится сразу на железо, так же как и ESXi, т.е. предустанавливать Debian не нужно.
Он не «заточен», он и есть «Debian + нужные компоненты, неплохо настроенные „из коробки“».

В этом смысле особых заморочек даже для самых Centos-админов нет, оно просто работает. Его же все равно нужно ставить на голое железо, а 2-3 команды конфигурации (того, что из веб-интрфейса не сделаешь) и в wiki самого Proxmox-а можно подглядеть.

С другой стороны, здесь «не обычного» — только веб-интерфейс + скрипты управления, а остальное (тот же KVM) вовсе не Debian-specific.
Есть мнение что выбор ядра 2.6.32 не очень верен.
KVM очень сильно улучшили IO подсистему в 2.6.35. Не забываем и про ksm.
Так же есть мнение что для таких решений больше подходят ядра от redhat.
giner расскажите о самой работе. Поделитесь опытом.

Используем Proxmox где-то с версии 1.3 или 1.4. Имеется два хоста, между ними DRBD (т.е. обходимся без внешнего хранилища). В ранних версиях Proxmox были проблемы с онлайн-миграцией Windows-гостей. В последних версиях этих проблем не наблюдалось. В нашем кластере работает подядка 20-ти виртуальных машин. Работает всё стабильно и очень шустро (и сами KVM-гости (особенно при использовании virtio), и DRBD, и iSCSI (тестировал)). Так же очень резв web-интерфейс и гостевая консоль (особенно в сравнении с VMware Client).

Что касается интерфейса, то для наглядности вот ссылка на видео-туториалы: http://pve.proxmox.com/wiki/Category:Video_Tutorials
Вот если бы, уважаемый, Вы бы пару слов про настройку DRBD еще добавили… Лучше бы вообще постом, но хотя бы здесь.

Я строил кластер на 2 хоста, делал DRBD, миграция и все остальные прелести работали отлично, и так бы и оставил, если бы не одно «но»: медленная синхронизация DRBD (и, в результате, работа дисков в самих ВМ).

Разработчики, что понравилось, ответили честно — «не так много людей в мире точно знают, как DRBD настроить, так что пробуйте, может и достигнете лучшей скорости».

В результате разбил схему на 2 независимых хоста, потерял live migration, но приобрел уверенность, что знаю, что происходит. Кластер ветки 1.х нес еще ту проблему, что при умирании мастера управлять машинами становилось невозможно, без насильственных действий в отношении самого кластера, так что счел за благо дождаться 2.х.
Сеть между серверами 1Gbit/s, скорость для DRBD ограничена лимитом в 30MB/s. Проблем с скоростью не было. Может у вас есть ещё какие-то специфические условия, нагруженный файл сервер, например?
У меня для теста было пару машин с двумя винтами в каждом, на первом винте Proxmox, вторый винты в DRBD и поверх него в LVM сами виртуалки.

Нагрузка — плевая. Несколько юниксовых машинок, по больше части даже не напрягающих диски. Но когда я извне по ssh или по ftp на внутр. машину копирую файл, а скорость записи — 5 Мб/сек, начинаешь переживать. Та же картина при копировании файлов внутри ВМ. Процессорной мощности и памяти в самих хостах хватало, и они не были выедены полностью.

Грешил на то, что диск был всего 1 под DRBD выделен, но пары аппаратных RAID10 у меня не нашлось…
У вас сеть между ними была не 100Mbit/s?
Нет, точно нет )

Работала выделенная для этих целей пара гигабитных сетевушек, не сильно крутых, правда. Т.е. в каждой машине по гигабитному порту, и между ними линк кабелем 6 категории.
В таком случае это необычное поведение. Нужно мониторить во что именно упирается скорость. При использовании DRBD с подобным не сталкивался.
Можно тоже вопрос по DRBD? Он у вас стабильно себя ведет? Бывают ли сбои?

С год назад пробовал виртуалки KVM с дисками на DRBD (на 2х серверах, без внешнего хранилища). Вроде все хорошо работало. Даже подумывал howto сюда написать :-) Но спросил на serverfault, использует ли кто-нибудь в production. Откликнулись всего пара человек. Один из них рассказал, что в один прекрасный день drbd ему превратил данные в кашу… После этого рассказа, полез в интернет и нашел еще пару историй-страшилок про DRBD. После этого решил отложить все это дело в долгий ящик. Вот все думаю, может зря…
> Один из них рассказал, что в один прекрасный день drbd ему превратил данные в кашу…
Зависит от обстоятельств при которых это произошло. Может он попытался использовать прямой доступ к диску или не кластерную FS и всё рассыпалось. В любом случае, будь то RAID, DRBD или что-то ещё — всё это не освобождает от бэкапов.

> Можно тоже вопрос по DRBD? Он у вас стабильно себя ведет? Бывают ли сбои?
У нас за год не было ни одного сбоя. Всё стабильно. При этом сервера пережили несколько обновлений между релизами Proxmox, когда виртуальные машины перемещаются на один хост, второй обновляется, перезагружается и потом второй так же.
>Нагрузка — плевая. Несколько юниксовых машинок, по больше части даже не
>напрягающих диски. Но когда я извне по ssh или по ftp на внутр. машину
>копирую файл, а скорость записи — 5 Мб/сек, начинаешь переживать. Та же
>картина при копировании файлов внутри ВМ. Процессорной мощности и
>памяти в самих хостах хватало, и они не были выедены полностью.

5 Мб/сек — какая-то знакомая цифра. У меня то же самое получилось, когда я копровал файлы внутри виртуальных машин, лежащих на softraid разделе. Сами образы виртуалок копировались с нормальной скоростью при этом. Что-то у проксмокса, похоже, внутри не любит промежуточного слоя к дискам. Может быть они поэтому и так рьяно против софтрейда восстают.
Возможно это оверхед SFTP?
> Есть мнение что выбор ядра 2.6.32 не очень верен.
2.6.32 выбрано как LTS, а некоторые полезности, такие как KSM и новые версии KVM, они добавляют патчами.
Да там ядра устанавливать просто. Потом grub редактируем и выбираем нужное.
Если нужен только kvm без openvz, то можно подняться до 2.6.35
Верно, но рекомендуется: «The 2.6.35 was introduced to support KSM. As KSM works now also with the default 2.6.32, this kernel branch will get no more updates, all users should switch to 2.6.32. „
недавно дописали, раньше не было. :)
> для таких решений больше подходят ядра от redhat
вот и я о чем
Сам упомянул, сам и отвечу.
Kernel 2.6.32 (recommended) — based on RHEL6x
Жаль, пока не могу затестить, но есть вопросы к тем кто попробовал.
Реализован ли многопользовательский режим? Вроде как обещали.
Стабильность 64 битных Windows гостей? Раньше при выделении больших ресурсов постоянный BSOD был.
Каковы общие впечатления?
> Реализован ли многопользовательский режим? Вроде как обещали.
Реализован, но пока не тестировал.
> Стабильность 64 битных Windows гостей? Раньше при выделении больших ресурсов постоянный BSOD был.
На форуме об этой проблеме писали?
> Каковы общие впечатления?
Интерфейс медленнее чем в 1.x, т.к. теперь он весь на JS. С другой стороны он стал намного богаче, появились графики загрузки и т.п. Некоторые фичи пока не реализованы, поэтому в продакшн пока не годится.
Ну это вседозволенности бетка) на продакшене ей не место )
>> Стабильность 64 битных Windows гостей? Раньше при выделении больших ресурсов постоянный BSOD был.
> На форуме об этой проблеме писали?

Да, писали и не только мы. Вот одна из тем forum.proxmox.com/archive/index.php/t-5317.html?s=3553954f01702c4378597ad8a56ff58f
Интерфейс похож с виртуоззой.
Эх, нету у меня свободной железки. Так бы с удовольствием затестил.
Сейчас в продакжене работает версия 1.х — полет отличный.
UFO landed and left these words here
Напрямую с KVM не работал (только через proxmox), поэтому вопрос: там можно менять bridge на другой во время работы VM (аналог физического втыкания сетевого кабеля в другую сеть)?
Скорее всего в консоли KVM это можно сделать, но нужно проверять.
Тогда было бы здорово, если бы в версии 2.0 можно было менять bridge через web-interface.
По крайней мере у VmWare ESXi такая возможность есть.
Уже бета 2 вышла. А обзора — нет! Выше перечисленные недочеты устранены. ушел тестить!
Only those users with full accounts are able to leave comments. Log in, please.