Pull to refresh

Comments 43

UFO just landed and posted this here
Виртуализация это хорошо. Но OpenVZ все же не идеальное решение. Для гостевых linux он хорош. А если нужен win? Да и в гостевом linux ядро не сменить. Пару лет назад я выбирал гипервизор для своего предприятия. Выбирал из: OpenVZ, KVM, XEN, VirtualBox, FreeBSD Jail. Остановился все же на Xen. Там и паравиртуализация есть, и паравиртуальные драйверы для win и полная виртуализация. И поретя производительности в гостевом linux не большая. К стати KVM сейчас ни чем не уступает xen. А его архитектура проще — отсутствует гипервизор который должен первым стартовать на железе.
OpenVZ хорош для VPS хостинга. Для задач web, mail, dns,… У OpenVZ преимущество в целом одно — минимизация потерь производительности. Плюс еще есть особенность: можно дать виртуальным машинам в сумме чуть больше ресурсов чем есть на физической ноде. Для провайдеров услуг это хорошо. А вот для потребителей не очень. Если все машины загружены, то кому-то чего-нибудь не хватит. Короче можно жульничать.
А вот насчет быстрого разворачивания гостевых систем, живой миграции, балансировки нагрузки на ноды, снапшетов это все есть и у других гипервизоров.
Нужно отдавать себе отчет, что именно OpenVZ будет более приемлемым решением, а не что-то другое.
Если нужен Win, то никто не мешает использовать OpenVZ совместно с KVM или иной системой полной виртуализации.
И следом вопрос, нафига плодить, если можно просто использовать KVM, Xen?
За тем что overhead порядка 3% и динамическое управление всеми параметрами контейнера. Возможность шарить данные между контейнерами.

К OpenVZ следует относится как к продвинутому jail. Для консолидации различных сервисов на одной ноде, на мой взгляд это оптимальное решение.
Гораздо проще и эффективнее. Именно поэтому плодить выгоднее, чем «просто использовать» KVM или Xen.
Физические (не виртуальные) сервера тоже ставить быстро если предварительно сделать шаблоны. Всякие вконтакте mail.ru и прочие гуглы ставят их целыми стойками и инсталлируют по сети загрузившись через bootp и выбрав нужный шаблон предустановленного ПО. Да и хостеры поменьше также зачастую практикуют автоматическую установку железного сервера.
Не для всех задач подойдет железная машина. Если какой-либо совсем мелкий демонюга у нас, например, стал запиливаться, мы его можем быстро и просто отселить на другую ноду до выяснения. Или просто почтовый релей быстро поднять.

Ну и еще, представляете себе, какая адушка будет на железной машине в сетевых интерфейсах, если на нее все поскидать в одну кучу — базу данных, веб сервисы с виртуальными хостами, почту, различные сервисные штуки типа сервера логов. Через некоторое время просто не разберешься во всех этих стопицот айпишниках и таблицах маршрутизации. Ну и когда настанет пора что-то переселять с машины — это тоже время, деньги и ресурсы. Не факт еще, что все получится гладко.
Openvz, ploop — почти без даунтайма и аккуратно такие проблемы решают. А если прикрутить ceph+kvm, то вообще почти вмваре ласт едишн со всеми свистелками.

Также если команда разработки большая, то с помощью openvz можно очень быстро и безболезненно создать унифицированное окружение — разработка-тестирование-продакшн.

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

Я к тому, что виртуализация — это чудеса, которых не бывает, как известно. И у нее есть свои проблемы. Особенно у openvz. Но зачастую этот инструмент дает профита гораздо больше, как в деньгах, так и времени. У нас вот время — самый важный ресурс, наверное. Если его неразумно тратить — то конкуренты сожрут просто.
Это несерьезный подход. Разобраться можно в любом количестве машин, вопрос в качестве документации. Единственные преимущества виртуализации — плотность и равномерность нагрузки на физические сервера. Установка и настройка ПО в массовых объемах (один сервер 10 раз == 10 серверов, так что это уже массовый объем) — это задача SCM, а не рук админа и уж тем более — не шаблонов виртуализатора.
В чем несерьезность? В каком качестве документации? Серверов больше десяти и ваша документация никому уже не нужна. Вы ее не успеете обновлять. Это не ентерпрайз, где раз поставил 1С десять лет назад и годами она там жужжит.

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

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

Мы в неделю релизим 10-50 фич в несколько продуктов сразу. Также используем сплиты, когда фича доступна не всем, а только небольшим группкам пользователей. Иногда используем «нестабильные» версии софта, которые требуют новейших либ. Как это все документировать? Надо целый отдел посадить писать неделю доки, которые к вечеру первого дня уже устареют.

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

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

Это все несерьезно? Да ладно.
А как «использование виртуализации дало возможность быстро добавить новые мощности» в Вашем случае?
Вы не смотрели lxc? В чем принципиальная разница?
LXC наполовину написан ребятами из Parallels — то есть, разработчиками Virtuozzo и OpenVZ.

Он ещё сырой. Безопасности очень не хватает. root в контейнере = root в системе. Написал shutdown в контейнере — остановил сервер.
Пользователь с UID=500 в контейнере = пользователь с UID=500 в другом. Это значит, что misha в одном = vasya в другом.

Короче, LXC — это то, чего всем давно нужно и все долго ждали, просто пока ещё не допилен. И этого очень, очень не хватает в винде.
Зачем сейчас OpenVZ? Это уже очень устаревшая технология.

Лучше использовать или Xen или KVM.
не сравнивайте тёплое с мягким. OpenVZ и LXC — это виртуализация окружения, Xen, KVM, Hyper-V и прочие — виртуализация машины
Вот вот. Не сравнивайте.

