Я у тебя спросил, в чем проблема с овиртом. Ты ответить не смог. Из чего я делаю вывод, что ответить тебе нечего и про ненормальность ты ляпнул просто так.

Люминос пока RC, кракен не лтс, лучше jewel использовать.

Да это понятно, просто интересно было Bluestore попробовать, а pveceph только с luminous поддерживает.

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

Меня мало интересует твоя мотивация. По факту ты пернул в лужу, а что ты там забыл, соврал или придумал - никому не интересно.

Меня мало интересует твоя мотивация.

«Три дня я бежала за вами, чтобы сказать, как вы мне безразличны».

А это то чего так не хватало все это время. Я, по сути, вручную делаю то-же самое уже несколько лет. И из-за отсутствия такой интеграции с zfs не мог перейти на Proxmox.

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

А с другой стороны без 10Gbe ethernet и других дорогих интерфейсов, мы можем получить топовую производительность на серверах начального уровня, т.к. будут использоваться только локальные диски.

А что за тонкий lvm который не убивает производительность снэпшотами? И почему он перестал убивать производительность?

почитай Thin Provisioning и его отличия от обычного тома и снепшота lvm

Банить за то что он запускает ванильный qemu c аргументами без огромного куска говна под названием libvirt? Нормально так редхат подмял разработку.

Минимальный шаг репликации - 1 мин. Разве этого не достаточно?

Минимальный шаг репликации - 1 мин. Разве этого не достаточно?

Это может быть как достаточно так и нет, в зависимости от конкретной системы.

Терминальник с кучкой 1С-ок, которые ни с чем не взаимодествуют можно и раз в час реплицировать. Контроллер домена Active Directory устойчив к откату на небольшое время назад - тоже раз в час.

Если в раз в год произойдет что-то, что потребует отката назад для нештатного перезапуска на другой ноде - ничего страшного.

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

В качестве примера та-же 1с-ка взаимодействующая с сайтом, на котором идут продажи.

В последнем случае поможет только ceph, drdb и другие кластерные файловые системы. Но это значительно медленнее или дороже.

Отлично.

А синхронную, наверное, дураки придумали?

ceph, drdb и другие

Лучшее из протестированного - vmware metro storage cluster на базе синхронной репликации дисковых массивов, как по производительности, так и по надёжности. Из оверхедов, по большому счёту только задержки на round-trip пакета, да и они становятся заметны при расстоянии между датацентрами хотя бы 5км. Кстате, drbd не файловая система.

Вопрос по лицензированию: То есть если код бесплатный и открытый, а оплачиваются только обновления и поддержка, то получается, что можно от выпуска к выпуску просто самому обновлять или накатывать с нуля (с сохранением конфигов старой версии) новый выпуск Proxmox и ничего не платить?

Установка в любом случае идёт из их бесплатного репозитория. Но написано, что он не рекомендуется для использования в продакшне.

Можно и в рамках выпуска обновлять. Пакеты проходят три стадии: всем доступная ветка pvetest, всем доступная pve-no-subscription, доступная по подписке pve-enterprise. Вторая ветка пригодна для мелкого энтерпрайза, просто там ничего никто не гарантирует. Впрочем, ничего и не ломают.

Ceph - это гуд!

Не стали использовать проксмокс только из-за того, что сефу минимально надо 10Гбит локальную сетку, а кластер под виртуалки в наличии только с гигабитными портами без возможности апргрейда.

прокс уже обязывает ceph ставить, поэтому вы не стали его использовать ?
не в проксе ceph летает на гигабитной сети ?

Не стали использовать проксмокс только из-за того, что сефу минимально надо 10Гбит локальную сетку...

По той-же самой причине отказался от кластерных хранилищ.

Для большинства задач достаточно отложной репликации. А Ceph, и, как я думаю, другие распределенные хранилки, на обычном гигабите работают очень плохо.

А ещё отложенную репликацию можно делать даже через Интернет, и таки образом одновременно получить катострофоустойчивость.

логично, что под каждую задачу удобен определённый инструмент, да ?

... не в проксе ceph летает на гигабитной сети ?

Нет, не обязывает и не летает. Но без него как обеспечить отказоустойчивость? Она, как правило, нужна хоть в каком-то виде.

DRDB обладает в точности теми-же недостатками. Либо его надо перевести в режим отложенной репликации, либо будет тупить на гигабите.

