Comments 76
В XenServer, а так же в бесплатном варианте Xen Cloud Platform, для HVM тоже использкется Xen. Насчет пропатченного ядра тоже не совсем верно — в совремнных дистрибутивах ядра «из коробки» прекрасно себя чувствуют в PV-режиме.
Подправил. Кстати, по скорости и надежности в общем случае что будет быстрее: Xen-HVM или KVM?
К сожалению, под руками нет данных. Не буду гадать.
Тут уже скорее религиозный вопрос. Чисто
субъективно, Xen-HVM выглядит симпатичнее.
Я пробовал в себя в лаборатории RHEV3, Ubuntu
11.10 и Fedora 16 даже не смогли загрузиться в KVM,
хотя прекрасно живут в XCP. А последние пару
месяцевя я уже перешел на Ubuntu 12.04 в PV-mode.
Полет нормальный
Тут уже скорее религиозный вопрос. Чисто
субъективно, Xen-HVM выглядит симпатичнее.
Я пробовал в себя в лаборатории RHEV3, Ubuntu
11.10 и Fedora 16 даже не смогли загрузиться в KVM,
хотя прекрасно живут в XCP. А последние пару
месяцевя я уже перешел на Ubuntu 12.04 в PV-mode.
Полет нормальный
Зачем HVM, если практически всё уже давно умеет работать в PV?
> Ядро обновлено до 2.6.32
Ядро 2.6.32 используется давно и оставлено в новой версии потому-что, как говорят разработчики, «очень надёжное».
> Разработчики подчеркивают высокую скорость работы (полный AJAX)
На счёт высокой скорости я бы поспорил, старый интерфейс быстрее. Но новый функциональнее и удобнее.
> Использование Proxmox наиболее актуально для тех пользователей, которые не хотят или не могут лезть в дебри OpenVZ и KVM. Система позиционируется как готовая к использованию. И реально так и есть. Отлично подойдет для начинающих.
Proxmox VE не позиционирует себя как «для тех, кто хочет попроще» или «для начинающих». Сегодня Proxmox VE становится реальной альтернативой VMware.
> Добавлю, что в основе Proxmox лежит виртуализация на базе контейнеров Linux OpenVZ.
Разработчики не ставят приоритеты именно на OpenVZ. Для версий 1.x существовали ядра и вовсе без поддержки OpenVZ, а только с KVM.
Ядро 2.6.32 используется давно и оставлено в новой версии потому-что, как говорят разработчики, «очень надёжное».
> Разработчики подчеркивают высокую скорость работы (полный AJAX)
На счёт высокой скорости я бы поспорил, старый интерфейс быстрее. Но новый функциональнее и удобнее.
> Использование Proxmox наиболее актуально для тех пользователей, которые не хотят или не могут лезть в дебри OpenVZ и KVM. Система позиционируется как готовая к использованию. И реально так и есть. Отлично подойдет для начинающих.
Proxmox VE не позиционирует себя как «для тех, кто хочет попроще» или «для начинающих». Сегодня Proxmox VE становится реальной альтернативой VMware.
> Добавлю, что в основе Proxmox лежит виртуализация на базе контейнеров Linux OpenVZ.
Разработчики не ставят приоритеты именно на OpenVZ. Для версий 1.x существовали ядра и вовсе без поддержки OpenVZ, а только с KVM.
В новой версии также появились возможности для создания отказоустойчивого кластера.Кластер был и в первой ветке, не было multi-master.
HA в первой ветке не было.
HA = High Availability
Было-было.
pve.proxmox.com/wiki/Roadmap#Proxmox_VE_2.0
…
…
High Availability Cluster support for KVM guests and OpenVZ containers
resource agents for KVM and OpenVZ
GUI for managing KVM and OpenVZ HA settings
…
На mdadm оно так и не научилось ставиться?
Думаю что не научится. Можно сделать вручную, но не рекомендуется.
Ставьте дебиан, делайте любой конфиг, накатывайте поверх проксмокс и вуаля.
Разработчики четко против такого. Если не ошибаюсь, были моменты в работе LVM со снапшотами поверх md.
Да и по-чести, если Вы делаете надежный сервер виртуализации, зачем его собирать на совсем уже бросовом железе? Если же хочется дешево и сердито, не парьтесь по зеркало.
Да и по-чести, если Вы делаете надежный сервер виртуализации, зачем его собирать на совсем уже бросовом железе? Если же хочется дешево и сердито, не парьтесь по зеркало.
Всё нормально, у меня оно на аппаратном рейде с BBU стояло. Но в силу своей бесплатности Proxmox занимает нишу «малого и среднего бизнеса», где на VmWare денег никогда не выделят, а с ручной настройкой Xen/KVM, допустим, кому-то возиться не хочется.
Так и у меня стоит на нормальных серверах :) И отлично работает, разумеется.
Я про то, что ставить сервер виртуализации поверх софтового рейда против рекомендаций разработчиков — верный путь к дальнейшим жалобам «опять разрабы что-то недокрутили». Не стоит риск завалить много машин (VM-ок) и сервер стоимости железного рейда, но до многих такая простая истина доходит только «кровью».
Я про то, что ставить сервер виртуализации поверх софтового рейда против рекомендаций разработчиков — верный путь к дальнейшим жалобам «опять разрабы что-то недокрутили». Не стоит риск завалить много машин (VM-ок) и сервер стоимости железного рейда, но до многих такая простая истина доходит только «кровью».
Разделяемые хранилища типа DAS, SAN не научились еще использовать?
Что вы имеете ввиду? По каким протоколам?
FC, SAS.
FC и SAS заявлены давно как поддерживаемые.
pve.proxmox.com/wiki/Storage_Model
Как LVM что-ли?
Как LVM что-ли?
HA требует разделяемого хранилища. И использовать их научились довольно давно.
Я не нашел как адекватно использовать dell powervalue md3200 (на борту два контроллера с 4мя SAS портами на каждом) в качестве разделяемого хранилища.
Да и про использование SAN-хранилищ я как-то информации не нашел.
Да и про использование SAN-хранилищ я как-то информации не нашел.
А о том, что без SAN не будет работать HA нашли? Есть в Wiki. Вообще надо их списком рассылки и форумом пользоваться — там очень много информации и живой разработчик отвечает на все вопросы.
Спасибо за информацию.
Если денег на VMWare не выйдет выбить — придется поискать.
Вообще я там чуть выше писал про Storage Model, эта информация уже устарела?
Если денег на VMWare не выйдет выбить — придется поискать.
Вообще я там чуть выше писал про Storage Model, эта информация уже устарела?
Кажется я понял в чем проблема.
" No need for expensive fiber channel (FC) infrastructure or the complexity of configuration of an extra storage network for iSCSI. In order get shared LVM storage you just need the optional shared LUN key.
The IMS and Proxmox VE storage model are very flexible so you can configure the disks to meet your requirement. Just a basic recommendation: Use only certified disks and only redundant raid levels, best performance with Raid10."
Разработчики считают, что SAN это iSCSI, а я, что SAN это FC.
Соотвественно, чтоб прицепить СХД по оптике, мне придется сделать это через анус (не вижу смысла в LVM, при наличии нормального хранилища).
" No need for expensive fiber channel (FC) infrastructure or the complexity of configuration of an extra storage network for iSCSI. In order get shared LVM storage you just need the optional shared LUN key.
The IMS and Proxmox VE storage model are very flexible so you can configure the disks to meet your requirement. Just a basic recommendation: Use only certified disks and only redundant raid levels, best performance with Raid10."
Разработчики считают, что SAN это iSCSI, а я, что SAN это FC.
Соотвественно, чтоб прицепить СХД по оптике, мне придется сделать это через анус (не вижу смысла в LVM, при наличии нормального хранилища).
Про LVM ответил выше. Что касается SAN — они говорят, что можно использовать iSCSI и с экономить (и многие так и делают, с Proxmox iSCSI работает очень быстро в отличии от VMware), но выбор за вами.
Кстати, SAN это не FC согласно определению: en.wikipedia.org/wiki/Storage_area_network. FC, наверное, ближе к SAS.
Собственно, разделение хранилища (в 1.х) у них было сделано именно через LVM. Что касается нормального хранилища — их форум в помощь, отвечают быстро и разумно.
За 2.х, правда, не скажу (пока только тестирую), но, уж раз мы говорим об opensource, никто не мешает попробовать, написать в их же wiki статью, и тем расширить знания сообщества.
За 2.х, правда, не скажу (пока только тестирую), но, уж раз мы говорим об opensource, никто не мешает попробовать, написать в их же wiki статью, и тем расширить знания сообщества.
Можно использовать DRBD вместо SAN, хотя SAN рекомендуется.
Можно, но страшновато. Ещё одна точка отказа, причём малопредсказуемая.
Точка отказа? Мне кажется наоборот, это ведь зеркало по сети. Представьте если SAN откажет. DRBD это тоже самое, что два SAN-а в HA-кластере.
Представьте, если DRBD откажет. Где концы искать? А он отказывает, и надо либо своими силами его поддерживать, либо латную поддержку принимать, а она стоит как SAN.
Что делать если откажет SAN?
Чаще всего в стоимость сана входит поддержка с помощью и заменами на пару лет.
Я не совсем вас понимаю.
Есть два сервера, между ними DRBD. Допустим сгорел сервер (блок питания или что там ещё), т.к. сервер на поддержке, его чинят. Тем временем DRBD работает на оставшемся сервере.
Тоже самое с саном (правда SAN всего один, поэтому пока SAN чинят работа стоит).
Если что-то происходит на урофне файловой системы, то тут поддержка не поможет, только бэкапы могут спасти.
Есть два сервера, между ними DRBD. Допустим сгорел сервер (блок питания или что там ещё), т.к. сервер на поддержке, его чинят. Тем временем DRBD работает на оставшемся сервере.
Тоже самое с саном (правда SAN всего один, поэтому пока SAN чинят работа стоит).
Если что-то происходит на урофне файловой системы, то тут поддержка не поможет, только бэкапы могут спасти.
Для понимания, что такое _простенький_ SAN.
Это два БП и два супервизора минимум + если архитектор не ****** то это два коммутатора и multipathing т.е. это полное дублирование.
Это два БП и два супервизора минимум + если архитектор не ****** то это два коммутатора и multipathing т.е. это полное дублирование.
Если откажет SAN, то у вас доле быть backup. Если точка отказа очень кретична, можно делать снэпшоты самой карзины на iscsi (можно поднять на nas, или взять linux и поднять самому). Если корзина выходит из строя по гарантии, то ее производитель меняет давольно шустро. Ну или как вариант две корзинки в зеркале =) Но как по мне это перебор уже.
Я сечас пробую glusterfs в виде nfs. Если все будет хорошо, то можно будет как временное решение, ели умерла корзинка.
Я сечас пробую glusterfs в виде nfs. Если все будет хорошо, то можно будет как временное решение, ели умерла корзинка.
Тоже самое и c DRBD, но плюс к этому в случае отказа одного из серверов 2-й можно использовать в одиночку до тех пор пока не будет восстановлен 1-й.
DRBD я сам люблю, но есть но!
1) производительность
2) кол-во подключемых машин.
Нам нужна производительность и маштабируемость + быстрые (очень быстрые насколько это возможно) резервные копии.
у на сейчас 11 машин из proxmox, к сожелению сделать это с drbd нельзя.
1) производительность
2) кол-во подключемых машин.
Нам нужна производительность и маштабируемость + быстрые (очень быстрые насколько это возможно) резервные копии.
у на сейчас 11 машин из proxmox, к сожелению сделать это с drbd нельзя.
> 1) производительность
С этим у нас проблем не было, но мы и не web-хостинг и не дата-центр.
> 2) кол-во подключаемых машин.
Разумеется DRBD в режиме мастер мастер может быть установлено только на два хоста. Каждой задаче своё решение и наоборот. Нам больше двух хостов в кластере не нужно.
С этим у нас проблем не было, но мы и не web-хостинг и не дата-центр.
> 2) кол-во подключаемых машин.
Разумеется DRBD в режиме мастер мастер может быть установлено только на два хоста. Каждой задаче своё решение и наоборот. Нам больше двух хостов в кластере не нужно.
мы то е начинали с drdb, но быстро выросли. Просто san это отличное решение, етественно надо понимать для чего оно вам нужно и как с этим работать.
Если вернутся к бэкапам, то у san с этим проблем нет.
Если вернутся к бэкапам, то у san с этим проблем нет.
У нас тоже нет проблем с бэкапом. У нас три кластера по два хоста в разных сетях. Если мы будем к каждому прикручивать SAN, то это будут неоправданные расходы в нашем случае.
Все у proxmox нормально с SAN. Если linux видет ваш FC контроллер, то все будет работать с proxmox через lvm. Мы так с ранних бет и используем в продакшене.
Что вы имеете ввиду? По каким протоколам?
HA требует еще и fencing — управляемый коммутатор питания или сети, насколько я понял. Т.е. Просто на нодах HA не построить, а жаль. Не понятно — ведь разделяемое хранилище является узким местом по надежности. Ну что может случиться с нодой ну сгорит блок питания… Та их там несколько как правило. Встанет кулер на проце… Маловероятно на том железе. Чаще всего сбои связаны с дисками. И этот узел у нас один. Да raid — но несколько нод каждая с raid ИМХО надежней.
Построить можно и без ничего, только считается, что смысла в этом нет, т.к. надёжность такого комплекса будет крайне низкой.
Если у нас серверы, набитые виртуалками, то давайте так посчитаем надёжность запуска всех виртуалок:
Представьте, что вероятность сбоя сервера либо системы хранения одинаковая. Тогда вероятность сбоя отказоустойчивого кластера равна вероятности сбоя системы хранения ну и плюс вероятность одновременного сбоя нескольких серверов (больше избыточности), которой пренебрежём. А вероятность сбоя кластера без системы хранения равна сумме вероятностей сбоев одиночного сервера. 10 одиночных серверов получается в 10 раз менее надёжны, чем 10 серверов плюс система хранения. Конечно, если мы считаем, что кластер работает если все виртуалки на нём работают. Если можно какое-то количество виртуалок потерять на большое время — то конечно одиночные сервера лучше. Если сервер с бэкапами не вылетит, конечно — а сами подумайте, tuk надёжность выше чем надёжность системы хранения?
Представьте, что вероятность сбоя сервера либо системы хранения одинаковая. Тогда вероятность сбоя отказоустойчивого кластера равна вероятности сбоя системы хранения ну и плюс вероятность одновременного сбоя нескольких серверов (больше избыточности), которой пренебрежём. А вероятность сбоя кластера без системы хранения равна сумме вероятностей сбоев одиночного сервера. 10 одиночных серверов получается в 10 раз менее надёжны, чем 10 серверов плюс система хранения. Конечно, если мы считаем, что кластер работает если все виртуалки на нём работают. Если можно какое-то количество виртуалок потерять на большое время — то конечно одиночные сервера лучше. Если сервер с бэкапами не вылетит, конечно — а сами подумайте, tuk надёжность выше чем надёжность системы хранения?
Не понятно почему вы складываете вероятности выхода из строя серверов без общей системы хранения, если сервера в HA кластере находятся врежиме горячего резерва и только один является активным. (в самом простом случае)Выход из строя резервного узла вообще к ничему не приводит — он просто увеличивает вероятность сбоя.
Извините, но я ничего не понял.
Если считать надёжность сервера и надёжность SAN одинаковыми (нормальный рейд, два БП и т.д.), то два сервера в зеркале надёжнее чем один SAN, т.к. при выходе одного из серверов за короткое время все виртуальные машины запускается на втором, т.к. диск (DRBD) у них общий с одними и теме же данными. А первый сервер тем временем восстанавливается.
Если считать надёжность сервера и надёжность SAN одинаковыми (нормальный рейд, два БП и т.д.), то два сервера в зеркале надёжнее чем один SAN, т.к. при выходе одного из серверов за короткое время все виртуальные машины запускается на втором, т.к. диск (DRBD) у них общий с одними и теме же данными. А первый сервер тем временем восстанавливается.
fencing у них сделан средствами RedHat, все что можно настроить в RedHat для HA, можно настроить и для proxmox. Например использовать ILO HP для HA proxmox.
И еще дополнение, для всего этого надо 3 машины :)
По поводу корзины, есть разные методы как сделать ее резервной.
Мы использует корзины HP Storage P2000 в зеркале + бэкапы всегда готовы включится по iscsi через nfs + запись на ленту.
И еще дополнение, для всего этого надо 3 машины :)
По поводу корзины, есть разные методы как сделать ее резервной.
Мы использует корзины HP Storage P2000 в зеркале + бэкапы всегда готовы включится по iscsi через nfs + запись на ленту.
fencing прекрасно работает на любой IPMI карте. То есть DRAC/iLO/RSA/IMM/… в каждый из серверов и все.
Sign up to leave a comment.
Наконец-то вышел Proxmox VE 2.0 final release