Партнёрская поддержка OpenVZ

Интересная идея, я считаю

Круто, надеюсь если опыт будет положительным он перейдет к другим программным пакетам, а то сейчас либо: «Это опенсорс детка, пиши сам, или жертвуй на проект» либо «Ой мы не будем брать деньги за эти фичи, даже оценивать их стоимость не будем и на кикстартере компанию заводить не будет ибо кодим мы в свободное время» - KiCAD.

Идея классная, но openvz это не спасет.

Что есть лучше чем OpenVZ? Другие позволяют такую же эффективную паравиртуализацию? Я сталкивался с OpenVZ как клиент хостинга, вполне неплохо. А KVM тоже позволяет память и общие системные файлы расшаривать между машинами?

А KVM тоже позволяет память и общие системные файлы расшаривать между машинами?

Сиво-сиво? :)) расшаривать память? :)

Раз не понял или видишь что не так выразился - прибереги смайлики. Вопрос иначе: KVM или другие системы виртуализации позволяют добиться того же уровня экономии памяти как у OpenVZ?

Уточню что не супер-специалист в OpenVZ, просто мне админ сказал что создание целой виртуальной машины еще одной - не стоит ему ни ОЗУ ни жесткого диска. Ему виднее что там у него потреблялось при создании очередной VM...

LXC, не?

с самым высоким приоритетом. Это могут быть как баги

т.е. на баги жаловаться в свободной openVZ бесполезно ? О_о

Аналог openvz - lxc. Удобен тем, что его поддержка есть в стандартном ядре.

В обоих случаях виртуализация весьма условная, отсюда и плюсы и минусы. Плюсы, конечно, экономия ресурсов и удобство клонирования. Фактически, вм, это в минимуме конфиг, а в максимуме конфиг + директория с рутом. Но и минусы серьезны. Шаг в сторону - расстрел.

Openvz постепенно вытесняется lxс. Долго ещё до победы, но она замоячила, ибо lxc в ядре и активно пилится, а vz в закромах параллелса.

openvz

Не хотеть.

KVM или другие системы виртуализации позволяют добиться того же уровня экономии памяти как у OpenVZ?

Это немного разные типы. Я в квме полную виртуализацию использую, а не пара. Если нужны именно паравиртуалки - привет lxc, v-server, solaris zones и тд.

KVM или другие системы виртуализации позволяют добиться того же уровня экономии памяти как у OpenVZ?

man Kernel Samepage Merging
man Memory ballooning

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

И да, сравнивать KVM и OpenVZ - это сравнивать теплое с мягким. LXC - другое дело, учитывая что идея та же что и OpenVZ(и, если мне не изменяет память, кодовая база местами - тоже)

Ясно, LXC, я как-то упустил этот момент. Вероятно, будет иметь массу удобств и поддержка самых последних ядер. Кроме того, вижу что LXC доступно для x86, x86-64, IA-64, PowerPC, SPARC, ARM - неплохой список...

Я сталкивался с OpenVZ как клиент хостинга, вполне неплохо.

Это до тех пор, пока один из контейнеров не начнет активно юзать i/o. И абсолютно все контейнеры на хосте резко начнут тормозить. Вот и вся история успеха.

А KVM тоже позволяет память и общие системные файлы расшаривать между машинами?

Вроде нет, ибо kvm работает с образами, а не с голой ФС. Но KVM позволяет оперативку дедублицировать между виртуалками через ядерный ksm.

Мало что идея хорошая, ещё и ценник гуманный. Посмотрим, кто следующий подтянется.

ksm

Либо можно поэкстремалить ^_^
*смотрит в сторону uksm, zram*

Я сталкивался с OpenVZ как клиент хостинга, вполне неплохо.

Это до тех пор, пока один из контейнеров не начнет активно юзать i/o. И абсолютно все контейнеры на хосте резко начнут тормозить.

Чудеса! IO, оказывается, не резиновый!

Это до тех пор, пока один из контейнеров не начнет активно юзать i/o. И абсолютно все контейнеры на хосте резко начнут тормозить. Вот и вся история успеха.

