ovirt vs proxmox vs openstack

ты прикалываешься?xen ещё больше грузит дисковую систему чем kvm.

112k - это в баксах сколько?

Подробнее пожалуйста

Ты NAS от SAN отличаешь?

Ну так ставь KVM, в чем проблема?

Нет нужно отличать паравиртуализацию (Xen PV) от полной (HVM).

а что тут расписывать? снепшоты в LVM не рассчитаны на долгоиграние. Тем более когда их много. Их вообще изначально запилили ради возможности сделать бекап (оттого и возможность сделать всего один снепшот а не цепочку). Когда мы разрабатывали концепцию блочного стореджа под rhev мы LVM перелопатили, и снепшоты особенно, и остановились на использовании отдельных LV в роли снепшотов, с линкованием через qcow, а не родного LVM-ного функционала. Просто потому что он не адекватен для такого юз-кейса

Когда мы разрабатывали концепцию блочного стореджа под rhev

Зачем?

мы LVM перелопатили, и снепшоты особенно, и остановились на использовании отдельных LV в роли снепшотов, с линкованием через qcow

Зачем?

Вот что «свободные» лицензии CDDL и GNU GPL с людьми делают. Это такая свобода - когда живые позавидуют мёртвым.

Если б ты знал чем он занимается, ты б не задавал таких вопросов

Если б ты знал чем он занимается, ты б не задавал таких вопросов

Если б ты знал чем я занимаюсь, ты б не давал таких ответов.

Зачем?

в каком смысле «зачем»? нужно было сделать систему для хранения дисков виртуальных машин на блочном хранилище (изначально поддерживался только NFS), a обычные кластерные FS ограничены, сложны и не подходят.

Зачем?

а какие еще есть варианты? писать свой volume manager, когда есть готовый, убив на это пару лет?

Вот что «свободные» лицензии CDDL и GNU GPL с людьми делают. Это такая свобода - когда живые позавидуют мёртвым.

дада, только вот масштабируется RHEV за счет LVM на порядок лучше vsphere.

я ничем не занимаюсь, пишу себе юнит тесты и лор читаю, предновогодний расслабон

Велосипедостроителям пламенный привет и с Новым Годом.

очень дельный ответ, сразу виден суровый профессионал.

Взаимно. Где я могу ознакомится с продуктом Вашей жизнедеятельности?

мы LVM перелопатили, и снепшоты особенно, и остановились на использовании отдельных LV в роли снепшотов, с линкованием через qcow, а не родного LVM-ного функционала

Четвертый раз читаю, и четвертый раз парсер ломается.

redhat.com например, или ovirt.org.

только на ваш сарказм я задал несколько простых вопросов, ответы на которые вы так и не соизволили привести. пока этого не случится, вы уж извините, но серьезно к вам относиться я не буду.

я задал несколько простых вопросов

Будьте любезны, повторить Ваши вопросы, я их не разглядел.

redhat.com например, или ovirt.org.

Мои работы также, например, свободно лежат на http://www.freebsd.org/. Welcome.

первая мысль была простая - LVM умеет снепшоты, будем пользоваться. оказалось ни фига эти снапшоты не годятся для построения цепочек с возможностью отката. поэтому сделали иначе: обычные файлы qcow2 в цепочке снепшотов можешь себе представить? мы просто сделали то же самое, но вместо файлов - LV. сложнее было сделать sparse LV до того как LVM научился делать это сам, но и это было сделано.

в каком смысле «зачем»? нужно было сделать систему для хранения дисков виртуальных машин на блочном хранилище (изначально поддерживался только NFS), a обычные кластерные FS ограничены, сложны и не подходят.

а какие еще есть варианты? писать свой volume manager, когда есть готовый, убив на это пару лет?

раз уж мы тут все такие любезные

обычные файлы qcow2 в цепочке снепшотов можешь себе представить? мы просто сделали то же самое, но вместо файлов - LV. сложнее было сделать sparse LV до того как LVM научился делать это сам, но и это было сделано.

Вы не бредите, случайно?

Вы не бредите, случайно?

опять очень профессионально и по существу. поздравляю

нужно было сделать систему для хранения дисков виртуальных машин на блочном хранилище (изначально поддерживался только NFS)

Это где такая беда случилась и почему?

оригинальная система, предшественник RHEV, называлась SolidICE. тогда (в 2006ом) они не хотели заморачиваться с SAN, важнее было довести KVM как таковой до рабочего состояния. Когда их (стартап qumranet) купил red hat им поставили задачу добавить поддержку FC и iSCSI.

обычные файлы qcow2 в цепочке снепшотов можешь себе представить? мы просто сделали то же самое, но вместо файлов - LV.

Представить могу. Могу даже представить «основной» qcow2 на LV. Я просто не понимаю профита от использования LVM в таком режиме - это значительно быстрее, чем обычные файлы, или что? На первый взгляд напоминает СУБД 20-летней давности - те тоже любили «сырые» разделы.

оригинальная система, предшественник RHEV, называлась SolidICE

ОК

они не хотели заморачиваться с SAN, важнее было довести KVM как таковой до рабочего состояния.

Снова не возражаю.

им поставили задачу добавить поддержку FC и iSCSI.