прокс уже обязывает ceph ставить, поэтому вы не стали его использовать ?

не обязывает, просто без живой миграции между нодами он нам был не интересен

не в проксе ceph летает на гигабитной сети ?

о чем ты вообще? ceph-у нужно 10Гбит не зависимо от проксмокса

о чем ты вообще?

Не стали использовать проксмокс только из-за того ..

мы не стали использовать proxmox, потому что живая миграция виртуалок между хост-системами работает только через ceph, который не будет работать на 1Гбит сетке, чего тут не понятного?

По iscsi должна работать живая миграция, возможно по nfs тоже.

Попробовал subj.

Репликация запускается. Чтобы она работала, пул должен называться одинаково на обоих нодах. Настроить что именно куда и как часто мы хотим реплицировать нельзя. В том смысле, что интервал действует на всю машину сразу.

Сначала система, как и ожидалось, создаёт снимок на источники и пытается скопировать его на пункт назначения. Если получилось, попытается ещё раз, через назначенный интервал времени. После передачи снимки удаляются, настроить это поведение нельзя.

Если передача не удалась в первый раз, процесс останавливается и не возобновляется. У меня из-за высокой нагрузки она была прервана по тамауту и всё на этом закончилось.

Передает через zfs send / receive over ssh

Снимки создаются и видны в zfs list -t snap как снимки zfs. Есть опция создания снимка с дампом состояния памяти.

Снимки реплицируются тоже, при включенной репликации и даже удаляются при удаленни их с источника.

Миграция не работает. Как использовать реплицированное состояние не понятно.

Работа в целом.

Единственная виртуалка зависла через 15 минут после старта., в процессе инсталяции ubuntu desktop. Пробовал перезапустить раз 5. Примерно в одно и тоже время, вне зависимости от процесса установки зависает. Можно просто подождать минут 15 и она зависнет.

Команда может сработать, может не сработать. Возникает общее ощущение глючности и не стабильности.

Кратко, я лучше и дальше ручками.

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

Только VMWARE нормально работала, но я её не использую, ещё хорошо работает libvirt. Все что выше по уровню абстракции, почему-то работает через задницу.

Но я себе репликацию zfs не представляю без тесной интеграции с резервным копированием аля «машина времени».

Я бы хотел видеть систему, которая за чет кластерного хранилища типа zookeeper или corosync знала бы где у нее какие виртаульные машины работают. Как расположены их диски по zfs-пулам. Понимает концепцию сайтов. Понимает, что виртуальная машина может использовать том через iscsi или nfs с другой ноды, но там он тоже хранится на zfs.

Нужно, чтобы система могла создавать распределенные консистентные снимки. Я имею в виду ситуацию когда нужно создать снимок и на локальной хосте, например в локлаьном ssd-пуле для баз данных и на соседнем, где мы расположили большой дисковый массив zfs для холодных и больших файлов.

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

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

В точке назначение, возможно, потребуется иметь глубину архива год или более. И скорее всего, там будет специально настроенное хранилище с дедупликацией, RAID6 и ssd-кешем под метаданные и таблицу дедупликации.

Отдельная подсистема должна иметь представление о том, что делать в случае аварии одного их хостов:

- ждать решения оператора, который может восстановить машину из архива на один из работающих хостов;

- автоматически запускать предварительно реплицированное состояние;

- восстанавливать состояние из архива;

Нужна филигранная работа со снимками. Представьте себе ситуацию, когда на хосте крутится виртуалка с базой банных под 100ГБ (в ssd-пуле) и файловым архивом 2-3ТБ (на другом, емком, но не таком быстром пуле). Она реплицируется на удаленную площадку, где есть большое хранилище. Самое хорошее решение - клонировать один из снимков, запустить копию этой вирталки из этого снимка и, таки образом получить данные.

Если же хост упал, то мы поднимим гигантскую виртуалку на удаленной площадке за счет предварительно реплицированного состояния.

Но что делать, когда придет время вернуть машину на место? Если данные на старом хосте уцелели, то можно опираясть на них передать разницу с удалённой площадки и не копировать теробайты между дата-цетрами.

Вот этого всего нет.

надстройкой над QEMU и LXC

В смысле KVM? Вряд-ли тем, кто пользуется именно qemu нужны надстройки.

Кстати, как оно по сравнению с oVirt?

По iscsi должна работать живая миграция, возможно по nfs тоже.

Точно работает, проверено.