kvm загнется ровно так же на disk i/o. на самом деле проблемы начинаются когда хостер продает больше памяти чем есть в системе, в тот момент когда все виртуалки начинают использовать ее по максимуму. тогда получается сваппинг и печалька.

плюсы openvz - минимальный оверхед по ресурсам и простота при полной изоляции. lxc пока не готово - нет инструментов, нет простоты и удобства, изоляция не полная. но когда его допилят, тогда да, openvz станет не нужно.

Я в квме полную виртуализацию использую, а не пара. Если нужны именно паравиртуалки - привет lxc, v-server, solaris zones и тд.

Ты путаешь паравиртуализацию и виртуализацию на уровне ОС.

Ты путаешь паравиртуализацию и виртуализацию на уровне ОС.

Чего?

Почему это событие важно? Раньше было только два варианта — либо свободную OpenVZ, без денег и без поддержки, либо коммерческую Parallels Virtuozzo Containers, за деньги и с поддержкой. Теперь же можно использовать open source продукт с коммерческой поддержкой.

Раньше было либо студенческое поделие бесплатно, либо профессиональный коммерческий продукт за деньги. Теперь же можно студенческое кривое поделие - за деньги !

Суть в том, что это поделие выкинули из дебиана.

Почему это важно? Потому что это закат перед лицом kvm и lxc.

Друзья! Слишком много скепсиса и ложных высказываний в сторону такой чудесной технологии как OpenVZ. Я ни минутой ни сотрудник Prallels, но активный пользователь технологий (несколько сотен нод в продакшене, если интересно подробнее - vps2fast.com).

openvz и без платной поддержки очень хорошо поддерживается в bugzilla.openvz.org, но скорее на уровне конкретных багов, возможности «скорректировать» roadmap (например, запросить какую-нибудь мегасуперфичу в ядро) проекта было очень мало, но с платной поддержкой она заявляется и это очень и очень радует.

Кроме того, платная поддержка крайне пригодится в ситуации «ШЕФ, все прполо», мы сталкивались с такими проблемами (и не раз), когда HWN ноды из-за бага в ядре улетали в стек-трейс по непонятным причинам. Удалось исправить/отладить своими силами, но нервов было истрачено излишне много, платная поддержка спасает от этого.

По поводу высказываний lxc vs openvz. Я рекомендую почитать LWN и посмотреть, кто автор тех самых патчей LXC и бОльшей части его подсистем. Для тех кто читать не хочет поясняю - бОльшая часть фич в lxc была «выстрадана» в пределах Parallels Virtuozzo/Parallel Bare Metal (ныне Parallel Cloud Server), была облагорожена и продвинута в апстрим.

Лидер проекта OpenVZ много раз писал, что они будут искреннее рады, когда Virtuozzo (а точнее уже Parallel Cloud Server) будет работать на ванильном ядре, но до этого пока что годы разработки.

Кроме этого по поводу платного ПО от Parallels, ядра что в платной версии, что в бесплатной (OpenVZ) идентичных вплоть до номера минорной версии, так что обвинять Parallels в закрытости разработки - очень странно.

По поводу преимуществ самой технологии OpenVZ перед другими я писать не буду, ибо это будет офтопом :) Есть отличная статья в LinuxJournal, что будущее именно за контейнерами, а не за виртульными машинами, я могу лишь порекомендовать ее к прочтению https://www.getpantheon.com/blog/containers-not-virtual-machines-are-future-c... и http://www.linuxjournaldigital.com/linuxjournal/201304?pg=122#pg118

С уважением, Павел Одинцов, CTO FastVPS

Чего?

http://en.wikipedia.org/wiki/Paravirtualization

http://en.wikipedia.org/wiki/Operating_system-level_virtualization

LXC, VServer, Solaris Zones — это виртуализация на уровне ОС. Паравиртуализация — это, например, Xen (PV guests).

когда HWN ноды из-за бага в ядре улетали в стек-трейс поЮ непонятным причинам

Попробуйте стабильные продукты использовать и не будет ничего улетать изза багов в ядре, ага.