Я не знаю что такое FC, но вероятно что то очень важное для RH. А какая связь между гипервизором и стораджем? «Добавление поддержки» это, в данном случае, как «распил бабла», не?

во первых сырые разделы немного быстрее чем ФС. Но это мелочь конечно же. основной профит тут от работы в кластере - используя LVM не нужно поднимать кластерную ФС, кворумы, scsi-3 и прочую гадость которая очень сильно ограничивает количество хостов в кластере. Для сравнения, vmfs позволяет 32 хоста (емнип), при этом, из-за scsi-3 локов, есть серьезные тормоза при изменении метадаты более чем 8 файлов одновременно. в овирте кластер ограничен на 200 хостов, и ограничение мы выставили просто потому что на тот момент у нас в QA не было больше свободного железа, а писать что мы поддеживаем не проверенное число не хотелось. Когда овирт перейдет с SPM на SDM, это число скорее всего увеличится на 1-2 порядка.

Я не знаю что такое FC

fibre channel. если вы и этого не знаете, то нам на самом деле не о чем говорить.

А какая связь между гипервизором и стораджем?

это такая попытка меня потроллить?

«Добавление поддержки» это, в данном случае, как «распил бабла», не?

не.

Сырые разделы немного быстрее чем ФС

Какая конкретно ФС?

любая.

fibre channel. если вы и этого не знаете, то нам на самом деле не о чем говорить.

Давайте без лишних понтов, Вас это не делает умнее, а окружающие могут подумать и того хуже.

Это не так.

Давайте без лишних понтов, Вас это не делает умнее, а окружающие могут подумать и того хуже.

никаких понтов, это просто констатация факта.

сколько шагов надо произвести чтоб написать один блок в образ VM в файле, по сравнению с тем же образом на LV?

По существу есть что сказать?

сколько шагов надо произвести чтоб написать один блок в образ VM в файле, по сравнению с тем же образом на LV?

Это уж точно не тема для форума, слишком много аргументов за и против. Но, вкратце - FS на ZVOL может показать производительсность на порядок большую, чем та же FS на классическом блочном устройстве типа lv (lvm).

А какая связь между гипервизором и стораджем?

Не тупи.

только после вас. вопросы мои так и остались без ответов.

FS на ZVOL будет безбожно тормозить без кучи памяти, процессоров и SSD для ZIL. при всех тех же ресурсах, скорость доступа к блоку все равно будет быстрее. а кэшировать можно не только zfs

основной профит тут от работы в кластере - используя LVM не нужно поднимать кластерную ФС, кворумы, scsi-3 и прочую гадость

Т.е. поскольку для qcow2 ФС особо и не нужна, давайте обойдемся без нее, заодно и облегчим себе жизнь в SAN... логично.

Кстати, а основной файл qcow2 можно поместить в LV? Гугл говорит, что вроде можно - это так?

FS на ZVOL будет безбожно тормозить без кучи памяти

16-32 Гб под ФС это куча? Red Hat тоже так считает?

процессоров

Если вы имеете ввиду сжатие, то при скорости любых современных НЖМД загрузка процессора уверенно стремится к нулю.

а кэшировать можно не только zfs

Научите кэшировать LVM штатными средствами в отрыве от ФС.

Кстати, а основной файл qcow2 можно поместить в LV? Гугл говорит, что вроде можно - это так?

основной это какой? базовый, т.е. корень цепочки снепшотов? конечно можно.

тестировщик работу закончил, shutdown сделал системе

За такое программеры будут бить очень сильно. Делаются снэпшоты на работающей машины до появления баги и после. Никаких shutdown.

Тестировщики никогда много не получали

4.2

16-32 Гб под ФС это куча? Red Hat тоже так считает?

если я могу добиться того же с 4гб, то да, это куча.

Научите кэшировать LVM штатными средствами в отрыве от ФС.

http://man7.org/linux/man-pages/man7/lvmcache.7.html

Почитай про тестировщиков в его конторе, я именно о таких

любых людей надо обучать и давать стимвул к обучению, а когда им платят 25, и ещё говорят о сокращении з\п до 20 из-за того, что у компании нет денег, то о чём говорить? Хотя мы хотя бы пока не закрываемся, сотни контор в питере закрываются сейчас.

что надо готовить в fedora с lvm, чтобы динамический lvm из анаконды так работал? Я просто 2 раза пробовал в прошлом году ставить систему на 0 рейд и динамический lvm(анаконда прекрасный в этом плане инструмент, жаль blivet gui ещё rhel не допилили). Система реально хуже работает нежели с btrfs, самба у меня вообще lvm терпеть не могла, у меня сначала был 10 рейд(опять же средствами анаконды) и поверх него динамический lvm, когда больше 100 баб подключались за файлом, этот файл мог в лёгкую стать недоступным даже, либо скачивание на 2-3 кб переходило, хотя самба шара у меня была на гбитной сетевухе и нормальной 6а категорией кабеля. После перевода на btrfs эта проблема решилась сама собой.

во многих компаниях всего 16-32 гб оперативы у сервера, им увы точно 4 гб куда выгоднее.

Что ты от него хочешь услышать? Он год юзает zfs и считает ее панацеей от всех бед. И любое дисковое хранилище == zfs, а кто не согласен тот лох и фанат свободных лицензий в плохом смысле этого слова.