Вы не объективны, т.к. вы не работали с Xen.
Я не предвзят т.к. в одинаковом количестве содержу и XEN и OVZ ноды, также есть LXC для работы внутренних систем. но это другая история.
У кого-то есть желание тестить баги на живых клиентах?
XEN 4.1 работает как часы.
XEN 4.2 также на тестовом проблем не показывает, но на продакт пока не ставим.
Частые обновления ядра на ноде — зло.
Конечно если вам не жалко свои нервы и своих клиентов… Кактус вас ждет…
Номер бага искать лень.
Помню что открывали ребята из fastvps.
Я не делаю никаких перекрестных mount.
openvz делает не полный umount при остановке.
И «доделать» его нельзя.
Только перезапуск ноды.
Для чего делать еще один rsync?
Чтобы еще замедлить миграцию?
Остановка на время сравнение rsync-ом никуда не денется.
Для XEN:
mount -o ro…
rsync
rsync
save
scp
restore
Да чего там, давайте тогда уж сразу патчи OVZ на ядро править.
Зачем оно надо когда есть стабильные технологии?
Дедлоки на mount кстати уже больше года в багтрекере висят.
Пока глухо.
Все же в OpenVZ не полноценный Live Migration, там просто холодная и горячая виртуализация.
При чем вовремя горячей синхронизации виртуалка ставится на паузу пока rsync засинхронизируется.
А на большом количестве файлов это может занимать минуты.
А ведь еще ОЗУ надо перекинуть, что тоже время.
Можно с таким же успехом мигрировать XEN виртуалки в несколько проходов.
Никакого отличия.
Я вам скажу как админ более 1к VPS на OpenVZ.
Если бы не желание клиентов такой гадости на наших серверов бы не было.
Вечные глюки с checkpoint, с остановкой квот и хардлоками.
Огромный оверхед на клиентских квотах.
В общем — ну нафиг, лучше мы будем иметь меньшую маржу, но будем давать клиентам безглючную услугу на XEN.
Главное чтобы клиенты это поняли и не нужно пытаться их переубеждать что «говно не так плохо пахнет».
Это уже не ДГУ, а электростанции и практически никто не делает их на дизелях.
Сколько пересмотрел ДГУ различных фирм и расценок, везде описано что для непрерывной работы необходим резервная установка, которая может принять нагрузку.
Можно конечно гонять генераторы круглосуточно, но положительно это на них не скажется.
В любом случае в Tier3 ДЦ уже ставят 2 ДГУ с общим хранилищем соляры, с синхронизаторами и автоматикой для переключения нагрузки между ними.
Хочу заметить что у ДГУ также есть максимальное время непрерывной работы.
Обычно это не более 24 часов, после чего начинается износ.
По крайней мере так декларируют производители ДГУ.
Понятное дело что никто не отменял резервные ДГУ.
Также подтверждаю что никогда со Спамхаузом проблем не возникало.
При том что у нас уже почти 16-я сеть в общей сложности насобиралась.
Если возникает прецедент, он решается в течении часа-дня по одному запросу.
Ответ всегда один:
Hello,
Thanks for your effort.
We have removed the SBL record.
1. С каких пор на стабильность софта влияет лицензия? Речь о проблемах с ZoL;
2. Это я уже все видел, и за пределы рунета ходил, ни одной success story в enterprise там нет.
Мои же тесты давали kernel panic на больших нагрузках при работе с iSCSI.
Возможно за пару месяцев много воды утекло, но с учетом скорости разработки сомневаюсь что там со временем баги прибывают медленнее чем правятся.
Я не предвзят т.к. в одинаковом количестве содержу и XEN и OVZ ноды, также есть LXC для работы внутренних систем. но это другая история.
XEN 4.1 работает как часы.
XEN 4.2 также на тестовом проблем не показывает, но на продакт пока не ставим.
Частые обновления ядра на ноде — зло.
Конечно если вам не жалко свои нервы и своих клиентов… Кактус вас ждет…
Блокирующие процессы не убиваются.
Проблема ядерная.
Так что мимо кассы вы.
Уже года 2 не видел.
Помню что открывали ребята из fastvps.
Я не делаю никаких перекрестных mount.
openvz делает не полный umount при остановке.
И «доделать» его нельзя.
Только перезапуск ноды.
Чтобы еще замедлить миграцию?
Остановка на время сравнение rsync-ом никуда не денется.
Для XEN:
mount -o ro…
rsync
rsync
save
scp
restore
В общем тоже что на OVZ, только плюс mount.
Зачем оно надо когда есть стабильные технологии?
Дедлоки на mount кстати уже больше года в багтрекере висят.
Пока глухо.
А то уже 5 лет с ним работаю и неисправимого конфигом глюка не видел.
При чем вовремя горячей синхронизации виртуалка ставится на паузу пока rsync засинхронизируется.
А на большом количестве файлов это может занимать минуты.
А ведь еще ОЗУ надо перекинуть, что тоже время.
Можно с таким же успехом мигрировать XEN виртуалки в несколько проходов.
Никакого отличия.
Если бы не желание клиентов такой гадости на наших серверов бы не было.
Вечные глюки с checkpoint, с остановкой квот и хардлоками.
Огромный оверхед на клиентских квотах.
В общем — ну нафиг, лучше мы будем иметь меньшую маржу, но будем давать клиентам безглючную услугу на XEN.
Главное чтобы клиенты это поняли и не нужно пытаться их переубеждать что «говно не так плохо пахнет».
Ниже дали ссылку на 3D FPS в браузере.
Даже с мультиплеером.
Сколько пересмотрел ДГУ различных фирм и расценок, везде описано что для непрерывной работы необходим резервная установка, которая может принять нагрузку.
Можно конечно гонять генераторы круглосуточно, но положительно это на них не скажется.
В любом случае в Tier3 ДЦ уже ставят 2 ДГУ с общим хранилищем соляры, с синхронизаторами и автоматикой для переключения нагрузки между ними.
Обычно это не более 24 часов, после чего начинается износ.
По крайней мере так декларируют производители ДГУ.
Понятное дело что никто не отменял резервные ДГУ.
Коварный замысел раскрыт. )))
Даже сажать никуда не надо, не сбежишь.
При том что у нас уже почти 16-я сеть в общей сложности насобиралась.
Если возникает прецедент, он решается в течении часа-дня по одному запросу.
Ответ всегда один:
Hello,
Thanks for your effort.
We have removed the SBL record.
Our mirrors will update within the hour.
2. Это я уже все видел, и за пределы рунета ходил, ни одной success story в enterprise там нет.
Мои же тесты давали kernel panic на больших нагрузках при работе с iSCSI.
Возможно за пару месяцев много воды утекло, но с учетом скорости разработки сомневаюсь что там со временем баги прибывают медленнее чем правятся.
Нет ли у вас статистики по реальному использованию этих фишек клиентами частных и публичных облаков?