Есть отличная статья в LinuxJournal, что будущее именно за контейнерами, а не за виртульными машинами

Конечно. Именно поэтому kvm облаков все больше, а опенвз инсталяций - все меньше.

Ваш этот контейнер начинает все быстрее вытесняться PaaS. В общем, советую посмотреть на рынок, прежде чем делать выводы, а то CTO на этом фоне выглядит забавно.

инструменты есть, изоляцию пилят (в том числе и с помощью селинукса). Но всётаки киллерфичей openvz является live migration

Я вообще считаю, что openvz нужен тогда, когда хостишь чужие контейнеры, а lxc достаточно, когда хостишь свои.

(юзер и того и другого)

«Попробуйте стабильные продукты использовать и не будет ничего улетать изза багов в ядре, ага.»

Честно говоря, я даже не нахожусь, что ответить по той причине, что это звучит в стиле «У Вас баги? Пробуйте использовать программы без багов».

Я с радостью приму (и внедрю) продукт по виртуализации (да и не по виртулизации, вообще любой продукт!), который никогда не падал. Баги в Xen, KVM и даже (о великий /dev/null) в ядре RHEL я могу привести со ссылками. Они не сильно экзотичные, но вполне в пределах заявленных «стабильных версий» и в пределах «корректного использования».

К слову сказать, в данном случае самый неприятный баг, с которым мы столкнулись был вызван бажной подситемой в ядре RHEL 5, к которой разработчики OpenVZ не приложили никакого участия, баг был в итоге отправлен в багтрекер RedHat, а в OpenVZ ядре была поставлена заглушка, деактивирубщая бажный код в работе DSO.

«Конечно. Именно поэтому kvm облаков все больше, а опенвз инсталяций - все меньше.»

Я не претендую на высокий уровень знания рынка, но таких отчетов «сколько человек пользуется опенвз» не встречал даже на ресурсах Parallels (но зато я вижу число людей его использующих по блогам, новостным сайтам и пресс-релизам и их - очень много), если они у Вас есть - я их с радостью приму. А статью бы Вы прочитали, по Вашим словам я вижу, что ее суть и смысл и даже заголовок (а именно то, что это - «будущее») оставлся без понимания.

надеюсь если опыт будет положительным он перейдет к другим программным пакетам

Уже. Не к каждому пока, и тем не менее. Это же обычный общечеловеческий здравый смысл. Во всяком случае, у нас с EGroupware именно так: Community ли версия, или Premium Line - поддержку может получить каждый кто в ней нуждается. И любого необходимого уровня.

FastVPS

Услуги фаствпс'а — ярчайшее доказательство фундаментальных проблем в openvz.

Конечно. Именно поэтому kvm облаков все больше, а опенвз инсталяций - все меньше.

Естественно, ведь lxc или openvz в принципе не дают возможности запустить свое ядро, загрузить свои модули и т.д.

Чудеса! IO, оказывается, не резиновый!

Именно поэтому во многих системах виртуализации есть управлением распределением i/o для гостей. Но не в ovz. Короче, читать учись.

Но всётаки киллерфичей openvz является live migration

Да с какой стати? Нормальная миграция предполагает полную виртуализацию.

фундаментальных проблем в openvz.

ты про оверселл или что-то еще?

С большим удовольствием держал свои виртуалки в OpenVZ под ProxmoxVE. KVM использовал для винды и виртуализированных «legacy» машин.

ты навреное не пробовал живых миграций в OpenVZ. Downtime в одну минуту при миграции машины с HDD в 200 гигабайт без shared storage - это картина абсолютно нормальная.

Я сталкивался с OpenVZ как клиент хостинга, вполне неплохо.

А я — с другой стороны баррикад. И мне было жалко пользователей.

Ну для определённых целей оно подходит, но не для сдачи VPS в аренду. OpenVZ не особо лучше shared-хостинга.

Рад слышать критику - это лучший способ стать лучше! Но давайте будем предеметными - номер тикета, краткое описание его здесь (дабы суть беседы была понятна всем окружающим, а не только нам с Вами) и подтверждение от Вас обсудить его здесь (так как по умолчанию, тикет - информация сугубо конфиденциальная).

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