OpenVZ, вещь, которая застряла в развитии.
Вот с чего вдруг вы это решили? Патчи периодически добавляются в ядро, они активно обмениваются наработками с девелоперами LXC. Запилили на днях буквально отличный ploop. Open-source решения для клаудов активно интегрируются с openvz — proxmox, open-nebula, cloudstack.
В каком развитии застряло? По сравнению с чем?

Ну как минимум можно получить лучшее распределение памяти по нодам. То есть когда одной ноде память не нужна её может использовать другая.
вот это можно сделать и в квм, и в зене, и в гиперви
bit.ly/XsI2Xy

то есть, я понимаю, что вы могли не слышать этот термин — ballooning. Но тогда вам вообще не следовало спорить на эту тему.
впрочем, я неправ. Извините.
То есть у меня сервер на 32 гига оперативы, и 10 контейнеров xen и каждому я могу выделить по 31 гигу оперативы?
когда я сидел на ксене ещё такого не было.
Нет, в зене такого не сделать.
KVM? Если я не ошибаюсь, там такое возможно.
Да, я так понимаю, Вы говорите про Virtio balloon driver
да. И есть такая служба для винды. и Xen умеет давно, как минимум вся третья ветка уже умела.
А никогда не расматривали Linux-vServer?
Там очень много проблем. Все залипает, сеть прокинуть, контейнер может исчезнуть или сдублироваться, изоляция криво работает.
В 2007 году было актуально, сейчас openvz по всем параметрам удобнее и лучше.
Не туда ответил, простите, вопросы ниже…
Что значит все залипает?
Сеть прокинуть нет проблем, добавил адрес на хосте, добавил адрес в виртуалку. Все в реалтайме.
Ни разу контейнер не исчезал у нас.

Подробнее про проблемы изоляции можете рассказать?
простите, я может не в теме, с linux-vserver не сталкивался. Мне непонятна логика: зачем добавлять адрес на хосте, если он нужен именно в контейнере?
Если честно я уже шесть лет почти не смотрел что там с vserver. На тот момент было много проблем. Если сейчас все стало лучше, то отлично же.
Вот навскидку. Как-то я переименовывал виртуалку, она как-то осталась запущенной, а файлов ее уже не было. Зато были файлы у новой виртуалки, которая еще не стартовала и даже не смогла. Без ребута сервера не решить.
Допустим, апач или какой другой сервис на хардваре ноде запущен и забинден на все интерфейсы. Внутри контейнера уже не запустится без плясок.
Сеть добавить? 18 айпишников есть — их надо зарутить по своим 18 таблицам маршрутизации, просто так их не добавить. Лимиты крутить для виртуалок, которые надо еще высчитать на калькуляторе.
Процессы постоянно дерутся за ресурсы.
Ну и под нагрузкой — залипания. Сервис вроде есть, порт открыт, но ничего не делает больше. Не читает оттуда, не пишет. И даже не дает стопнуть виртуалку.
Как это все мигрировать в случае чего — быстро и с минимальным даунтаймом.

Неудобно же )
Есть мнение, что виртуализация добавляет значительный оверхед ресурсов, но, за счет того, что OpenVZ является лишь надстройкой ядра, если специально не ограничивать ресурсы, разница между физическим сервером и VPS-контейнером практически незаметна.
Мнение ошибочно. Оверхед на полноценную виртуализацию, вроде Xen или KVM настолько мал, что его можно отбросить.

контейнеры представляют из себя обычные папки со структурой операционной системы.
Да, это — действительно удобно. Как и то, что можно зайти внутрь виртуальной машины, не зная пароля от ssh. Страно, что вы об этом не упомянули. В Xen, например, чтобы сбросить юзеру пароль от ssh, надо много действий сделать, плюс это 2 ребута виртуальной машины, что тоже не есть хорошо.

Если уже разбирать по полочкам — вы сейчас сравниваете теплое с мягким. OpenVZ и Xen/KVM — это достаточно разные виртуализации, и прямо сказать, что лучше — нельзя. Вот что не понравилось в OpenVZ — я не могу выдать процессор по мегагерцам машине, могу лишь приоритет ей задать.
не знаю как в openvz, а в lxc можно выдать, ну если не по мегагерцам, то лимитировать загрузку через cgroup. Вообще любые ресурсы, которые cgroup поддерживает (ОЗУ, своп, проц, I/O) можно лимитировать для контейнера
Пробовали мы этот ваш опенвз. Наелись по уши. iotop не работает, процессы залипают время от времени на несколько секунд. Монга ругается.

Ушли на KVM. Пока что полет нормальный.
Вы просто неправильно его готовите. OpenVZ — виртуализация окружения со всеми вытекающими (включая в высшей степени странное распределение памяти, не менее странную маршрутизацию и более чем безумно выглядещие устройства). Использовать OVZ для чего-то нагруженного — верный способ напридумывать себе проблем на ровном месте. Идеальное место для опенвз — это очень много очень маленьких контейнеров с нагрузкой, близкой к нулевой.
Да ладно. У нас с нагрузкой вроде проблем нет. До 15 тысяч рпс на некоторых участках, полет нормальный, проблем нет.
Согласен. У нас много нагруженных проектов и все они стабильно работают под OpenVZ.
Что мы все, ploop ploop. Вот слайды.
Посоны вроде как решили самые назойливые и неприятные проблемы openvz — чрезмерное запиливание дискового I\O из-за общего журнала, также появились снапшоты и почти живая миграция, и бекапы. Также в некотором роде дедупликация. Также появилась возможность использоват разные файлухи для разных контейнеров и забить на общие иноды и различные квоты для хранилища.
Sign up to leave a comment.