Кроме того, OpenVZ имеет очень много портированных подсистем (iptables, fuse, tun/tap, nfs client, nfs server, raw sockets rtc итд), которые дают возможность использовать фичи ядра напрямую, как будто мы работаем прямо на железе.

Так что свое ядро - это определенно «плюс» в таких задачах как роутинг, специфичные модули ядра (вложенная виртулизация), но для типовых user-space приложений это вовсе не нужно.

LXC как чемодан без ручки. Под него по-моему до сих пор нет чего-то вроде Proxmox Virtual Enviroment.

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

Могу предложить использовать vzctl от ребят из Parallels, это как раз та самая «ручка», которая уже может работать на ядре без патча openvz. Правда, не скажу какая версия ядра требуется, но чтобы не промахнуться - можно взять ванильную с linux.org

У вас очень старые данные, в openvz 2/6/32 есть ploop и он стабилен, а такая штука как ploop write tracker позволяет мигрировать хоть терабайтный контейнер, http://openvz.livejournal.com/41835.html

У Вас устаревшая информация. С версии 2.6.32 в openvz используется разделение ввода/вывода на базе cgroups blkio, которое работает абсолютно идентично KVM и LXC в случае использования дисков на базе ploop. KVM/LXC приведены как пример для того, чтобы не было тех, кто скажет, что «а в KVM это лучше», нет, не лучше, ровно точь-в-точь также, так как facility ядра обслуживает эти фичи один и тот же.

Ну и да - куча пиара OpenVZ чуть выше от имени анонимуса - моя (черт подери, где же мой аккаунт на лоре):)

С уважением, Одинцов Павел

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

Я не сталкивался, а клиенты сталкивались.

Ну во-первых, некоторым нужен был VPN (и это далеко не только для обхода цензуры, некоторым он нужен и в рамках изначального назначения VPS), а та компания принципиально не подгружала модуль tun.

Далее идёт привязка к ОС хоста. В том месте использовалась CentOS 5 (в 2013 году), соответственно, клиентам тоже приходилось иметь дело только с ней. Ядро никак не обновишь, userspace-компоненты — только с большим бубном. Допустим, они могли поставить более свежую систему, но бывает, когда наоборот требуется самизнаетечто мамонта. Так что выходом будет только иметь несколько реальных серверов с разными ОС.

Далее клиент не мог так просто переустановить ОС. Если всё упадёт (или, например, он с iptables накосячит, что его самого по ssh не будет пускать), то необходимо обращение в техподдержку.

ты навреное не пробовал живых миграций в OpenVZ. Downtime в одну минуту при миграции машины с HDD в 200 гигабайт без shared storage - это картина абсолютно нормальная.

Я даже не буду говорить, что downtime должен вообще отсутствовать, если миграция действительно живая. В openvz нет живой миграции.

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

Естественно, то, что openvz это по сути чрут, то есть старт/стоп «виртуалки» не влечет за собой рестарт биоса, ядра и занимает секунды, это существенный плюс. Но и только.

Далее клиент не мог так просто переустановить ОС. Если всё упадёт (или, например, он с iptables накосячит, что его самого по ssh не будет пускать), то необходимо обращение в техподдержку.

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

LXC как чемодан без ручки. Под него по-моему до сих пор нет чего-то вроде Proxmox Virtual Enviroment.

Это и плюс и минус. В минимуме, ничего и не надо.

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

При переходе с шаред-хостинга, наверное, да. При переходе со своего сервера, однозначно, нет.

Кроме того, OpenVZ имеет очень много портированных подсистем (iptables, fuse, tun/tap, nfs client, nfs server, raw sockets rtc итд), которые дают возможность использовать фичи ядра напрямую, как будто мы работаем прямо на железе.

Которые работают весьма криво. Лично я столкнулся с трудностями shorewall, nfs сервер и rtc. В итоге предпочел, чтобы они были настроены на хосте, а не виртуалками.