Comments 278
крупные операторы вообще предпочитают сдавать в аренду «серверы», собирая их из десктопных комплектующих
кажется это камень в огород одного неплохого немецкого хостера. а вообще всё же просто: не хотите попасть на оверселинг — покупайте физический сервер. жалко денег на администрирование физического железа? страдайте от оверселлинга.
Именно так и есть, автор много раз (не в этой статье) упоминает о не-серверном железе от хетзнера. Не иначе как в угоду своей компании :)
Да нет же :) У меня нет своей компании (полтора года назад была, бизнес закрыт). Я обычная наемная офисная служащая (UNIX администратор) в настолько крупной компании, что я в ней просто винтик. Разумеется, никто мне права писать от имени этой компании не давал.
Кстати, у меня у самой дедик у того хостера, у кого «серверы» из PC :) И да, там стоит OpenVZ, на которой раздаются VPS знакомым (за сервер платит один из личных клиентов)
Кстати, у меня у самой дедик у того хостера, у кого «серверы» из PC :) И да, там стоит OpenVZ, на которой раздаются VPS знакомым (за сервер платит один из личных клиентов)
а вообще всё же просто: не хотите попасть на оверселинг — покупайте физический сервер. жалко денег на администрирование физического железа? страдайте от оверселлинга.
В моем топике высказан очень спорный тезис о том, что оверселлинг это не плохо, а наоборот хорошо: хорошо и для хостера, и [b]для клиента[/b]. Понимаю, что вникнуть в это тяжело, но попробуйте хотя бы не отвергать его сразу!
В качестве обоснования привела пример из теории игр. Можно Вас попросить перечитать мой топик еще раз? Может быть, это заставит Вас изменить точку зрения на оверселлинг?
В статье куча несуразности, например:
Такое впечатление, что писал человек, приверженный openvz, то есть не беспристрастно.
Чего стоят только абзацы о миграции в реальном времени.
PS: С Вами знаком еще с opennet, там Вы проявляли себя более лояльно.
Так же плюс контейнеров
заключается в том, что память и другие ресурсы, такие как дисковое пространство, не выделяются гостевой системе целиком (например, размер lun, отданного в распоряжение виртуальной машине в качестве диска, уже нельзя уменьшить).
Такое впечатление, что писал человек, приверженный openvz, то есть не беспристрастно.
Чего стоят только абзацы о миграции в реальном времени.
PS: С Вами знаком еще с opennet, там Вы проявляли себя более лояльно.
Это не несуразность :) Вы заходили когда-нибудь под рутом на хост-систему с OpenVZ или FreeBSD Jails?
Загляните вот сюда:
ls /vz/{root,private}/[VEID]/
и увидите файловую систему контейнера. Как Вы думаете, файлы VPS-ок, сложенные в файловой системе хост-системы, и файлы, которые находятся внутри файлов или, например, внутри LUN рейд контроллера, займут столько же места? Как бы не так!
А фичи того же KVM вроде baloon технологии, для оверселлинга ОЗУ, можно включить только с согласия администратора VPS, и для хостинга не годятся!
Загляните вот сюда:
ls /vz/{root,private}/[VEID]/
и увидите файловую систему контейнера. Как Вы думаете, файлы VPS-ок, сложенные в файловой системе хост-системы, и файлы, которые находятся внутри файлов или, например, внутри LUN рейд контроллера, займут столько же места? Как бы не так!
А фичи того же KVM вроде baloon технологии, для оверселлинга ОЗУ, можно включить только с согласия администратора VPS, и для хостинга не годятся!
Не хочу превращать данный диалог в холивар, но достаточно одного пункта, который играет решающюю роль при выборе openvz vs XEN/KVM, для знающего человека, берущего VPS в аренду, это возможность использовать своё ядро.
В openvz, прикрутить модуль или поменять ядро не представляется возможным или только с бубном и письмами, а это значит, что сервер неполноценен.
В openvz, прикрутить модуль или поменять ядро не представляется возможным или только с бубном и письмами, а это значит, что сервер неполноценен.
Вам так часто нужно собственное ядро или собственный модуль? Особенно на дешевом VPS хостинге? Можете привести примеры?
Кстати маленькие, дешевые OVZ хостинги очень часто могут пойти Вам на встречу, и загрузить нужный Вам модуль, дав Вашему VPS права на доступ к его устройству в /dev
Кстати маленькие, дешевые OVZ хостинги очень часто могут пойти Вам на встречу, и загрузить нужный Вам модуль, дав Вашему VPS права на доступ к его устройству в /dev
Несомненно часто, и не только мне, а, я считаю, многим.
Нет кишит вопросами про то, как добавить модуль в iptables на openvz — никогда не интересовались?
а tap/tun вопросом под openvz, неужели ни разу не сталкивались?
Да просто осознание того, что ты заплатил на неполноценный сервер, уже угнетает душу :)
Нет кишит вопросами про то, как добавить модуль в iptables на openvz — никогда не интересовались?
а tap/tun вопросом под openvz, неужели ни разу не сталкивались?
Да просто осознание того, что ты заплатил на неполноценный сервер, уже угнетает душу :)
OpenVPN прекрасно работает в контейнере под OpenVZ. Почему некоторые OVZ хостеры запрещают с ним работать, для меня совершенно не понятно.
Модули iptables тоже можно добавить на ноду.
В общем, это вопрос отношений с хостером.
Мое ИМХО (не обижайтесь пожалуйста!) Вы стали жертвой широкомасштабной агитации против OpenVZ на хабрахабре.
Мой топик преследовал только одну цель: исправить положение, и объяснить, что OVZ не так плох, как его на хабрахабре рисуют, а Xen, KVM, hyper-V VPS-ки не настолько хороши, если хостер не использует для хранения виртуалок SAN/DAS, а данные VPS лежат локально. \
Честное слово, у меня нет никакого коммерческого интереса! Просто обидно за, на мой взгляд, потрясающую технологию (OpenVZ), хотела лишь защитить ее от несправедливых нападок!
Модули iptables тоже можно добавить на ноду.
В общем, это вопрос отношений с хостером.
Да просто осознание того, что ты заплатил на неполноценный сервер, уже угнетает душу :)
Мое ИМХО (не обижайтесь пожалуйста!) Вы стали жертвой широкомасштабной агитации против OpenVZ на хабрахабре.
Мой топик преследовал только одну цель: исправить положение, и объяснить, что OVZ не так плох, как его на хабрахабре рисуют, а Xen, KVM, hyper-V VPS-ки не настолько хороши, если хостер не использует для хранения виртуалок SAN/DAS, а данные VPS лежат локально. \
Честное слово, у меня нет никакого коммерческого интереса! Просто обидно за, на мой взгляд, потрясающую технологию (OpenVZ), хотела лишь защитить ее от несправедливых нападок!
Никаких обид лично на себя не принимаю, но эти Ваши слова, про «жертв широкомасштабной агитации», камень в огород всего Хабр-сообщества, которое так считает — Вам это не кажется?
Создав этот топик, я пошла на определенный риск, уйти катастрофически в минуса по репутации, и впредь всегда молчать на Хабра Хабре, но было слишком обидно за репутацию OpenVZ, настолько, что захотелось переломить ситуацию, и объяснить, что не все то белое, что кажется белым, и не все то черное, что кажется черным.
Иногда над ситуацией, где хороший VPS, а где " неполноценный", стоит подумать еще раз.
Иногда над ситуацией, где хороший VPS, а где " неполноценный", стоит подумать еще раз.
Не переживайте вы так… Профессионалов прежде всего отличает умение использовать инструменты по назначению.
Админ, который действительно понимает, что такое производительность, системные ресурсы и время администратора, не будет использовать xen, там где можно обойтись контейнером. И контейнеры там, где не требуется серьезная изоляция и можно обойтись отдельным аккаунтом. Лично для меня тут нет предмета для обсуждения…
Многие считают, что для временного решения проще поднять xen, так как инфраструктура отлажена. Но они видимо считают дополнительные затраты своего времени на настройку сервера не существенными.
Для тех, кто в мыслит категориями «круто, не круто», администрирование это очевидно хобби, и всерьез их воспринимать вряд ли стоит…
Админ, который действительно понимает, что такое производительность, системные ресурсы и время администратора, не будет использовать xen, там где можно обойтись контейнером. И контейнеры там, где не требуется серьезная изоляция и можно обойтись отдельным аккаунтом. Лично для меня тут нет предмета для обсуждения…
Многие считают, что для временного решения проще поднять xen, так как инфраструктура отлажена. Но они видимо считают дополнительные затраты своего времени на настройку сервера не существенными.
Для тех, кто в мыслит категориями «круто, не круто», администрирование это очевидно хобби, и всерьез их воспринимать вряд ли стоит…
Да просто осознание того, что ты заплатил на неполноценный сервер, уже угнетает душу :)
Лично для меня это основная причина :)
Да просто осознание того, что ты заплатил на неполноценный сервер, уже угнетает душу :)
Отличный аргумент для профессионала…
своё ядро ценой потери sendfile/splice/tee и других чудесных системных вызовов?
Файлы? Для контейнеров? Всегда выделял виртуалкам LVM-разделы. Кстати, поменять их размер можно и без перезагрузки.
Я тоже на KVM/Xen выделяю виртуалкам LVM тома, хотя у LVM есть много недостатков. Если Вы внимательно прочитаете пост, то увидите там:
LVM том вы тоже не сможете оверселлить. Это не промышленная SAN с дедубликацией и даже не ZFS.
LVM том Вы сможете сделать для VPS клиента меньше только при смене клиентом тарифного плана, и продать то место, что не не использует, не выйдет. Ладно, если у Вас SATA диски, а если сверхдорогие SSD? Или дороговатые SAS?
например, размер lun, отданного в распоряжение виртуальной машине в качестве диска, уже нельзя уменьшить
LVM том вы тоже не сможете оверселлить. Это не промышленная SAN с дедубликацией и даже не ZFS.
LVM том Вы сможете сделать для VPS клиента меньше только при смене клиентом тарифного плана, и продать то место, что не не использует, не выйдет. Ладно, если у Вас SATA диски, а если сверхдорогие SSD? Или дороговатые SAS?
LVM тома оверселлить можно.
С версии ядра 3.2 или 3.3, не помню ужо.
С версии ядра 3.2 или 3.3, не помню ужо.
Угу, а еще Live Migration уже есть в KVM fedora между стораджами. Только сколько регрессий в этих ядрах?
Может быть, у меня не точка зрения большинства, но мне больше нравится ядро RHEL6 на сервере.
Может быть, у меня не точка зрения большинства, но мне больше нравится ядро RHEL6 на сервере.
И еще, наверняка ведь есть деградация производительности при включенной дедубликации? Она даже на промышленных SAN иногда ощущается :(
LVM и так мягко говоря не быстрый, если сделать снапшот, и имеет кучу других проблем, так вы еще и дедубликацию включаете: ничего этого не нужно на дешевой машине с OpenVZ: все данные клиентов на одной файловой системе, есть Live Migration, есть vzswap
LVM и так мягко говоря не быстрый, если сделать снапшот, и имеет кучу других проблем, так вы еще и дедубликацию включаете: ничего этого не нужно на дешевой машине с OpenVZ: все данные клиентов на одной файловой системе, есть Live Migration, есть vzswap
А кто сказал про дедупликацию? Я говорю про то, что можно создать LVM томов на больший объём, чем есть в vg. Писать после заполнения всего vg не дадут, само собой. Никакой деградации в производительности здесь нет.
LVM — быстрый. По крайней мере, достаточно быстр для своих задач. Оверхед от его использования не сильно превышает оверхед от использования аналогичного количества партиций на диске. Снапшоты — медленные, если в них писать. Но чего вы ещё ждете от них О_о? Вы бы ещё сказали, что galera медленно коммитит UPDATE в базы.
По поводу все «данные клиентов на одной файловой системе» — тут тоже все не так просто. Openvz с большим количеством виртуалок по IO проседает намного сильнее, чем LXC с lvm томами. Главная причина, понятное дело, квоты. Но их можно отключить. Но есть и вторая причина — уровень абстракции, при помощи которого ovz ограничивает виртуалки в пределах этой фс (короче, simfs). Эта штука — достаточно медленная в условиях большого количества конкурентных запросов. И с этим вы уже ничего не сделаете. Более того, при 8 виртуальных машинах на SATA-дисках (enterprise-дисках) у вас 8 виртуалок в KVM на LVM томах будут получать суммарно больше IO, чем 8 виртуалок через simfs без квот.
LVM — быстрый. По крайней мере, достаточно быстр для своих задач. Оверхед от его использования не сильно превышает оверхед от использования аналогичного количества партиций на диске. Снапшоты — медленные, если в них писать. Но чего вы ещё ждете от них О_о? Вы бы ещё сказали, что galera медленно коммитит UPDATE в базы.
По поводу все «данные клиентов на одной файловой системе» — тут тоже все не так просто. Openvz с большим количеством виртуалок по IO проседает намного сильнее, чем LXC с lvm томами. Главная причина, понятное дело, квоты. Но их можно отключить. Но есть и вторая причина — уровень абстракции, при помощи которого ovz ограничивает виртуалки в пределах этой фс (короче, simfs). Эта штука — достаточно медленная в условиях большого количества конкурентных запросов. И с этим вы уже ничего не сделаете. Более того, при 8 виртуальных машинах на SATA-дисках (enterprise-дисках) у вас 8 виртуалок в KVM на LVM томах будут получать суммарно больше IO, чем 8 виртуалок через simfs без квот.
Можно тесты в студию?
И Вы опять таки забываете про vzswap, а еще про vzfs, может, Вы и ее тестили?
А что касается lvm, с ним постоянно у многих возникают странные проблемы (у меня никогда не было, так как я с ним всегда аккуратно обращалась) шаг влево-щаг вправо расстрел.
Я думаю, для Вас не секрет, что у многих в телекоме предубеждение против LVM, и многие его просто не используют.
И Вы опять таки забываете про vzswap, а еще про vzfs, может, Вы и ее тестили?
А что касается lvm, с ним постоянно у многих возникают странные проблемы (у меня никогда не было, так как я с ним всегда аккуратно обращалась) шаг влево-щаг вправо расстрел.
Я думаю, для Вас не секрет, что у многих в телекоме предубеждение против LVM, и многие его просто не используют.
vzfs — «virtuozzo feature».
vswap не поможет вам, если у вас mass IO в сторадж. Помогут хорошие fs-cache, да кто ж о них у хостеров думать будет. А свой собственный fs-cache мне не дают в openvz, да.
> у многих возникают странные проблемы
В линуксах всё повторяет кривизну рук владельца. У меня вот сеть всегда плохо работает, да…
Про тесты записал в тудушку, в блоге опубликую.
vswap не поможет вам, если у вас mass IO в сторадж. Помогут хорошие fs-cache, да кто ж о них у хостеров думать будет. А свой собственный fs-cache мне не дают в openvz, да.
> у многих возникают странные проблемы
В линуксах всё повторяет кривизну рук владельца. У меня вот сеть всегда плохо работает, да…
Про тесты записал в тудушку, в блоге опубликую.
Очень жду… Но пока (не обижайтесь, пожалуйста!) позвольте сомневаться в Ваших выводах.
У меня OpenVZ даже на офисных задачах (не говоря о хостинговых!) делает по производительностильности KVM и очень существенно.
Бенчмарков я не делала, но в топике запостила бенчмарки HP xen vs openvz
Хотя в офисах обычно использовала комбинированные ядра KVM+OpenVZ (что бы Windows виртуализировать).
Кажется, мне тут готовы приписать ненависть XEN/KVM или ESXi, тогда как при наличии бюджета я бы и хостинг, и в офисе серверную инфраструктуру сделала с гипервизором (а не контейнерами) и виртуалками на полочке с дисками, хотя бы с «хвостами» SAS для двух серверов.
У меня OpenVZ даже на офисных задачах (не говоря о хостинговых!) делает по производительностильности KVM и очень существенно.
Бенчмарков я не делала, но в топике запостила бенчмарки HP xen vs openvz
Хотя в офисах обычно использовала комбинированные ядра KVM+OpenVZ (что бы Windows виртуализировать).
Кажется, мне тут готовы приписать ненависть XEN/KVM или ESXi, тогда как при наличии бюджета я бы и хостинг, и в офисе серверную инфраструктуру сделала с гипервизором (а не контейнерами) и виртуалками на полочке с дисками, хотя бы с «хвостами» SAS для двух серверов.
> делает по производительностильности KVM и очень существенно.
Это уж точно ересь. Ради такого я даже танк достану и постреляю в одинаковые конфиги.
Я могу поверить, что openvz выигрывает при большом количестве машин (8 или больше), но раньше — вряд ли. А уж при виртуализации 1в1 делает vz в хвост и гриву.
В те же тесты внесу тогда обстрел одинаковой конфигурации.
> гипервизором (а не контейнерами)
openvz — тоже гипервизор.
> приписать ненависть XEN/KVM или ESXi
ненависть приписать не готовы, а вот излишнюю любовь к ovz — вполне. Ну и любовь к rhel.
Ещё раз — не нужно писать столь безапелляционные посты. Openvz ни плох, ни хорош. Это инструмент. Инструмент, который хорошо работает при одних условиях и плохо при других. Вы же описываете всё столь безоблачно, что прочитавший вас сисдамин с 5ю сотнями dom0 машин должен пойти и снести оттуда весь lxc и понаставить ovz.
(кстати, lxc я бы вам в офисе настоятельно порекомендовал — вам же изоляция непробиваемая не нужна и вы администрируете сами виртуалки тоже?).
Это уж точно ересь. Ради такого я даже танк достану и постреляю в одинаковые конфиги.
Я могу поверить, что openvz выигрывает при большом количестве машин (8 или больше), но раньше — вряд ли. А уж при виртуализации 1в1 делает vz в хвост и гриву.
В те же тесты внесу тогда обстрел одинаковой конфигурации.
> гипервизором (а не контейнерами)
openvz — тоже гипервизор.
> приписать ненависть XEN/KVM или ESXi
ненависть приписать не готовы, а вот излишнюю любовь к ovz — вполне. Ну и любовь к rhel.
Ещё раз — не нужно писать столь безапелляционные посты. Openvz ни плох, ни хорош. Это инструмент. Инструмент, который хорошо работает при одних условиях и плохо при других. Вы же описываете всё столь безоблачно, что прочитавший вас сисдамин с 5ю сотнями dom0 машин должен пойти и снести оттуда весь lxc и понаставить ovz.
(кстати, lxc я бы вам в офисе настоятельно порекомендовал — вам же изоляция непробиваемая не нужна и вы администрируете сами виртуалки тоже?).
Изоляция это практически всегда и изоляция безопасности. Даже для офисного сервера.
Кстати, в LXC нет аналога не только vzswap (lxc.cgroup.memory.memsw.limit_in_bytes это не аналог. Почему, написала в топике), но и аналога cpulimit, а так же нет того изящного решения, что есть в OVZ с cpuunits (читали же про бенчмарк, и cpuunits, которые power of node?).
Без этого, а так же без Live Migration он не нужен. Гасить «сервер» в офисе без hotswap, и тем самым переводить кучу сервисов в down, совсем не хочется (как и работать во внерабочее время)
Вы серьезно? Может и jails гипервизор, и chroot? Если Вы в этом уверены, сделайте доброе дело, исправьте википедию!
Кстати, в LXC нет аналога не только vzswap (lxc.cgroup.memory.memsw.limit_in_bytes это не аналог. Почему, написала в топике), но и аналога cpulimit, а так же нет того изящного решения, что есть в OVZ с cpuunits (читали же про бенчмарк, и cpuunits, которые power of node?).
Без этого, а так же без Live Migration он не нужен. Гасить «сервер» в офисе без hotswap, и тем самым переводить кучу сервисов в down, совсем не хочется (как и работать во внерабочее время)
openvz — тоже гипервизор.
Вы серьезно? Может и jails гипервизор, и chroot? Если Вы в этом уверены, сделайте доброе дело, исправьте википедию!
Эм. Как это нету? В любом линуксе есть аналог vswap — swap-файл в ramfs ;)
С учетом того, что ovz пока не очень хорошо освобождает vswap, когда нужна память под приложения — получается вполне себе сравнимое решение.
cpuunits есть — cpuset.sched_load_balance
cpulimit по количеству ядер — cpuset.cpus (а в lxctl и он не нужен, само разберется). Возможности выдать «полтора ядра» действительно нет.
Живой миграции нет, пока. Впрочем, есть checkpointing — его хватает.
Ну ок, вам lxc не подходит. Мне ovz не подходит. На том пока и сойдемся =)
С учетом того, что ovz пока не очень хорошо освобождает vswap, когда нужна память под приложения — получается вполне себе сравнимое решение.
cpuunits есть — cpuset.sched_load_balance
cpulimit по количеству ядер — cpuset.cpus (а в lxctl и он не нужен, само разберется). Возможности выдать «полтора ядра» действительно нет.
Живой миграции нет, пока. Впрочем, есть checkpointing — его хватает.
Ну ок, вам lxc не подходит. Мне ovz не подходит. На том пока и сойдемся =)
Эм. Как это нету? В любом линуксе есть аналог vswap — swap-файл в ramfs ;)
Это не аналог. vzswap специально сделана медленной, что бы гостевая система под нагрузкой замедлилась, и не потребляла лишних ресурсов системы, но и ее при этом не покарал OOM Killer
cpuunits есть — cpuset.sched_load_balance
Не тот это cpuunits, почитайте про утилиту vzcpucheck (выше написала подсказку, power of node)
Хотя попытка была хорошая, функционал UNIX nice обеспечен :))
cpulimit по количеству ядер — cpuset.cpus
Вы, наверное, слишком давно администрировали OpenVZ и Virtuozzo (а значит ваши бенчмарки устарели), по тому, что аналогом cpuset.cpus является вовсе не cpulimit, а совсем другой параметр., cpus, они даже пишутся похоже!
Что за vzswap такой никому неизвестный?
Про vswap же на каждом заборе написано.
CPUunits отродясь определял приоритет запросов к CPU между виртуалками. Как раз то же самое делает и cpuset.sched_load_balance. Что-то изменилось?
cpulimit, кстати, есть — cpu.shares. 100% процессорного времени — 1024 единицы. Непривычно первое время и нужно переписывать при миграции на машину с другим количеством ядер, но, опять же — нельзя сказать «нету».
Про vswap же на каждом заборе написано.
CPUunits отродясь определял приоритет запросов к CPU между виртуалками. Как раз то же самое делает и cpuset.sched_load_balance. Что-то изменилось?
cpulimit, кстати, есть — cpu.shares. 100% процессорного времени — 1024 единицы. Непривычно первое время и нужно переписывать при миграции на машину с другим количеством ядер, но, опять же — нельзя сказать «нету».
Что за vzswap такой никому неизвестный?
Блин :( Просто читала первый раз про него в с экрана смартфона, где буквы меньше, чем на ноуте, так неправильно и запомнила. Спасибо, что поправили ошибку в моей памяти :)
Поставлю Вам плюс, если не забуду, и когда-нибудь будет достаточно кармы :)
CPUunits отродясь определял приоритет запросов к CPU между виртуалками. Как раз то же самое делает и cpuset.sched_load_balance. Что-то изменилось?CPUunits отродясь определял приоритет запросов к CPU между виртуалками. Как раз то же самое делает и cpuset.sched_load_balance. Что-то изменилось?
У cpuunits есть еще одна, не всем известная фича: что VE с cpuunits 200 будет быстрее VE с cpuunits 100 при прочих равных в два раза, знают все, но не все знают, что на всех серверах хостинга с разными процессорами можно использовать утилиту:
[root@ovz07 ~]# vzcpucheck
Current CPU utilization: 1322084
Power of the node: 1122625
Warning: hardware node is overcommitted
Вы можете ставить не рандомные cpuunuts (100, 2000 и тд), а такие, что бы в сумме было чуть больше, чем power of the node.
Тогда при переезде на другой сервер контейнер будет работать с такой же скоростью, не смотря на разницу в производительности мегагерц на одной и другой ноде.
Вот такая вот честность OpenVZ хостинга по CPU перед хостингом на Xen
Я вам скажу как админ более 1к VPS на OpenVZ.
Если бы не желание клиентов такой гадости на наших серверов бы не было.
Вечные глюки с checkpoint, с остановкой квот и хардлоками.
Огромный оверхед на клиентских квотах.
В общем — ну нафиг, лучше мы будем иметь меньшую маржу, но будем давать клиентам безглючную услугу на XEN.
Главное чтобы клиенты это поняли и не нужно пытаться их переубеждать что «говно не так плохо пахнет».
Если бы не желание клиентов такой гадости на наших серверов бы не было.
Вечные глюки с checkpoint, с остановкой квот и хардлоками.
Огромный оверхед на клиентских квотах.
В общем — ну нафиг, лучше мы будем иметь меньшую маржу, но будем давать клиентам безглючную услугу на XEN.
Главное чтобы клиенты это поняли и не нужно пытаться их переубеждать что «говно не так плохо пахнет».
По-моему, все наоборот: продвинутые клиенты не любят OpenVZ (так как якобы оверселлинг в отличие от «честного Xen»), большинству клиентов справедливо просто пофик, им важно, что бы было дешево и качественно, а OVZ нравится бизнесу.
Если Вы думаете, что нет глюков у Xen и у KVM, имхо, Вы живете в виртуальной реальности :))
Если Вы думаете, что нет глюков у Xen и у KVM, имхо, Вы живете в виртуальной реальности :))
Тогда расскажите о «глюках XEN».
А то уже 5 лет с ним работаю и неисправимого конфигом глюка не видел.
А то уже 5 лет с ним работаю и неисправимого конфигом глюка не видел.
Как будто бы багтрекер xen-а всегда был пуст, и в нем ничего не было :)
Вы сами понимаете, о чем пишите?
Например, масса глюков и регрессий с паравиртуализированными ядрами были.
FreeBSD только недавно вот научилась не падать в DomU
Вы сами понимаете, о чем пишите?
Например, масса глюков и регрессий с паравиртуализированными ядрами были.
FreeBSD только недавно вот научилась не падать в DomU
А фряха пока официально и не поддерживается. Допилят — тогда и посмотрим.
А как там драйвера для Windows поживают от коммюнити? Давно ли синие экраны прекратились, что Вы об этом уже забыли?
Давно.
Уже года 2 не видел.
Уже года 2 не видел.
Почти 5 лет на XCP+XenServer. Не видел экранов.
Хотя не. Вру. Недавно встретил баг на древней виртуалке с 2к3 после переезда на xcp 1.6, решилось установкой старой версии дров/тулзов. Там дисковые io тормозили, если у системы больше одного ядра. Если бы не жадность админа из отдела, заказавшего ее, то мы бы баг не заметили. :)
Хотя не. Вру. Недавно встретил баг на древней виртуалке с 2к3 после переезда на xcp 1.6, решилось установкой старой версии дров/тулзов. Там дисковые io тормозили, если у системы больше одного ядра. Если бы не жадность админа из отдела, заказавшего ее, то мы бы баг не заметили. :)
на XenServer проприетарные драйвера для Windows, а не драйвера от коммюнити.
XenServer нужно сравнивать не с GPL-ым OpenVZ, а с тоже частично проприетарной Virtuozzo
XenServer нужно сравнивать не с GPL-ым OpenVZ, а с тоже частично проприетарной Virtuozzo
Присоединяюсь. Тоже хотелось бы услышать.
За все время хапнул глюки в xen только два раза — включил openvSwitch когда его впилили, но официально не включили. Второй раз — когда попробовал вкомпилить в ядро dom0 одну экспериментальную, но очень нужную штуку. Но в обоих случаях я ССЗБ :)
За все время хапнул глюки в xen только два раза — включил openvSwitch когда его впилили, но официально не включили. Второй раз — когда попробовал вкомпилить в ядро dom0 одну экспериментальную, но очень нужную штуку. Но в обоих случаях я ССЗБ :)
Кстати, про глюки чекпоитинга: угу, иногда сам выгружается vzcpt, например. Но это же лечится костылём в кроне!
Да чего там, давайте тогда уж сразу патчи OVZ на ядро править.
Зачем оно надо когда есть стабильные технологии?
Дедлоки на mount кстати уже больше года в багтрекере висят.
Пока глухо.
Зачем оно надо когда есть стабильные технологии?
Дедлоки на mount кстати уже больше года в багтрекере висят.
Пока глухо.
можно номер бага? Кажется, я поняла, о чем Вы говорите.
А зачем Вы делаете перекрестный mount между контейнерами?
А зачем Вы делаете перекрестный mount между контейнерами?
Номер бага искать лень.
Помню что открывали ребята из fastvps.
Я не делаю никаких перекрестных mount.
openvz делает не полный umount при остановке.
И «доделать» его нельзя.
Только перезапуск ноды.
Помню что открывали ребята из fastvps.
Я не делаю никаких перекрестных mount.
openvz делает не полный umount при остановке.
И «доделать» его нельзя.
Только перезапуск ноды.
Ага, тоже сталкивалась с этим на ядре пятой шапки. На шестой шапке проблема встречаться перестала (во всяком случае я не сталкивалась).
Это не баг, это возможности Linux ядра. Дело в том, что процессы в статусе D линукс ядро, по команде kill -9 $PID, научилось убивать не сразу.
Сейчас уже умеет :)
В общем, мимо кассы.
Это не баг, это возможности Linux ядра. Дело в том, что процессы в статусе D линукс ядро, по команде kill -9 $PID, научилось убивать не сразу.
Сейчас уже умеет :)
В общем, мимо кассы.
Речь о 2.6.32.
Блокирующие процессы не убиваются.
Проблема ядерная.
Так что мимо кассы вы.
Блокирующие процессы не убиваются.
Проблема ядерная.
Так что мимо кассы вы.
в Bugzilla OpenVZ есть несколько багов с DeadLock. Сейчас они все закрыты, кроме 2156 (его пометили как Dublicate 2110)
Причем у меня это проблема не наблюдается.
Судя по всему, мы, возможно, о разных проблемах, которые выглядят одинаково.
Разработчики вот патч написали для тестового ядра :) Скоро исправят в production ядре. Баги есть везде, главное, что бы их исправляли.
Причем у меня это проблема не наблюдается.
Судя по всему, мы, возможно, о разных проблемах, которые выглядят одинаково.
Разработчики вот патч написали для тестового ядра :) Скоро исправят в production ядре. Баги есть везде, главное, что бы их исправляли.
У кого-то есть желание тестить баги на живых клиентах?
XEN 4.1 работает как часы.
XEN 4.2 также на тестовом проблем не показывает, но на продакт пока не ставим.
Частые обновления ядра на ноде — зло.
Конечно если вам не жалко свои нервы и своих клиентов… Кактус вас ждет…
XEN 4.1 работает как часы.
XEN 4.2 также на тестовом проблем не показывает, но на продакт пока не ставим.
Частые обновления ядра на ноде — зло.
Конечно если вам не жалко свои нервы и своих клиентов… Кактус вас ждет…
У _меня_ нет этой проблемы. У кого есть, могут откатиться, поискав непроблемное ядрышко, или дождаться фикса.
И еще: у меня нет опыта работы с Xen-хостингом в качестве администратора. Я использовала до трех Xen нод и дешевую хранилку для офисной виртуализации, и low-cost лотерею с drbd и двумя нодами под Центосью, поэтому сразу вспомнила о багах паравиртуализированных систем.
Уверена, что приверженец VmWare, который использовал Xen, назвал бы Вам кучу проблем Xen-а на больших инсталляциях!
Да тут на ХабраХабре и были такие топики.
Ваше заявление о том, что с Xen нет и никогда не бывает, и не может быть никаких проблем и глюков, оно очень спорное: баги бывают даже в прошивках коммутаторов Циски.
Мне тяжело его опровергнуть, так как я не видела большого Xen хостинга.
А Вы явно предвзяты. Вот, другой администратор OVZ, Xen, LXC не настолько ненавидит OVZ, как Вы :)
Уверена, что приверженец VmWare, который использовал Xen, назвал бы Вам кучу проблем Xen-а на больших инсталляциях!
Да тут на ХабраХабре и были такие топики.
Ваше заявление о том, что с Xen нет и никогда не бывает, и не может быть никаких проблем и глюков, оно очень спорное: баги бывают даже в прошивках коммутаторов Циски.
Мне тяжело его опровергнуть, так как я не видела большого Xen хостинга.
А Вы явно предвзяты. Вот, другой администратор OVZ, Xen, LXC не настолько ненавидит OVZ, как Вы :)
Вы не объективны, т.к. вы не работали с Xen.
Я не предвзят т.к. в одинаковом количестве содержу и XEN и OVZ ноды, также есть LXC для работы внутренних систем. но это другая история.
Я не предвзят т.к. в одинаковом количестве содержу и XEN и OVZ ноды, также есть LXC для работы внутренних систем. но это другая история.
Я работала с Xen, но на не массивных инсталляциях. OpenVZ, и особенно Virtuozzo, администрировала на массивных (более ста физических машин).
Так же я видела Xen-хостинги у моих собственных клиентов (когда занималась аутсорсингом), дешевые и не очень.
Так что с Вашим обвинением в необъективности несогласна :)
Качество Xen-VPS всегда так хорошо скачет вверх, когда за 256мегабайт ОЗУ на сервере в Европе просят от 20 долларов.
Обычно у хостера в этом случае хватает денег на SAN.
Так же я видела Xen-хостинги у моих собственных клиентов (когда занималась аутсорсингом), дешевые и не очень.
Так что с Вашим обвинением в необъективности несогласна :)
Качество Xen-VPS всегда так хорошо скачет вверх, когда за 256мегабайт ОЗУ на сервере в Европе просят от 20 долларов.
Обычно у хостера в этом случае хватает денег на SAN.
а чекпоинтов нет =(
> Вы серьезно? Может и jails гипервизор, и chroot? Если Вы в этом уверены, сделайте доброе дело, исправьте википедию!
Даже исправлять ничего не буду — en.wikipedia.org/wiki/Hypervisor
Гипервизор — это сущность, которая создаёт и управляет виртуальными машинами. Способ реализации не важен.
Chroot — нет, там ничего не виртуализируется. Jail — да, гипервизор в чистом виде, с виртуализацией сети, стораджа (если нужно), виртуализацией CPU (проброс 2х ядер CPU из 32х — это тоже своего рода виртуализация, а не просто ограничение по ресурсам).
Даже исправлять ничего не буду — en.wikipedia.org/wiki/Hypervisor
Гипервизор — это сущность, которая создаёт и управляет виртуальными машинами. Способ реализации не важен.
Chroot — нет, там ничего не виртуализируется. Jail — да, гипервизор в чистом виде, с виртуализацией сети, стораджа (если нужно), виртуализацией CPU (проброс 2х ядер CPU из 32х — это тоже своего рода виртуализация, а не просто ограничение по ресурсам).
Объясните мне пожалуйста, чем принципиально отличается chroot от OpenVZ, jails, или Solaris Zones?
А в chroot как раз виртуализируется файловая система :)))
Это называется name spaces: может быть на файловую систему, как у jails, а может быть и на сетевой стек, iptables, ppid процессов, и тд.
Кстати, как там с виртуализацией сетевого стека в LXC? Все так же кисло как и три года назад? А iptables никогда не будет?
А в chroot как раз виртуализируется файловая система :)))
Это называется name spaces: может быть на файловую систему, как у jails, а может быть и на сетевой стек, iptables, ppid процессов, и тд.
Кстати, как там с виртуализацией сетевого стека в LXC? Все так же кисло как и три года назад? А iptables никогда не будет?
> Объясните мне пожалуйста, чем принципиально отличается chroot от OpenVZ, jails, или Solaris Zones?
В chroot не виртуализируются устройства. Доступ к физическим ресурсам просто «ограничивается». Да и не я придумал, что chroot — не гипервизор =)
В openvz есть simfs, отдельные сетевые устройства, уровень абстракции вокруг виртуальной памяти (адреса памяти отличаются от тех, которые у того же блока памяти на dom0) и так далее. Вполне себе взрослый гипервизор.
В jail — аналогично. Про солярку ничего не скажу.
> Кстати, как там с виртуализацией сетевого стека в LXC?
А что с ним было не так? Классический вариант — бридж на dom0 + eth в виртуалке никуда не делся. Macvlan тоже можно использовать. Netfilter у каждого контейнера независим (конечно, conntrack включенный на одной виртуалке включит его их и на остальных, но это последствия shared-ядра). А правила писать можно сколько влезет.
Там главные проблемы вокруг /proc сейчас. Его никто не хочет виртуализировать (дорого и медленно), а пересечения /proc разных виртуалок дают кучу неприятных моментов — от проблем с sysctl до возможности пострейсить или по-gdbшить чужой процесс, если знать pid.
В chroot не виртуализируются устройства. Доступ к физическим ресурсам просто «ограничивается». Да и не я придумал, что chroot — не гипервизор =)
В openvz есть simfs, отдельные сетевые устройства, уровень абстракции вокруг виртуальной памяти (адреса памяти отличаются от тех, которые у того же блока памяти на dom0) и так далее. Вполне себе взрослый гипервизор.
В jail — аналогично. Про солярку ничего не скажу.
> Кстати, как там с виртуализацией сетевого стека в LXC?
А что с ним было не так? Классический вариант — бридж на dom0 + eth в виртуалке никуда не делся. Macvlan тоже можно использовать. Netfilter у каждого контейнера независим (конечно, conntrack включенный на одной виртуалке включит его их и на остальных, но это последствия shared-ядра). А правила писать можно сколько влезет.
Там главные проблемы вокруг /proc сейчас. Его никто не хочет виртуализировать (дорого и медленно), а пересечения /proc разных виртуалок дают кучу неприятных моментов — от проблем с sysctl до возможности пострейсить или по-gdbшить чужой процесс, если знать pid.
Мне все-таки нравится определение, что гипервизор это (микро)ядро, крутящееся на dom0, и запускающее гостевые ядра.
В этом и есть принципиальная разница между Os-level virtualization (chroot, jail, openvz, solaris zones, etc) и гипервизоров (Xen,KVM, Vmware, Hyper-V)
а что касается того, что chroot не виртуализирует devfs и proc, а должен был? LXC тоже не виртуализирует, например, таблицы iptables, просто chroot такой вот примитивный контейнер.
В этом и есть принципиальная разница между Os-level virtualization (chroot, jail, openvz, solaris zones, etc) и гипервизоров (Xen,KVM, Vmware, Hyper-V)
а что касается того, что chroot не виртуализирует devfs и proc, а должен был? LXC тоже не виртуализирует, например, таблицы iptables, просто chroot такой вот примитивный контейнер.
> Мне все-таки нравится определение, что гипервизор это (микро)ядро, крутящееся на dom0, и запускающее гостевые ядра.
Это определение так называемого «native hypervisor». Собственно, в той же статье про это и написано. Openvz — hosted hypervisor. Просто другой тип виртуализации, но это всё ещё виртуализация. Более того, есть ещё виртуализация как сущность, а не как виртуализация ОС (java, например). Но там действительно нет гипервизора (точнее, принято так считать).
Ну то есть гипервизор — это не какое-то ядро, а просто сущность, управляющая гостевыми машинами. И запускает она не ядра, а именно машины.
> а что касается того, что chroot не виртуализирует devfs и proc, а должен был? LXC тоже не виртуализирует, например, таблицы iptables, просто chroot такой вот примитивный контейнер.
chroot (без всяких патчей, само собой — одна пачка таких патчей ныне называется openvz, а другая — lxc) — не виртуализирует вообще ничего. LXC же виртуализирует что-то (и iptables, кстати). В частности, lxc не виртуализирует сторадж никоим образом (это отдаётся на откуп dom0 — чаще всего это lvm тома), зато сеть — вполне. К тому же, адреса памяти всё же отличаются, нельзя просто взять и сходить в чужую =) В chroot — вполне.
Это определение так называемого «native hypervisor». Собственно, в той же статье про это и написано. Openvz — hosted hypervisor. Просто другой тип виртуализации, но это всё ещё виртуализация. Более того, есть ещё виртуализация как сущность, а не как виртуализация ОС (java, например). Но там действительно нет гипервизора (точнее, принято так считать).
Ну то есть гипервизор — это не какое-то ядро, а просто сущность, управляющая гостевыми машинами. И запускает она не ядра, а именно машины.
> а что касается того, что chroot не виртуализирует devfs и proc, а должен был? LXC тоже не виртуализирует, например, таблицы iptables, просто chroot такой вот примитивный контейнер.
chroot (без всяких патчей, само собой — одна пачка таких патчей ныне называется openvz, а другая — lxc) — не виртуализирует вообще ничего. LXC же виртуализирует что-то (и iptables, кстати). В частности, lxc не виртуализирует сторадж никоим образом (это отдаётся на откуп dom0 — чаще всего это lvm тома), зато сеть — вполне. К тому же, адреса памяти всё же отличаются, нельзя просто взять и сходить в чужую =) В chroot — вполне.
chroot виртуализирует пути в файловой системе :)
как lxc и ovz имеют init с правильным ppid, и / в котором есть и /bin и /var, так и в chroot есть /bin (но ppid, таблиц маршрутизации и подобного нет)
как lxc и ovz имеют init с правильным ppid, и / в котором есть и /bin и /var, так и в chroot есть /bin (но ppid, таблиц маршрутизации и подобного нет)
> chroot виртуализирует пути в файловой системе :)
Гм. Не совсем. Он его подменяет для всех системных вызовов. Так что это филькина грамота, если внутри chroot'a вы root.
Кстати, почитал умности (или неумности, уж слишком скользкая тема) всякие.
Ключевое отличие здесь в том, что внутри chroot вы не сможете запустить целиком гостевую ОС (и перезапускать её целиком отдельно от dom0). Это механизм виртуализации процессов по корневому каталогу, а не механизм виртуализации ОС. Как следствие — гипервизором его считать нельзя.
Гм. Не совсем. Он его подменяет для всех системных вызовов. Так что это филькина грамота, если внутри chroot'a вы root.
Кстати, почитал умности (или неумности, уж слишком скользкая тема) всякие.
Ключевое отличие здесь в том, что внутри chroot вы не сможете запустить целиком гостевую ОС (и перезапускать её целиком отдельно от dom0). Это механизм виртуализации процессов по корневому каталогу, а не механизм виртуализации ОС. Как следствие — гипервизором его считать нельзя.
Мне все же не нравится определение «гипервизор» в отношении OpenVZ/jails/Zones/etc, по тому, что и там тоже нельзя «запустить гостевую ОС целиком». В OVZ контейнере /boot например чисто декоративный… Какая это «запущенная целиком» гостевая ОС?
Не вижу разницы с chroot: в нем, зато, как и в LXC, можно запустить один бинарник :)
Не вижу разницы с chroot: в нем, зато, как и в LXC, можно запустить один бинарник :)
> Какая это «запущенная целиком» гостевая ОС?
Её можно включить целиком и выключить целиком. И есть сущность, которая этим занимается. Да и, кстати, исходя из определения ОС — загрузчик в ней как раз и не обязателен. Ядро обязательно — да. Но никто и не говорит, что ядро должно быть выделенным ^_^
> Не вижу разницы с chroot: в нем, зато, как и в LXC, можно запустить один бинарник :)
Но в LXC можно запустить целую ОС. А в chroot — нельзя. А ещё нельзя одним махом поубивать все процессы, запущенные в chroot (в виде демонов). Для этого нужно что-то написать. Вот когда появится сущность, которая будет сама следить за тем, что запустили в чрутах и уметь убивать всё это — можно будет говорить о зарождении гипервизора. Но уже есть LXC — он и есть гипервизор для chroot-ов.
Её можно включить целиком и выключить целиком. И есть сущность, которая этим занимается. Да и, кстати, исходя из определения ОС — загрузчик в ней как раз и не обязателен. Ядро обязательно — да. Но никто и не говорит, что ядро должно быть выделенным ^_^
> Не вижу разницы с chroot: в нем, зато, как и в LXC, можно запустить один бинарник :)
Но в LXC можно запустить целую ОС. А в chroot — нельзя. А ещё нельзя одним махом поубивать все процессы, запущенные в chroot (в виде демонов). Для этого нужно что-то написать. Вот когда появится сущность, которая будет сама следить за тем, что запустили в чрутах и уметь убивать всё это — можно будет говорить о зарождении гипервизора. Но уже есть LXC — он и есть гипервизор для chroot-ов.
>Там главные проблемы вокруг /proc сейчас.
кстати, /proc нынче в lxc тоже изолирован. даже всякие conntrack hashsize )))
кстати, /proc нынче в lxc тоже изолирован. даже всякие conntrack hashsize )))
>Кстати, как там с виртуализацией сетевого стека в LXC?
там как раз всё хорошо. я даже статью писал на эту тему.
что вы хотели сказать фразой «всё кисло»?
вот сейчас ipset не умеет жить в неймспейсах и его к этому приучают.
iptables уже достаточно давно умеет.
в ethtool добавили флажок netns-local, показывающий можно ли интерфейс отдать в неймспейс(например, чтобы так не сделали с lo).
в iw есть уже достаточно давно phy set netns, позволяющий закинуть беспроводной интерфейс внутрь контейнера.
через ip netns exec можно запустить pppd(можно разные ppp терминировать в контейнере).
а теперь вопрос. вот у вас есть ядро с openvz и вы хотите туда ipset.
сколько боли и страданий доставит процесс добавления?
там как раз всё хорошо. я даже статью писал на эту тему.
что вы хотели сказать фразой «всё кисло»?
вот сейчас ipset не умеет жить в неймспейсах и его к этому приучают.
iptables уже достаточно давно умеет.
в ethtool добавили флажок netns-local, показывающий можно ли интерфейс отдать в неймспейс(например, чтобы так не сделали с lo).
в iw есть уже достаточно давно phy set netns, позволяющий закинуть беспроводной интерфейс внутрь контейнера.
через ip netns exec можно запустить pppd(можно разные ppp терминировать в контейнере).
а теперь вопрос. вот у вас есть ядро с openvz и вы хотите туда ipset.
сколько боли и страданий доставит процесс добавления?
>Кстати, в LXC нет аналога не только vzswap
во-первых vswap
во-вторых:
отсюда
vswap врядли примут в мейнлайн, потому как есть более элегантные вещи вроде compcache
которые уже там есть(в 2.6.34 добавлили).
используя лимиты на число страниц в свопе можно добиваться похожего поведения.
>Без этого, а так же без Live Migration он не нужен.
чекпойтинг. в него всё упирается. по факту, live migration в openvz — это checkpoint, передача файла с образом и restore.
сейчас это делают силами criu. в ядре уже почти всё для этого есть.
во-первых vswap
во-вторых:
Про OpenVZ vs LXC
Существует несколько разных людей и команд, которые заинтересованы в том, чтобы в Линуксе (в мейнстрим-ядре) появились контейнеры и вся сопутствующая функциональность. Одна из таких команд — OpenVZ. Как я выше написал, мы самбитим патчи в мейнстрим, иногда их даже принимают (какое-то время Parallels даже был в top10 linux contributing companies). Одна из других команд — это ребята из IBM (Франция, Индия, США). Их много и они упорные, и кроме некоторых патчей в ядро, они пишут свои утилиты. Вот LXC — это то, что есть в менйстримном ядре (включая патчи от OpenVZ, IBM и других людей типа Эрика Бидермана), плюс эти самые lxc утилиты. В противоположность, OpenVZ — это то, что в мейнстримном ядре, плюс наши патчи, плюс наши утилиты. Что из этого всего следует — решать вам.
То есть, из этого следует, что не надо противопоставлять LXC и OpenVZ. По сути, это взаимопроникающие вещи, просто LXC более work in progress, а OpenVZ — готовое решение.
Про портирование на новые ядра — выше вроде я описал. Нельзя сказать, что сложность падает — скорее, просто объём портируемого кода уменьшается.
отсюда
vswap врядли примут в мейнлайн, потому как есть более элегантные вещи вроде compcache
которые уже там есть(в 2.6.34 добавлили).
используя лимиты на число страниц в свопе можно добиваться похожего поведения.
>Без этого, а так же без Live Migration он не нужен.
чекпойтинг. в него всё упирается. по факту, live migration в openvz — это checkpoint, передача файла с образом и restore.
сейчас это делают силами criu. в ядре уже почти всё для этого есть.
>Кстати, в LXC нет аналога не только vzswap
во-первых vswap
во-вторых:
отсюда
vswap врядли примут в мейнлайн, потому как есть более элегантные вещи вроде compcache
которые уже там есть(в 2.6.34 добавлили).
используя лимиты на число страниц в свопе можно добиваться похожего поведения.
>Без этого, а так же без Live Migration он не нужен.
чекпойтинг. в него всё упирается. по факту, live migration в openvz — это checkpoint, передача файла с образом и restore.
сейчас это делают силами criu. в ядре уже почти всё для этого есть.
во-первых vswap
во-вторых:
Про OpenVZ vs LXC
Существует несколько разных людей и команд, которые заинтересованы в том, чтобы в Линуксе (в мейнстрим-ядре) появились контейнеры и вся сопутствующая функциональность. Одна из таких команд — OpenVZ. Как я выше написал, мы самбитим патчи в мейнстрим, иногда их даже принимают (какое-то время Parallels даже был в top10 linux contributing companies). Одна из других команд — это ребята из IBM (Франция, Индия, США). Их много и они упорные, и кроме некоторых патчей в ядро, они пишут свои утилиты. Вот LXC — это то, что есть в менйстримном ядре (включая патчи от OpenVZ, IBM и других людей типа Эрика Бидермана), плюс эти самые lxc утилиты. В противоположность, OpenVZ — это то, что в мейнстримном ядре, плюс наши патчи, плюс наши утилиты. Что из этого всего следует — решать вам.
То есть, из этого следует, что не надо противопоставлять LXC и OpenVZ. По сути, это взаимопроникающие вещи, просто LXC более work in progress, а OpenVZ — готовое решение.
Про портирование на новые ядра — выше вроде я описал. Нельзя сказать, что сложность падает — скорее, просто объём портируемого кода уменьшается.
отсюда
vswap врядли примут в мейнлайн, потому как есть более элегантные вещи вроде compcache
которые уже там есть(в 2.6.34 добавлили).
используя лимиты на число страниц в свопе можно добиваться похожего поведения.
>Без этого, а так же без Live Migration он не нужен.
чекпойтинг. в него всё упирается. по факту, live migration в openvz — это checkpoint, передача файла с образом и restore.
сейчас это делают силами criu. в ядре уже почти всё для этого есть.
criu проект команды OpenVZ/Virtuozzo, впрочем Вы это наверняка знаете.
Они все делают правильно: уменьшают размер патча на ядро, что бы пропал главный аргумент против OpenVZ, что используется патченный кёрнель.
Они все делают правильно: уменьшают размер патча на ядро, что бы пропал главный аргумент против OpenVZ, что используется патченный кёрнель.
вы так говорите, словно есть какая-то конфронтация с openvz.
по факту, openvz в rhel6 использует ту же инфраструктуру ядра, что и lxc.
более того, k001 писал про vzctl, который ограниченно поддерживает ядра 3.х и не требует патчей.
по факту, openvz в rhel6 использует ту же инфраструктуру ядра, что и lxc.
более того, k001 писал про vzctl, который ограниченно поддерживает ядра 3.х и не требует патчей.
вы так говорите, словно есть какая-то конфронтация с openvz.
в OpenVZ вике даже есть статья такая:
wiki.openvz.org/Vzctl_for_upstream_kernel
Конфронтация есть разве что в головах администраторов. Я пыталась донести мысль, которую разделяют и разработчики, что OVZ более законченное решение.
А вообще топик не об этом же. Он о том, что гипервизоры рулят на дорогом оборудовании, а дешевые Xen-хостеры очень много лукавят (особенно, про «честность» Xen и оверселлинг OVZ), ну и о том, что OVZ заслуживает лучшего имиджа, чем у него сложился на хабра-хабре!
>Он о том, что гипервизоры рулят на дорогом оборудовании
все эти технологии рулят на хорошем железе.
просто у вас вместо взвешенной аналитики получилась весьма сумбурная статья с весьма странной аргументацией.
вместо того, чтобы более-менее разобрать типовые сценарии вы выдвинули ряд весьма спорные тезисы и спровоцировали вполне обоснованную критику.
вот смотрите:
я никогда не возьму xen для задач с более-менее серьезным i/o (и pv-драйвера тут не спасают). т.е. раздача статического контента из виртуалки — это утопия.
при этом, я бы взял xen/kvm если мне нужно внутрь гостя закинуть какое-то pci-устройство(допустим, у нас какое-то важное legacy-устройство с драйверами только под rhel3).
В конце-концов, openvz можно запустать внутри виртуалки под xen/kvm :))))
все эти технологии рулят на хорошем железе.
просто у вас вместо взвешенной аналитики получилась весьма сумбурная статья с весьма странной аргументацией.
вместо того, чтобы более-менее разобрать типовые сценарии вы выдвинули ряд весьма спорные тезисы и спровоцировали вполне обоснованную критику.
вот смотрите:
я никогда не возьму xen для задач с более-менее серьезным i/o (и pv-драйвера тут не спасают). т.е. раздача статического контента из виртуалки — это утопия.
при этом, я бы взял xen/kvm если мне нужно внутрь гостя закинуть какое-то pci-устройство(допустим, у нас какое-то важное legacy-устройство с драйверами только под rhel3).
В конце-концов, openvz можно запустать внутри виртуалки под xen/kvm :))))
>но мне больше нравится ядро RHEL6 на сервере.
оууу… следите за руками:
1) сначала их просят в багзилле: пацаны, смотрите какую клёвую штуку придумал Tom Herbert
2) потом выходит апдейт с бэкпортом rps в el6.
3) а потом выясняется, что портировали криво, а фикс тривиален
так что рассказывать про регрессии не надо )))
longterm-ядра не уступают в стабильности ядрам из el6.
оууу… следите за руками:
1) сначала их просят в багзилле: пацаны, смотрите какую клёвую штуку придумал Tom Herbert
2) потом выходит апдейт с бэкпортом rps в el6.
3) а потом выясняется, что портировали криво, а фикс тривиален
так что рассказывать про регрессии не надо )))
longterm-ядра не уступают в стабильности ядрам из el6.
Другие примеры, уже про регрессии long ядер, наверняка есть. Phoronix вот постоянно публикует, и в чем-то новые ядра всегда чуть тормознее, чем более старые (а в чем-то быстрее).
У RHEL, имхо, более гладко с этим!
А еще, не забывайте, что железячным вендорам серверного оборудования иногда тяжело поддерживать драйвер в main line, проще один раз в несколько лет написать под RHEL.
У RHEL, имхо, более гладко с этим!
А еще, не забывайте, что железячным вендорам серверного оборудования иногда тяжело поддерживать драйвер в main line, проще один раз в несколько лет написать под RHEL.
>Другие примеры, уже про регрессии long ядер, наверняка есть.
вот понимаете, разница между тем что написали вы и я — наличие конкретики.
>Phoronix вот постоянно публикует, и в чем-то новые ядра всегда чуть тормознее, чем более старые (а в чем-то быстрее).
во-первых, в приличном обществе за упоминание тестов фороникса бьют канделябром.
во-вторых, что мешает сделать собственные тесты?
в-третьих, что делать, когда поддержка нужного вам железа живёт вне мейнлайна в ветках разработчиков?
и собирается исключитльно на свежих ядрах.
моё железо(dvb-карточки) не поддерживается в rhel6, но поддерживается и прекрасно работает в 3.4-longterm за исключением одной модели(драйвер ddbridge). бэкпортировать это в 3.4 было совсем несложно.
вообщем, сам процесс разработки слабо отличается у longterm и rhel-ядер.
т.е. сначала release, а потом: fix,fix,fix…
только число тестеров для longterm-ядер больше(а не только сотрудники redhat)
>А еще, не забывайте, что железячным вендорам серверного оборудования иногда тяжело поддерживать драйвер в main line, проще один раз в несколько лет написать под RHEL.
упомянутый мной e1000e есть в мейнлайне. только разного уровня свежести.
вот понимаете, разница между тем что написали вы и я — наличие конкретики.
>Phoronix вот постоянно публикует, и в чем-то новые ядра всегда чуть тормознее, чем более старые (а в чем-то быстрее).
во-первых, в приличном обществе за упоминание тестов фороникса бьют канделябром.
во-вторых, что мешает сделать собственные тесты?
в-третьих, что делать, когда поддержка нужного вам железа живёт вне мейнлайна в ветках разработчиков?
и собирается исключитльно на свежих ядрах.
моё железо(dvb-карточки) не поддерживается в rhel6, но поддерживается и прекрасно работает в 3.4-longterm за исключением одной модели(драйвер ddbridge). бэкпортировать это в 3.4 было совсем несложно.
вообщем, сам процесс разработки слабо отличается у longterm и rhel-ядер.
т.е. сначала release, а потом: fix,fix,fix…
только число тестеров для longterm-ядер больше(а не только сотрудники redhat)
>А еще, не забывайте, что железячным вендорам серверного оборудования иногда тяжело поддерживать драйвер в main line, проще один раз в несколько лет написать под RHEL.
упомянутый мной e1000e есть в мейнлайне. только разного уровня свежести.
>LVM том вы тоже не сможете оверселлить. Это не промышленная SAN с дедубликацией и даже не ZFS.
lvm может быть организован на lun, полученном по iscsi со стораджа с zfs. так что я бы не был столь категоричен.
>LVM том Вы сможете сделать для VPS клиента меньше только при смене клиентом тарифного плана, и продать то место, что не не использует, не выйдет.
thin provisioning в lvm есть.
>Ладно, если у Вас SATA диски, а если сверхдорогие SSD? Или дороговатые SAS?
если даже в рамках локальных дисков, то есть bcache.
lvm может быть организован на lun, полученном по iscsi со стораджа с zfs. так что я бы не был столь категоричен.
>LVM том Вы сможете сделать для VPS клиента меньше только при смене клиентом тарифного плана, и продать то место, что не не использует, не выйдет.
thin provisioning в lvm есть.
>Ладно, если у Вас SATA диски, а если сверхдорогие SSD? Или дороговатые SAS?
если даже в рамках локальных дисков, то есть bcache.
>LVM том вы тоже не сможете оверселлить. Это не промышленная SAN с дедубликацией и даже не ZFS.
lvm может быть организован на lun, полученном по iscsi со стораджа с zfs. так что я бы не был столь категоричен.
>LVM том Вы сможете сделать для VPS клиента меньше только при смене клиентом тарифного плана, и продать то место, что не не использует, не выйдет.
thin provisioning в lvm есть.
>Ладно, если у Вас SATA диски, а если сверхдорогие SSD? Или дороговатые SAS?
если даже в рамках локальных дисков, то есть bcache.
lvm может быть организован на lun, полученном по iscsi со стораджа с zfs. так что я бы не был столь категоричен.
>LVM том Вы сможете сделать для VPS клиента меньше только при смене клиентом тарифного плана, и продать то место, что не не использует, не выйдет.
thin provisioning в lvm есть.
>Ладно, если у Вас SATA диски, а если сверхдорогие SSD? Или дороговатые SAS?
если даже в рамках локальных дисков, то есть bcache.
>LVM том вы тоже не сможете оверселлить. Это не промышленная SAN с дедубликацией и даже не ZFS.
lvm может быть организован на lun, полученном по iscsi со стораджа с zfs. так что я бы не был столь категоричен.
>LVM том Вы сможете сделать для VPS клиента меньше только при смене клиентом тарифного плана, и продать то место, что не не использует, не выйдет.
thin provisioning в lvm есть.
>Ладно, если у Вас SATA диски, а если сверхдорогие SSD? Или дороговатые SAS?
если даже в рамках локальных дисков, то есть bcache.
lvm может быть организован на lun, полученном по iscsi со стораджа с zfs. так что я бы не был столь категоричен.
>LVM том Вы сможете сделать для VPS клиента меньше только при смене клиентом тарифного плана, и продать то место, что не не использует, не выйдет.
thin provisioning в lvm есть.
>Ладно, если у Вас SATA диски, а если сверхдорогие SSD? Или дороговатые SAS?
если даже в рамках локальных дисков, то есть bcache.
Еще чаще возникает необходимость балансировки нагрузки: на одной ноде VPS продали слишком много, а на другой слишком мало. дешевые Xen хостеры вынуждены или выключать часть клиентов, и перевозить их offline на недогруженный сервер, или не обращать внимание на жалобы клиентов на перегруженном сервере: авось кто-то уйдет, и тормозить у остальных VPS перестанут!Про Live Migration на Xen и KVM автор не знает? Между тем очень просто всё настраивается даже на арендованном хецнеровском железе.
Вот и я о том же. :)
Автор не работал с этим, и не может себе представить насколько это удобно по сравнению с openvz.
Автор не работал с этим, и не может себе представить насколько это удобно по сравнению с openvz.
Что удобнее? DRBD что ли? А Если у Вас есть SAN, то это совсем другая ценовая категория VPS!
с каких пор ещё один сервер с пачкой дисков, zfs и iscsi-таргетом — это сразу другая ценовая категория?
3-4U x86 сервер под сторадж это категорически другая ценовая категория. Он стоит как несколько 1U нод, на которых можно запускать OpenVZ, и в которых уже есть слоты для дисков.
Которая приближается по цене к самым дешевым «мелкобрендовым» полочкам с дисками.
Мы с 4U машинами на моей текущей работе с ZFS уже намучались под почтовые стораджи :(
Насколько лучше работает старый-старый нетап, Вы себе представить не можете!
Кстати, если расскажите, как победить на ZFS тормоза при заполнении, я буду Вам очень благодарна! Если использовать заполненную процентов на 70-80, или даже наполовину, что бы i/o не проседало, гигабайт получается слишком дорогим, и сравнимым по стоимости с мелкобрендовыми «хранилками»
Которая приближается по цене к самым дешевым «мелкобрендовым» полочкам с дисками.
Мы с 4U машинами на моей текущей работе с ZFS уже намучались под почтовые стораджи :(
Насколько лучше работает старый-старый нетап, Вы себе представить не можете!
Кстати, если расскажите, как победить на ZFS тормоза при заполнении, я буду Вам очень благодарна! Если использовать заполненную процентов на 70-80, или даже наполовину, что бы i/o не проседало, гигабайт получается слишком дорогим, и сравнимым по стоимости с мелкобрендовыми «хранилками»
>3-4U x86 сервер под сторадж это категорически другая ценовая категория. Он стоит как несколько 1U нод, на которых можно запускать OpenVZ, и в которых уже есть слоты для дисков.
нормальный 1U стоит ~ 2500$. дисковая полка на 36 дисков — где-то столько же (не сочтите за рекламу, первое что в гугле нашлось).
при этом там 2 блока питания и нормальное охлаждение. другое дело, что это за собой потянет карточки на 10GE и наличие свитча хотя бы с двумя портами на 10GE.
>Кстати, если расскажите, как победить на ZFS тормоза при заполнении
читали?
ну и паттерн использования, условия и проч-проч. это ж не лечение по фотографии.
да и лучше вам этот вопрос задать отдельно в Q&A.
нормальный 1U стоит ~ 2500$. дисковая полка на 36 дисков — где-то столько же (не сочтите за рекламу, первое что в гугле нашлось).
при этом там 2 блока питания и нормальное охлаждение. другое дело, что это за собой потянет карточки на 10GE и наличие свитча хотя бы с двумя портами на 10GE.
>Кстати, если расскажите, как победить на ZFS тормоза при заполнении
читали?
ну и паттерн использования, условия и проч-проч. это ж не лечение по фотографии.
да и лучше вам этот вопрос задать отдельно в Q&A.
нормальный 1U стоит ~ 2500$. дисковая полка на 36 дисков
Так это полка, а не сервер. Полки (DAS) мне самой нравятся, на них классно бюджетные кластеры городить без всяких iscsi и тем более FC.
читали?
Да. Не помогает :( Ладно, Вы правы, это отдельный вопрос.
>Так это полка, а не сервер. Полки (DAS) мне самой нравятся, на них классно бюджетные кластеры городить без всяких iscsi и тем более FC.
ну так берёте полку, сервер с контроллером и вперед. в чём проблема?
а зачем вам FC? такие фантастические требования к латентности дисков?
если так, можно взять FCoE, дешевле будет.
ну так берёте полку, сервер с контроллером и вперед. в чём проблема?
а зачем вам FC? такие фантастические требования к латентности дисков?
если так, можно взять FCoE, дешевле будет.
затем, что zfs тормозит :(
Полочка хороша подключить ее к двум серверам, сделать поверх нее кластерный сlvm и гонять между ними виртуалки на KVM или xen. А вот под хранилище уже не очень.
Даже древний-древний нетап, отдающий директории с миллионами файлов (Maildir) просто несравненно быстрее, чем ZFS. ZFS еще хоть как-то справляется, пока занято половина объема, как приближается к 90%, начинается коллапс :(
Мы на допотопный нетап сложили самые страшные Maildir'ы
Полочка хороша подключить ее к двум серверам, сделать поверх нее кластерный сlvm и гонять между ними виртуалки на KVM или xen. А вот под хранилище уже не очень.
Даже древний-древний нетап, отдающий директории с миллионами файлов (Maildir) просто несравненно быстрее, чем ZFS. ZFS еще хоть как-то справляется, пока занято половина объема, как приближается к 90%, начинается коллапс :(
Мы на допотопный нетап сложили самые страшные Maildir'ы
zfs — это инструмент.
наличие у человека дома фортепиано не делает его виртуозом, как и наличие спортивного болида в гараже не делает гонщиком.
у некоторых людей используется хитрый бутерброд из 3х уровней: sata-диски => sas-диски => ssd
+ там ещё много памяти.
zfs вообще её хочет примерно 1Гб на 1Тб места и очень любит cpu.
Тутубалин про это пишет
даже с цифрами
т.е. 76 крутилок и 16 — касаются кешей, а 3шт — zil.
наличие у человека дома фортепиано не делает его виртуозом, как и наличие спортивного болида в гараже не делает гонщиком.
у некоторых людей используется хитрый бутерброд из 3х уровней: sata-диски => sas-диски => ssd
+ там ещё много памяти.
zfs вообще её хочет примерно 1Гб на 1Тб места и очень любит cpu.
Тутубалин про это пишет
даже с цифрами
# modinfo zfs | grep parm | wc -l
76
# modinfo zfs | grep parm | grep arc | wc -l
16
т.е. 76 крутилок и 16 — касаются кешей, а 3шт — zil.
Для Live Migration на Xen Вам нужно общее блочное устройство. Если им будет drbd, то у Вас будет или просадка производительности, или асинхронная синхронизация между нодами, которая чревата потерями данных при hard reset.
Для KVM уже есть Live Migration без СХД :) Но в продакшен ее пока не видно: в RHEL6 ее еще нет, есть в Fedora (насчет Debian и Ubuntu LTS не знаю)
Для KVM уже есть Live Migration без СХД :) Но в продакшен ее пока не видно: в RHEL6 ее еще нет, есть в Fedora (насчет Debian и Ubuntu LTS не знаю)
Распределённое хранилище — скорее благо, чем зло, серьёзно поднимает отказоустойчивость. Учитывая, что трафик внутри дц бесплатен, проблемы не вижу.
Распределенное хранилище это благо :) Особенно если это какой-то Xyratex бюджетный хотя бы…
А вот насчет drbd это уже очень спорно, особенно для хостинга. Вы отдаете себе отчет, что при асинхронной репликации у Вас может быть потеря данных? Если Вы кластеризируете собственный сервис (то есть вы администратор сервиса!) вы, скажем, будете использовать в MySQL innodb, а если Вы не админите гостевую систему, и там у клиента MyISAM?
А вот насчет drbd это уже очень спорно, особенно для хостинга. Вы отдаете себе отчет, что при асинхронной репликации у Вас может быть потеря данных? Если Вы кластеризируете собственный сервис (то есть вы администратор сервиса!) вы, скажем, будете использовать в MySQL innodb, а если Вы не админите гостевую систему, и там у клиента MyISAM?
А что мешает хранилище организовать на GlusterFS какой-нибудь? Данные терять не должно, единственное, малость производительность всё же просядет.
Вот-вот. А на OpenVZ с локальным raid массивом будет Live migration, и быстрые диски по тому, что не будет оверхеда от лишних, ненужных вещей для дешевых VPS вроде drbd и тем более GlusterFS, и еще из-за vzswap!
High Avaible для дешевых VPS как бы излишне, это услуга совсем другого ценового диапазона. Но если очень хочется, то кластер можно сделать и на OpenVZ: монтировать /vz на ноды с полки с дисками, и запускать VPS-ки с ocfs2. У Вас тоже будет HA в дополнение к Live Migration(а может и не быть! У Вас есть выбор! в Xen его нет!)
Я считаю, что Xen VPS, виртуалки которой это луны на дисковой полочке (или даже файлы, полочки с дисками очень быстрые, зато файлы удобнее) гораздо лучше, чем OpenVZ впс-ки.
Но дешевые OpenVZ VPS лучше дешевых Xen/KVM/Hyper-V(если гостевая ОС Линукс) за счет Live Migration и более быстрой дисковой подсистемы
High Avaible для дешевых VPS как бы излишне, это услуга совсем другого ценового диапазона. Но если очень хочется, то кластер можно сделать и на OpenVZ: монтировать /vz на ноды с полки с дисками, и запускать VPS-ки с ocfs2. У Вас тоже будет HA в дополнение к Live Migration(а может и не быть! У Вас есть выбор! в Xen его нет!)
Я считаю, что Xen VPS, виртуалки которой это луны на дисковой полочке (или даже файлы, полочки с дисками очень быстрые, зато файлы удобнее) гораздо лучше, чем OpenVZ впс-ки.
Но дешевые OpenVZ VPS лучше дешевых Xen/KVM/Hyper-V(если гостевая ОС Линукс) за счет Live Migration и более быстрой дисковой подсистемы
Все же в OpenVZ не полноценный Live Migration, там просто холодная и горячая виртуализация.
При чем вовремя горячей синхронизации виртуалка ставится на паузу пока rsync засинхронизируется.
А на большом количестве файлов это может занимать минуты.
А ведь еще ОЗУ надо перекинуть, что тоже время.
Можно с таким же успехом мигрировать XEN виртуалки в несколько проходов.
Никакого отличия.
При чем вовремя горячей синхронизации виртуалка ставится на паузу пока rsync засинхронизируется.
А на большом количестве файлов это может занимать минуты.
А ведь еще ОЗУ надо перекинуть, что тоже время.
Можно с таким же успехом мигрировать XEN виртуалки в несколько проходов.
Никакого отличия.
холодная и горячая виртуализация = холодная и горячая синхронизация
Вы можете написать свой скрипт, и добавить еще один rsync (я именно так и сделала)
Решение для Xen-а в студию, пожалуйста: то-то их все возили оффлайн до недавнего времени.
Решение для Xen-а в студию, пожалуйста: то-то их все возили оффлайн до недавнего времени.
Для чего делать еще один rsync?
Чтобы еще замедлить миграцию?
Остановка на время сравнение rsync-ом никуда не денется.
Для XEN:
mount -o ro…
rsync
rsync
save
scp
restore
В общем тоже что на OVZ, только плюс mount.
Чтобы еще замедлить миграцию?
Остановка на время сравнение rsync-ом никуда не денется.
Для XEN:
mount -o ro…
rsync
rsync
save
scp
restore
В общем тоже что на OVZ, только плюс mount.
Для чего делать еще один rsync?
Для того, что бы уменьшить даунтайм. C тремя rsync-ами (последний перед чекпоинтингом), если файлов не миллионы, даунтайм меньше.
Интересное у Вас решение, поставила Вам плюс. Почему его никто не использует? Вот Microsoft у себя сделала подобную миграцию для Hyper-V, может быть, есть какие-то подводные камни?
Какой скрипт, какой rsync, какое решение? Right-click, выбрали пул/сервер, выбрали SR, ушли пить кофе. Или тоже самое, но через xapi. У юзера максимум один пинг теряется — даже сессии не рвутся.
XCP 1.6 есть миграция без общего стораджа и уже в продакшене.
Чушь вы написали. Любой, кто копался поглубже с любой из систем виртуализации — засмеет вас. Особенно про «оффлайн» миграцию.
А с openvz есть куча очевидных проблем. Главная из них — openvz у всех старый (обновлять dom0-ноды действительно муторно). Про Vswap (всё же не VZswap) не все слыхали, а уж используют так вообще единицы. «Ванильное „ядро от openvz не поддерживает новые процессоры/сетевые карты/etc. Ну то есть оно подтягивается со временем, но обычно нельзя просто купить последнюю железку и запустить на ней ovz. Либо ядрышко руками собирать. С ipv6 там ппц, и проще его не использовать. Ну и так далее.
А с openvz есть куча очевидных проблем. Главная из них — openvz у всех старый (обновлять dom0-ноды действительно муторно). Про Vswap (всё же не VZswap) не все слыхали, а уж используют так вообще единицы. «Ванильное „ядро от openvz не поддерживает новые процессоры/сетевые карты/etc. Ну то есть оно подтягивается со временем, но обычно нельзя просто купить последнюю железку и запустить на ней ovz. Либо ядрышко руками собирать. С ipv6 там ппц, и проще его не использовать. Ну и так далее.
Но при том, если знать, как использовать ovz и правильно её готовить — то да, в некоторых местах оно и лучше.
От цены тут ничего не зависит. Всегда всё зависит от умений того, кто настраивал dom0-ноду. Кто-то сделает из KVM реактивный пулемет, кто-то из vbox, а кто-то даже ovz тюнить не умеет.
От цены тут ничего не зависит. Всегда всё зависит от умений того, кто настраивал dom0-ноду. Кто-то сделает из KVM реактивный пулемет, кто-то из vbox, а кто-то даже ovz тюнить не умеет.
Про Live Migration без полочки с дисками на Xen см. ветку выше.
А про драйвера, RHEL6 ядра, на которых базируется свежий OpenVZ, поддерживают все серверное железо.
Более того, все производители серверов (не PC машин, которые выдают за серверы в некоторых датацентрах, а именно серверов!) обязательно выпускают драйверы под RHEL6 и обычно RHEL5 ядра.
Под ванильные ядра линукса, с номерами 3.*, очень часто не выпускают, так что ситуация обратная той, что Вы написали.
Свежая вебкамера или новый принтер может быть действительно не будут работать под RHEL6 based OpenVZ ядром, но зачем это для хостинга??
Вы уверены, что Ваш ответ, в свою очередь не чушь? Прочитайте комментарии. Я понимаю, что топик провокационный, и на хабрахабре сложилось определенное мнение об OpenVZ: в этом и был смысл и его новизна: если не переубедить, то уговорить задуматься: а так ли все, как тут считает большинство?
А про драйвера, RHEL6 ядра, на которых базируется свежий OpenVZ, поддерживают все серверное железо.
Более того, все производители серверов (не PC машин, которые выдают за серверы в некоторых датацентрах, а именно серверов!) обязательно выпускают драйверы под RHEL6 и обычно RHEL5 ядра.
Под ванильные ядра линукса, с номерами 3.*, очень часто не выпускают, так что ситуация обратная той, что Вы написали.
Свежая вебкамера или новый принтер может быть действительно не будут работать под RHEL6 based OpenVZ ядром, но зачем это для хостинга??
Вы уверены, что Ваш ответ, в свою очередь не чушь? Прочитайте комментарии. Я понимаю, что топик провокационный, и на хабрахабре сложилось определенное мнение об OpenVZ: в этом и был смысл и его новизна: если не переубедить, то уговорить задуматься: а так ли все, как тут считает большинство?
> А про драйвера, RHEL6 ядра, на которых базируется свежий OpenVZ, поддерживают все серверное железо.
Ага. То-то у меня машинки на SB без сети наливались долгое время =)
И ещё там очень забавно работал Turbo Boost. Некоторые назвали бы это «не работал».
> Более того, все производители серверов (не PC машин, которые выдают за серверы в некоторых датацентрах, а именно серверов!) обязательно выпускают драйверы под RHEL6 и обычно RHEL5 ядра.
Вот только пока openvz-шники эти патчи вкрутят в своё ядро — железо перестаёт быть актуальным и в закупках участвует уже более новое.
> на хабрахабре сложилось определенное мнение об OpenVZ
У меня до сих пор больше сотни dom0 машин с openvz. На мнение хабрахабра в данном вопросе мне наплевать, честно =)
Нет, я не говорю что openvz плохой. Я говорю о том, что его нужно уметь готовить (и потратить на его изучение больше времени, чем на любой другой гипервизор, кроме разве что lxc). В нём неимоверно много глюков, проблем и отставаний от общего технического прогресса.
Если у вас говно мамонта ставят вместо серверов — пжалста, у вас проблем не будет. Если вы не собираетесь воевать с ipv6 — аналогично. Если у вас не процессоры серии 55хх (слава богу, они ушли) и не raid10 — вы тоже будете жить спокойно. И таких если наберется десятка два.
Ага. То-то у меня машинки на SB без сети наливались долгое время =)
И ещё там очень забавно работал Turbo Boost. Некоторые назвали бы это «не работал».
> Более того, все производители серверов (не PC машин, которые выдают за серверы в некоторых датацентрах, а именно серверов!) обязательно выпускают драйверы под RHEL6 и обычно RHEL5 ядра.
Вот только пока openvz-шники эти патчи вкрутят в своё ядро — железо перестаёт быть актуальным и в закупках участвует уже более новое.
> на хабрахабре сложилось определенное мнение об OpenVZ
У меня до сих пор больше сотни dom0 машин с openvz. На мнение хабрахабра в данном вопросе мне наплевать, честно =)
Нет, я не говорю что openvz плохой. Я говорю о том, что его нужно уметь готовить (и потратить на его изучение больше времени, чем на любой другой гипервизор, кроме разве что lxc). В нём неимоверно много глюков, проблем и отставаний от общего технического прогресса.
Если у вас говно мамонта ставят вместо серверов — пжалста, у вас проблем не будет. Если вы не собираетесь воевать с ipv6 — аналогично. Если у вас не процессоры серии 55хх (слава богу, они ушли) и не raid10 — вы тоже будете жить спокойно. И таких если наберется десятка два.
Ага. То-то у меня машинки на SB без сети наливались долгое время =)
И ещё там очень забавно работал Turbo Boost. Некоторые назвали бы это «не работал».
А можно номер бага в багзилле OVZ? И воспроизводилась ли проблема на RHEL6 ядре? Какой именно у Вас был сервер? Давайте почитаем комментарии разработчиков…
Про проблемы с Xeon 55xx я слышала, и даже с ними сталкивалась(мы дропнули закупку нод с этими CPU, и купили их, когда они существенно просели в цене). На мой взгляд, их пофиксили очень быстро, еще до того, как цена на эту линейку опустилась с маркетингово-запредельной как на новинку.
Предлагаю вспомнить о том, что смешные баги бывают и в Xen, и тем более в KVM. Вообще сложного софта без багов не бывает, мне кажется, Вы утрируете.
Предлагаю вспомнить о том, что смешные баги бывают и в Xen, и тем более в KVM. Вообще сложного софта без багов не бывает, мне кажется, Вы утрируете.
Проблему с отстреливанием 3х дисков из raid10 в 55хх вне rhel с ovz так и не починили ;)
Ну могу сейчас найти тот самый баг, но на сколько я помню, его как раз уже закрыли.
Кстати, поделитесь, а Вы что, на LXC продаете клиентам VPS-ки??
Кстати, поделитесь, а Вы что, на LXC продаете клиентам VPS-ки??
Продаю я их на kvm и openvz. На работе (суровый продакшн с десятками тысяч RPS) — lxc.
В LXC всё ещё недостаточный уровень изоляции контейнеров. Да и insmod всё ещё можно из гостя делать.
Каждому инструменту своё предназначение. У openvz оно достаточно ограниченное. И уж точно далеко от «виртуальная машина, которую ставят один раз и надолго». Я их даю клиентам, которые часто ломают свои виртуалки и просят переустановки ОС.
root@8 ~ # uptime
17:15:45 up 292 days, 11:45, 1 user, load average: 1.00, 0.77, 0.56
[root@vz1 ~]# uptime
17:07:06 up 8 days, 2:48, 1 user, load average: 14.01, 16.12, 16.93
И ведь vz1 скоро снова ребутнется, да… Ну там дней через 30-40.
В LXC всё ещё недостаточный уровень изоляции контейнеров. Да и insmod всё ещё можно из гостя делать.
Каждому инструменту своё предназначение. У openvz оно достаточно ограниченное. И уж точно далеко от «виртуальная машина, которую ставят один раз и надолго». Я их даю клиентам, которые часто ломают свои виртуалки и просят переустановки ОС.
root@8 ~ # uptime
17:15:45 up 292 days, 11:45, 1 user, load average: 1.00, 0.77, 0.56
[root@vz1 ~]# uptime
17:07:06 up 8 days, 2:48, 1 user, load average: 14.01, 16.12, 16.93
И ведь vz1 скоро снова ребутнется, да… Ну там дней через 30-40.
Может быть, я делаю что-то не так?
[shaggycat@ovz07 ~]$ uptime
19:23:47 up 307 days, 21:06, 2 users, load average: 12.89, 13.02, 13.20
Что LXC в обозримом будущем будет готов для хостинга я, извините, не верю :(
Оно до сих пор умеет не больше, чем Linux VServer 2005-го года, который давно проиграл войну OpenVZ
[shaggycat@ovz07 ~]$ uptime
19:23:47 up 307 days, 21:06, 2 users, load average: 12.89, 13.02, 13.20
Что LXC в обозримом будущем будет готов для хостинга я, извините, не верю :(
Оно до сих пор умеет не больше, чем Linux VServer 2005-го года, который давно проиграл войну OpenVZ
> Может быть, я делаю что-то не так?
Вас не ддосят и veth не делает oops)?
> Что LXC в обозримом будущем будет готов для хостинга я, извините, не верю :(
Его готовность для хостинга на текущий момент описывается словом «никогда». Это _очень_ быстрое решение для виртуализации в _своей_ инфраструктуре. Очень хорошо интегрированное в систему, не использующее каких-либо древних костылей. Со всеми вытекающими. Если чужим людям нужны руты на ваших виртуалках, но не нужны на соседних с ними — lxc вам не подойдет, однозначно. Если пользователям виртуалок нужен контроль ресурсов потребляемых конкретной виртуалкой (и не через cgroup, как это смотрю я, а через top/htop/etc) — то вам тоже мимо.
> Оно до сих пор умеет не больше, чем Linux VServer 2005-го года, который давно проиграл войну OpenVZ
Вот только количество накладных ресурсов на lxc поражает воображение ;) В отличие от того же vserver, да. Вы не теряете ни в дисках, ни в процессоре, ни в памяти, ни в IO. Если использовать macvlan — то и гигабит мелких пакетов по сети можно спокойно «прокачать». Теряете вы только на контекст-свичах, но не больше, чем если бы вы всё то же самое запустили в одной bare-metall.
Вас не ддосят и veth не делает oops)?
> Что LXC в обозримом будущем будет готов для хостинга я, извините, не верю :(
Его готовность для хостинга на текущий момент описывается словом «никогда». Это _очень_ быстрое решение для виртуализации в _своей_ инфраструктуре. Очень хорошо интегрированное в систему, не использующее каких-либо древних костылей. Со всеми вытекающими. Если чужим людям нужны руты на ваших виртуалках, но не нужны на соседних с ними — lxc вам не подойдет, однозначно. Если пользователям виртуалок нужен контроль ресурсов потребляемых конкретной виртуалкой (и не через cgroup, как это смотрю я, а через top/htop/etc) — то вам тоже мимо.
> Оно до сих пор умеет не больше, чем Linux VServer 2005-го года, который давно проиграл войну OpenVZ
Вот только количество накладных ресурсов на lxc поражает воображение ;) В отличие от того же vserver, да. Вы не теряете ни в дисках, ни в процессоре, ни в памяти, ни в IO. Если использовать macvlan — то и гигабит мелких пакетов по сети можно спокойно «прокачать». Теряете вы только на контекст-свичах, но не больше, чем если бы вы всё то же самое запустили в одной bare-metall.
veth не делает oops)?
Зачем veth на хостинговом сервере?? also, Когда мы занимались аутсорингом офисных клиентов, не было и проблем с veth, который прокачивал через себя трафик с гигабитного линка для Samba-контейнера. Какие были сетевые карточки я не помню, к сожалению, но материнская плата была самая что ни на есть десктопно PC-юковая.
Я сперва думала, что придется отказаться от маков для контейнера с Samba, и гонять файловый трафик через venet, но все получилось.
Если использовать macvlan — то и гигабит мелких пакетов по сети можно спокойно «прокачать».
Вы же в курсе про Venet, да?
Ы. Почитал ваш пост, задумался.
[root@vz1 ~]# ifconfig venet0
venet0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet6 addr: fe80::1/128 Scope:Link
UP BROADCAST POINTOPOINT RUNNING NOARP MTU:1500 Metric:1
RX packets:6878805 errors:0 dropped:0 overruns:0 frame:0
TX packets:6340592 errors:0 dropped:178 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1108399229 (1.0 GiB) TX bytes:800480015 (763.3 MiB)
Его-то драйвер и выпадает — машина сеть теряет.
А вот veth у меня как раз нормально работал, хоть и медленно.
Впрочем, это уже конфиг позапрошлого года и скоро ему придет смерть, так что говорить про него бестолку.
Главное, что бриджи везде хорошо работают, а там где плохо — macvlan спасет =)
[root@vz1 ~]# ifconfig venet0
venet0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet6 addr: fe80::1/128 Scope:Link
UP BROADCAST POINTOPOINT RUNNING NOARP MTU:1500 Metric:1
RX packets:6878805 errors:0 dropped:0 overruns:0 frame:0
TX packets:6340592 errors:0 dropped:178 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1108399229 (1.0 GiB) TX bytes:800480015 (763.3 MiB)
Его-то драйвер и выпадает — машина сеть теряет.
А вот veth у меня как раз нормально работал, хоть и медленно.
Впрочем, это уже конфиг позапрошлого года и скоро ему придет смерть, так что говорить про него бестолку.
Главное, что бриджи везде хорошо работают, а там где плохо — macvlan спасет =)
Мне кажется, что-то с железом :(
Как раз venet всегда работает идеально, так как это локальная петля по сути…
А veth работает с небольшим оверхедом.
Как раз venet всегда работает идеально, так как это локальная петля по сути…
А veth работает с небольшим оверхедом.
К слову про бриджи и veth: я как раз сейчас колупаюсь с поднятием dhclient внутри ovz-контейнера, и третий день не могу побороть дропание dhcp reply в бридже. Все другие типы пакетов (от arp до http) ходят, а эти ни в какую. Что это может быть?
а tcpdump -i БРИДЖ на ноде и в контейнере что говорит?
то есть в контейнере конечно tcpdump -i eth0
В бридж пакеты приходят, из бриджа не выходят. Внутри контейнера картина такая же, как на хостовой ноде tcpdump -i vethNN: только request'ы.
iptables, конечно, сброшен?
А попробуйте создать пустой дефольтный контейнер (лучше другой дистрибутив, чем у вас сейчас), и повторить опыт с ним.
А попробуйте создать пустой дефольтный контейнер (лучше другой дистрибутив, чем у вас сейчас), и повторить опыт с ним.
iptables -F сделано, с форвардингом чего только не делал, /proc/sys/net/bridge/bridge-nf-* в самых разных комбинациях испробовано. Контейнер как раз пустой дефолтный (единственный на этой машине), только что пересоздал для чистоты эксперимента. Снаружи шапка 6, внутри 5.9
>В LXC всё ещё недостаточный уровень изоляции контейнеров. Да и insmod всё ещё можно из гостя делать.
lxc.cap.drop = sys_module
ну и полезно ещё отобрать:
lxc.cap.drop = sys_boot
lxc.cap.drop = setpcap
lxc.cap.drop = sys_admin
lxc.cap.drop = sys_boot
lxc.cap.drop = sys_rawio
но основная беда — это proc & sys.
ну и поддержка неймспейсов объектами ядра.
lxc.cap.drop = sys_module
ну и полезно ещё отобрать:
lxc.cap.drop = sys_boot
lxc.cap.drop = setpcap
lxc.cap.drop = sys_admin
lxc.cap.drop = sys_boot
lxc.cap.drop = sys_rawio
но основная беда — это proc & sys.
ну и поддержка неймспейсов объектами ядра.
Нет, конечно. Зачем мне было грызть кактус? Все новые машины с тех пор у меня под lxc, благо условия позволяют.
Вам выше неоднократно сказали — если не разбираетесь в Xen и в технологиях виртуализации отличных от виртуозы, то лучше промолчать, а не говорить, тем более так безапелляционно. Xen уже давно умеет live storage и live pool migration. То есть полочка не нужна. Виртуоза это умеет? Несколько лет назад когда я ее ковырял точно не умела.
А по поводу виртуозы. Обычно я большинству знакомых рекомендую, если они видят на сайте хостера это слово, сразу сайт закрывать и искать дальше. Свои модули в ядро — умоляем хостера, свою версию ядра — не, облом. 20 инстансов апача и память кончилась, но ведь влезало даже на rpi при тестах. А, ну да, виртуоза память иначе считает и надо тюнить все. Да ну ее в пень такую «виртуализацию». Хотя под некоторые проекты — каюсь, грешен, рекомендовал ее :)
А по поводу виртуозы. Обычно я большинству знакомых рекомендую, если они видят на сайте хостера это слово, сразу сайт закрывать и искать дальше. Свои модули в ядро — умоляем хостера, свою версию ядра — не, облом. 20 инстансов апача и память кончилась, но ведь влезало даже на rpi при тестах. А, ну да, виртуоза память иначе считает и надо тюнить все. Да ну ее в пень такую «виртуализацию». Хотя под некоторые проекты — каюсь, грешен, рекомендовал ее :)
поправьте если ошибаюсь, но XenMotion разве не только для платного Citrix? А в бесплатном, GPL OpenVZ, живая миграция между стораджами(в качестве которых обычно выступают локальные диски сервера) была всегда, то есть, с серидины 2000-х годов.
Значит я тогда не разобрался как ее готовить, ибо не смог завести.
Не путайте XenMotion и Storage XenMtion. Первый был всегда и в любой версии. Второй появился в XCP 1.6 и XenServer 6.1. На счет бесплатного сервера не скажу — у меня из XenServer'ов только на адванседе один из пулов, а халявного уже нет. Но в остальных пулах, которые крутятся на GPL'ном XCP, из коробки прекрасно пашет Storage XM.
Не путайте XenMotion и Storage XenMtion. Первый был всегда и в любой версии. Второй появился в XCP 1.6 и XenServer 6.1. На счет бесплатного сервера не скажу — у меня из XenServer'ов только на адванседе один из пулов, а халявного уже нет. Но в остальных пулах, которые крутятся на GPL'ном XCP, из коробки прекрасно пашет Storage XM.
Что Вы ключи vzmigrate посмотрели невнимательно, я не верю, Вы вроде бы профи :)
Скорее всего, у Вас были между нодами ли CPU разных поколений (в KVM кстати круто, что он умеет Live Migration между Xeon и Opteron, в OpenVZ и Virtuozzo, к сожалению, совместимость меньше), или был не загужен какой-то модуль вроде vzcpt, или был разный список ядерных модулей на нодах (для VPS-ки был, скажем, прописан модуль iptables, которого не было на destenation ноде)
Эти все ситуации есть в kb параллельса, ну или саппорт на такие вопросы тоже отвечает (хоть они и простые)
Скорее всего, у Вас были между нодами ли CPU разных поколений (в KVM кстати круто, что он умеет Live Migration между Xeon и Opteron, в OpenVZ и Virtuozzo, к сожалению, совместимость меньше), или был не загужен какой-то модуль вроде vzcpt, или был разный список ядерных модулей на нодах (для VPS-ки был, скажем, прописан модуль iptables, которого не было на destenation ноде)
Эти все ситуации есть в kb параллельса, ну или саппорт на такие вопросы тоже отвечает (хоть они и простые)
Скорее всего не доковырял. На тот момент решали делать ли два пула под винды и линукса или один общий. В результате сделали один общий и пока ни разу не пожалели.
Я сходу с этой виртуозой пару багов словил, решения не нашел и забил. Плюс с товарищем пообщался, который хостера с виртуозой админил — много мата выслушал по поводу багов и скорости их починки, и качества саппорта. Сейчас может там все и шоколадно, но нужно было тогда.
Сейчас несколько пулов на xen, несколько контейнеров lxc, несколько jail на фряхе. Так что по openvz/virtuozzo я точно не профи.
Я сходу с этой виртуозой пару багов словил, решения не нашел и забил. Плюс с товарищем пообщался, который хостера с виртуозой админил — много мата выслушал по поводу багов и скорости их починки, и качества саппорта. Сейчас может там все и шоколадно, но нужно было тогда.
Сейчас несколько пулов на xen, несколько контейнеров lxc, несколько jail на фряхе. Так что по openvz/virtuozzo я точно не профи.
Значит я тогда не разобрался как ее готовить, ибо не смог завести.
Не смогли запустить команду vzmigrate --online? Смешно.
А не мигрировали :( Сейчас уже не вспомню почему.
Стоит заметить, что vzmigrate --online вовсе не живая миграция. Если у контейнера скажем 5-10-100 гб оперативной памяти, то время даунтайма при vzmigrate --online будет аховским (будет ровняться времени саспенда — довольно серьезному — и последующей передачи дампа по сети).
Бесплатно в XCP 1.6
Тогда правомерно говорить, что live migration нет в части решений под Xen.
Cloud Platform же, наверное, не всем подойдет?
Cloud Platform же, наверное, не всем подойдет?
Всем подойдет. В xcp и есть xen.
Во всех дистрибутивах?
Xapi накручиваетя на большинство дистров, на которые можно установить Xen, а дальше рулится из XenCenter, а для пуристов — из под GPL-софта, которого навалом разных видов.
Это уже кто-то использует в production из Xen хостеров?
Никогда не интересовался этим вопросом. Но раз в wiki xcp этот вопрос разжевали очень подробно, то вещь популярная. Там много чего не освещено, а этот топик разжевали.
Тот же амазон врядли живет под чистым xen, но и врядли на XenServer/XCP. Скорее всего xen+libvirt или xapi. В свое время я подробностей не нашел.
Тот же амазон врядли живет под чистым xen, но и врядли на XenServer/XCP. Скорее всего xen+libvirt или xapi. В свое время я подробностей не нашел.
Чисто для понимания, это возможность теоретическая. xapi в дебиане — это снапшот из гита, который с продакту никакого отношения не имеет, а вкрутить в живую ОСЬ xapi просто так не выйдет — много нюансов.
XCP, это уже готовая платформа, которую можно использовать. Из коробки, уже много готового, если рассматривать фаш случай, вам хватит. Если смотреть на более крпуные инсталяции и предоставление этого как услуги, необходимо дорабатывать по несколким направлениям.
XCP=XenServer минус чуток проприетарщины и под GPL.
Да все она правильно говорит.
Виртуоза — платный продукт. Openvz — нет. Вы про какой? А есть еще гибридные решения, proxmox, например, он позволяет из одной вебморды управлять и KVM, и Openvz. В такой среде работает online миграция при соблюдении некоторых условий и с небольшими допущениями. Топик не про это, но у нас даунтайм kvm виртуалки под нагрузкой чуть меньше 5ms при живой миграции. И это без всяких СХД и дорогущих ентерпрайз. Сейчас openvz запилят свой ploop, и его можно будет мигрировать также. Плюс ploop решает вопросы с затупами kjournald на хост машине.
Пресловутые «модули в ядро» никому не нужны. Память считается? Нормально считается, это некоторые нечистые на руку оверселлеры делают антирекламу своим маркетинговым булщитом. Что там тюнить? Три параметра в конфиге уже давно.
Ну и апачи на дешевые впски-вдски не советую, лучше что-нибудь посовременнее.
Опенвз не нравится тем, что совсем под нагрузкой процессы внутри залипают. Порт открыт, процесс висит, но ничего не делает и ни на что не отвечает. Ну, просто под такой нагрузкой у нас вообще остальные никакие виртуалки не живут. С Java есть некоторые сложности. Нет возможности контролировать диск IO. Да это все мелочи по сравнению с плюсами.
— легковесность.
— легкость администрирования.
— крутая математика внутри. Оверкоммиты, балуны, всвап. Ну круто, правда.
— шустро очень очень шустро.
— развивается и пилится.
У нас все проекты внешние на openvz. Это несколько петабайт трафика, несколько десятков миллионов уников в месяц и до 6000 рпс на некоторые узлы системы.
Я вот XEN людям не советую. Тормозной и крашится под нагрузкой. Rackspace же его использует? Ну-ну.
Виртуоза — платный продукт. Openvz — нет. Вы про какой? А есть еще гибридные решения, proxmox, например, он позволяет из одной вебморды управлять и KVM, и Openvz. В такой среде работает online миграция при соблюдении некоторых условий и с небольшими допущениями. Топик не про это, но у нас даунтайм kvm виртуалки под нагрузкой чуть меньше 5ms при живой миграции. И это без всяких СХД и дорогущих ентерпрайз. Сейчас openvz запилят свой ploop, и его можно будет мигрировать также. Плюс ploop решает вопросы с затупами kjournald на хост машине.
Пресловутые «модули в ядро» никому не нужны. Память считается? Нормально считается, это некоторые нечистые на руку оверселлеры делают антирекламу своим маркетинговым булщитом. Что там тюнить? Три параметра в конфиге уже давно.
Ну и апачи на дешевые впски-вдски не советую, лучше что-нибудь посовременнее.
Опенвз не нравится тем, что совсем под нагрузкой процессы внутри залипают. Порт открыт, процесс висит, но ничего не делает и ни на что не отвечает. Ну, просто под такой нагрузкой у нас вообще остальные никакие виртуалки не живут. С Java есть некоторые сложности. Нет возможности контролировать диск IO. Да это все мелочи по сравнению с плюсами.
— легковесность.
— легкость администрирования.
— крутая математика внутри. Оверкоммиты, балуны, всвап. Ну круто, правда.
— шустро очень очень шустро.
— развивается и пилится.
У нас все проекты внешние на openvz. Это несколько петабайт трафика, несколько десятков миллионов уников в месяц и до 6000 рпс на некоторые узлы системы.
Я вот XEN людям не советую. Тормозной и крашится под нагрузкой. Rackspace же его использует? Ну-ну.
>А про драйвера, RHEL6 ядра, на которых базируется свежий OpenVZ, поддерживают все серверное железо.
хехе. вот только интеловские e1000e плюются netdev watchdog timeout )))
а фикс — на sourceforge.net(где можно стянуть интеловские драйвера) либо вообще git.
могу ещё напомнить про silent panic в 2.6.9(да, это rhel4) на определённых чипах интеловских карточек при включенном tso.
хехе. вот только интеловские e1000e плюются netdev watchdog timeout )))
а фикс — на sourceforge.net(где можно стянуть интеловские драйвера) либо вообще git.
могу ещё напомнить про silent panic в 2.6.9(да, это rhel4) на определённых чипах интеловских карточек при включенном tso.
2.6.32 уже давно.
Вы, наверное, говорите про те времена, когда ядро было дебиановское? Очень давно такое встречал, но вроде это было в 2.6.18, оно было debian-based.
RedHat делает славные ядра. Не нравится, что они все повыпилили правда, кроме своих редхатовских штук. В продакшне с этим проблема.
Вы, наверное, говорите про те времена, когда ядро было дебиановское? Очень давно такое встречал, но вроде это было в 2.6.18, оно было debian-based.
RedHat делает славные ядра. Не нравится, что они все повыпилили правда, кроме своих редхатовских штук. В продакшне с этим проблема.
>2.6.32 уже давно.
я как бы в курсе. про 2.6.9 упоминалось лишь как пример «стабильности» rhel-ядер.
>Вы, наверное, говорите про те времена, когда ядро было дебиановское?
вы о чём? openvz можно рассматривать серьёзно только в контексте rhel-ядер(в том числе полученных патчами на ванильные 2.6.18 и 2.6.32).
то что вы не встречали netdev watchdog timeout — очень и очень странно.
я как бы в курсе. про 2.6.9 упоминалось лишь как пример «стабильности» rhel-ядер.
>Вы, наверное, говорите про те времена, когда ядро было дебиановское?
вы о чём? openvz можно рассматривать серьёзно только в контексте rhel-ядер(в том числе полученных патчами на ванильные 2.6.18 и 2.6.32).
то что вы не встречали netdev watchdog timeout — очень и очень странно.
<= 2.6.18stab это были дебиановские ядра. Сами разработчики openvz считают ядро rhel стабильным, нет оснований им не верить.
2.6.9 — это 2004 год? Как бы очень и очень давно. Я думаю, что в сравнении с другими продуктами 2004 года эта штука будет достаточно «стабильной».
2.6.9 — это 2004 год? Как бы очень и очень давно. Я думаю, что в сравнении с другими продуктами 2004 года эта штука будет достаточно «стабильной».
<= 2.6.18stab это были дебиановские ядра.
да ну?
2.6.9 — это 2004 год? Как бы очень и очень давно.
RHEL4.9 вышел в феврале 2011
Все правильно сказано между прочим, мало того что продают на несерверном железе так еще и готовят на нем OVZ так что не знают сколько чего оно тянет и оверселят в итоге втыщу раз. И кстати про хецнер, я никогда не забуду продажу i7 серверов с старым ядром где куча фишечек просто недоступно было в системе, а все так бросались за новым мощным CPU за нищенские деньги что плевать хотели на полноценный сервер, а их диски и рейд контроллеры до сих пор заставляют нервно улыбаться.
Практика использования XEN/KVM/OpenVZ/Jail у крупных провайдеров, показывает что в OpenVZ/Jail соседи по серверу могут больше друг другу мешать. Ддос либо использование тяжелых неоптимизированных приложений может положить к чертям весь сервер. В KVM изоляция намного лучше. Теперь если клиент использует что-то адово тормозное, предлагаем ему переехать на KVM и о чудо, проблемы пропадают.
.
Как интересно скачет рейтинг топика: сперва было больше десяти, а вот сейчас, сейчас он уйдет в минуса :)
Пожалуй, попытка реабилитации OpenVZ в глазах сообщества Хабра-Хабра провалилась :(
Один человек никогда не нивелирует многолетные труды пиар команд нескольких Xen-хостеров.
Сорри за такую конспирологическую теорию, но я в нее верю, а вот в жидомассонский заговор нет!
Пожалуй, попытка реабилитации OpenVZ в глазах сообщества Хабра-Хабра провалилась :(
Один человек никогда не нивелирует многолетные труды пиар команд нескольких Xen-хостеров.
Сорри за такую конспирологическую теорию, но я в нее верю, а вот в жидомассонский заговор нет!
Вся аргументация против OpenVZ состоит из «нельзя пересобрать ядро и загрузить свой модуль iptables» :)
Основная аргументация — для админа сервер в контейнере это как резиновая женщина. На первый. згляд вроде такая же как настоящая, но дьявол как всегда кроется в деталях :)
На самом деле в статье и в комментах постоянно смешивают услуги хостинга и севисы предприятия, т.е. enterprise, а это несколько разные вещи с несколько разными задачами и требованиями.
На самом деле в статье и в комментах постоянно смешивают услуги хостинга и севисы предприятия, т.е. enterprise, а это несколько разные вещи с несколько разными задачами и требованиями.
Да что Вы говорите, почитайте комменты, аргументов приведено выше крыши…
UFO just landed and posted this here
Даже не интересуюсь, на какой платформе у Вас VPS, по тому, что для Xen/KVM есть только dm-ioband для жестких лимитов по i/o, который почти никто не использует по многим причинам (прежде всего, он не мантайнится).
То есть, за, например, таренье архивов с миллионами файлов Вас могут даже выключить на любом хостинге, где не используется быстрая полочка с дисками, или SSD.
То есть, за, например, таренье архивов с миллионами файлов Вас могут даже выключить на любом хостинге, где не используется быстрая полочка с дисками, или SSD.
как предварительное резюме: по поводу бенчмарков HP о VPS Xen vs VPS OpenVZ возражений не было, не было и возражений по поводу vzswap. Прицепились к слабым местам в тезисах, озвучив новые фичи, вроде Storage XenMtion, которые не обязательно есть у всех Xen хостеров.
Пока не видно, в чем дешевые Xen и KVM VPS-ки, без общего стораджа, лучше для конечного пользователя, чем OpenVZ VPS-ки. Особенно с учетом большей плотности OpenVZ VPS на ноде, а, значит, и меньшей стоимости ресурсов для конечного пользователя, или большей рентабельности хостинга, дополнительные деньги от которой low-cost хостер может потратить на качественный, умный саппорт.
Удивительно, что никто не вспомнил старую песню о том, что Апач на OpenVZ ест меньше памяти, чем на Xen (подсказка: нужно тюнить стек, man ulimit)
Пока не видно, в чем дешевые Xen и KVM VPS-ки, без общего стораджа, лучше для конечного пользователя, чем OpenVZ VPS-ки. Особенно с учетом большей плотности OpenVZ VPS на ноде, а, значит, и меньшей стоимости ресурсов для конечного пользователя, или большей рентабельности хостинга, дополнительные деньги от которой low-cost хостер может потратить на качественный, умный саппорт.
Удивительно, что никто не вспомнил старую песню о том, что Апач на OpenVZ ест меньше памяти, чем на Xen (подсказка: нужно тюнить стек, man ulimit)
что Апач на OpenVZ ест меньше памяти, чем на Xen (подсказка: нужно тюнить стек, man ulimit)
То есть, наоборот больше
Как пользователю дешевых VDS мне, в принципе, всё равно какая технология виртуализации используется, лишь бы она мне не доставляла проблем. В администрировании я не силен и занимаюсь им, грубо говоря, вынужденно — из-за желания или заработать лишнюю копейку, или сэкономить её моим заказчикам (как правило малокомпетентым в области администрирования и разработки) для сохранения их лояльности ко мне. Но я с трудом представляю себе администрирование системы (практикую debian-based), где не все пакеты мне подконтрольны. С одной стороны, в нужных мне пакетах могут оказаться зависимости от нового ядра, а с другой — хостер может обновить ядро и оно окажется несовместимым с моим В свое время намучался по подобным причинам с обычным шаред-хостингом, то не обновиться, когда нужно, то насильно обновляют, когда не нужно, и потому скептически отношусь к технологиям на основе «клонирования ядра» и, тем более, если речь идет не только о ядре.
«VPS на Xen лучше, чем VPS на OpenVZ/Virtuozzo»
XEN банально лучше тем, что у десятка хостинг провайдеров (работающих с Virtuozzo и OpenVZ) с которыми я имел дело, нельзя поставить ppp модуль ядра, потому что видите ли (по словам тех-поддержки) это сломает хост-систему. На Xen у меня такой проблемы не возникло.
Для меня это например очень критично.
XEN банально лучше тем, что у десятка хостинг провайдеров (работающих с Virtuozzo и OpenVZ) с которыми я имел дело, нельзя поставить ppp модуль ядра, потому что видите ли (по словам тех-поддержки) это сломает хост-систему. На Xen у меня такой проблемы не возникло.
Для меня это например очень критично.
С одной стороны, в нужных мне пакетах могут оказаться зависимости от нового ядра, а с другой — хостер может обновить ядро и оно окажется несовместимым с моим
В OpenVZ одно ядро, которое всегда совместимо само с собой :)
А вот паравиртуальный домен Xen может теоретически сломаться при обновлении ядра dom0
Что само с собой оно совместимо, я понимаю. :) но что делать, если, утрируя, у PHP 5.5 появится зависимость от 3.9, а у хостера останется 3.8?
PHP не будет зависеть от ядра :))) Максимум, от glibc :)
В VPS на любой технологии Вы можете себе поставить любую версию PHP. Точнее, иногда не можете из-за панели управления, установленной внутрь VPS, или на физический сервер. Но если поставить другую панель, или администрировать VPS(дедик) без панели, то можно «воткнуть» любую версию PHP
В VPS на любой технологии Вы можете себе поставить любую версию PHP. Точнее, иногда не можете из-за панели управления, установленной внутрь VPS, или на физический сервер. Но если поставить другую панель, или администрировать VPS(дедик) без панели, то можно «воткнуть» любую версию PHP
Занятно, что автор статьи преподносит vSwap как плюс. Это костыль, который приводит к следующим проблемам:
1) Учёт памяти страницами приводит к аварийному завершению процесса, который стал причиной выделения страницы, которая не может быть выделена. Например, все страницы забрали процессы apache, а oom-killer решил прибить mysql. Имеем битые базы.
2) Вытеснение swap в память может иметь противоположный описанному результат. Операционная система — не дура, и откачивает редкоиспользуемые страницы, а вместо них загружает, например, дисковый кеш. Если своп от впсок будет висеть вместо дискового кеша, то общая производительность упадёт.
3) Искуственное замедление доступа к памяти — полный бред. Много одновременных запросов -> превышение лимита на память -> ещё больше одновременных запросов -> падение.
Мы от него используем только первую возможность, потому что она в некотором смысле повторяет поведение реальной операционной системы и все, кого это волнует, к этому привыкли.
Кроме того, сейчас OpenVZ рекомендует переходить на ploop, что отменяет Ваши аргументы про миграцию (т.к. копирование блочного устройства будет идти одинаковое количество времени на всех гипервизорах, а, очевидно, именно это самое узкое место) и уплотнение ФС (которое приводит к очень злым проблемам при оверселлинге).
В своё время OpenVZ действительно был нужен и полезен. Когда аппаратная виртуализация стала иметь сравнимые с текущими стабильность и оверхед, технология стала применима лишь в очень узком спектре вроде разещения на одном сервере 10000 виртуалок, каждая из которых обрабатывает по 3 запроса в день.
1) Учёт памяти страницами приводит к аварийному завершению процесса, который стал причиной выделения страницы, которая не может быть выделена. Например, все страницы забрали процессы apache, а oom-killer решил прибить mysql. Имеем битые базы.
2) Вытеснение swap в память может иметь противоположный описанному результат. Операционная система — не дура, и откачивает редкоиспользуемые страницы, а вместо них загружает, например, дисковый кеш. Если своп от впсок будет висеть вместо дискового кеша, то общая производительность упадёт.
3) Искуственное замедление доступа к памяти — полный бред. Много одновременных запросов -> превышение лимита на память -> ещё больше одновременных запросов -> падение.
Мы от него используем только первую возможность, потому что она в некотором смысле повторяет поведение реальной операционной системы и все, кого это волнует, к этому привыкли.
Кроме того, сейчас OpenVZ рекомендует переходить на ploop, что отменяет Ваши аргументы про миграцию (т.к. копирование блочного устройства будет идти одинаковое количество времени на всех гипервизорах, а, очевидно, именно это самое узкое место) и уплотнение ФС (которое приводит к очень злым проблемам при оверселлинге).
В своё время OpenVZ действительно был нужен и полезен. Когда аппаратная виртуализация стала иметь сравнимые с текущими стабильность и оверхед, технология стала применима лишь в очень узком спектре вроде разещения на одном сервере 10000 виртуалок, каждая из которых обрабатывает по 3 запроса в день.
1) Учёт памяти страницами приводит к аварийному завершению процесса, который стал причиной выделения страницы, которая не может быть выделена. Например, все страницы забрали процессы apache, а oom-killer решил прибить mysql. Имеем битые базы.
Этого не произойдет, так как vswap медленный. Раньше, в OVZ, действительно OOM Killer прибивал процессы :(
не дура, и откачивает редкоиспользуемые страницы, а вместо них загружает, например, дисковый кеш.
С чего Вы взяли, что OVZ ядро будет себя так вести? Вы это точно знаете?
Кроме того, сейчас OpenVZ рекомендует переходить на ploop,
Не рекомендует, т.к. он еще очень сырой. В будущем, думаю, можно будет и ploop использовать (опять же для жестких лимитов на i/o через cgroups) и просто свалку в /vz/private.
А еще есть vzfs. Может быть, его когда-нибудь откроют, и портируют в OVZ из виртуозы.
Кстати, свалка в /vzr/private очень удобна с точки зрения администрирования :) Скрипты для большого числа VPS очень сильно упрощаются.
своё время OpenVZ действительно был нужен и полезен. Когда аппаратная виртуализация стала иметь сравнимые с текущими стабильность и оверхед, технология стала применима лишь в очень узком спектре вроде разещения на одном сервере 10000 виртуалок,
Очень категоричное заявление. Оверхед все еще большой, и, например, хоть многие и успешно запускают такие приложения как Asterisk и FreeSwitch в Xen доменах, VmWare виртуалках, на форумах айпи телефонии категорически не рекомендуют виртуализировать приложения для АйПи телефонии в чем-то, кроме OpenVZ или LXC
>чень категоричное заявление. Оверхед все еще большой, и, например, хоть многие и успешно запускают такие приложения как Asterisk и FreeSwitch в Xen доменах, VmWare виртуалках, на форумах айпи телефонии категорически не рекомендуют виртуализировать приложения для АйПи телефонии в чем-то, кроме OpenVZ или LXC
как человек с инсталляцией ~ 300 астерисков в разных xen/kvm могу сказать: да, такие рекомендации есть. но связаны они в первую очередь с убегающим временем внутри виртуалки. в реальности я с этим столкнулся только 1 раз(и то, хост был наш собственный со старым ядром и xen'ом).
как человек с инсталляцией ~ 300 астерисков в разных xen/kvm могу сказать: да, такие рекомендации есть. но связаны они в первую очередь с убегающим временем внутри виртуалки. в реальности я с этим столкнулся только 1 раз(и то, хост был наш собственный со старым ядром и xen'ом).
1. Начиная с XenServer 6 и XCP 1.6 поддерживается storage migration. То есть перенос возможен между пулами при наличии DAS с фактическим копированием файлов между полностью изолированными узлами. У себя в лаборатории я гонял виртуалки из одного федерального округа в другой, причём благодаря использованию 'base' части, повторные миграции будут весьма и весьма шустрыми.
2. OpenVZ не имеет адекватных средств по изоляции виртуалок друг от друга. Пара примеров: mount list (позволяет сильно напрячь ядро из самого дешёвого контейнера), entropy drain.
3. Оверселлинг никуда не девается.
4. Я не видел ни одной инсталляции openvz, которая была бы способна пережить хотя бы 400kpps сетевого трафика.
2. OpenVZ не имеет адекватных средств по изоляции виртуалок друг от друга. Пара примеров: mount list (позволяет сильно напрячь ядро из самого дешёвого контейнера), entropy drain.
3. Оверселлинг никуда не девается.
4. Я не видел ни одной инсталляции openvz, которая была бы способна пережить хотя бы 400kpps сетевого трафика.
>Я не видел ни одной инсталляции openvz, которая была бы способна пережить хотя бы 400kpps сетевого трафика.
а в чём проблема? т.е. вот всё вышеперечисленное — это мне понятно. но пакетрейт…
а в чём проблема? т.е. вот всё вышеперечисленное — это мне понятно. но пакетрейт…
Ну если ни в чём проблемы нет, то вы готовы для эксперимента выделить vds'ку?
Если что, я говорю про brtools и/или роутинг.
Если что, я говорю про brtools и/или роутинг.
#kernel
Interface RX Pkts/Rate TX Pkts/Rate RX Data/Rate TX Data/Rate
RX Errs/Drop TX Errs/Drop RX Over/Rate TX Coll/Rate
eth0 810955 0 1 0 51901K 0 450 0
30994 61988 0 0 0 0 0 0
тюнингом особо не заморачивался, да и больше 800kpps трафик генератор не может(процессор слабенький).
правда, это lxc, но тоже бридж.
А какие инсталляции способны такой трафик пережить? Это уже проблемы приложения, если такой трафик есть, но борется с ним виртуалка и всего одна.
Любая vmware или hyper-v выживают при 400kpps. XenServer/XCP — требуют специальной обработки, но всё-таки могут пережить. OpenVZ (точнее, софтовый бридж из комплекта) не переживают.
Заметим, в первую очередь речь идёт не о жизни конкретной виртуалки, а о том, что большой трафик в адрес одной виртуалки может полностью парализовать соседей. Заметим, не флуд в стиле «под потолок полосы», а просто большое число пакетов.
Я одно время думал, что это только подлый DoS таким бывает, пока не наткнулся на реального клиента, у которого средний размер tcp-сессии был около 200 байт. В продакте. При не очень выдающихся байтовых показателях.
Заметим, в первую очередь речь идёт не о жизни конкретной виртуалки, а о том, что большой трафик в адрес одной виртуалки может полностью парализовать соседей. Заметим, не флуд в стиле «под потолок полосы», а просто большое число пакетов.
Я одно время думал, что это только подлый DoS таким бывает, пока не наткнулся на реального клиента, у которого средний размер tcp-сессии был около 200 байт. В продакте. При не очень выдающихся байтовых показателях.
OpenVZ (точнее, софтовый бридж из комплекта) не переживают.
Так может, venet нужно использовать? Его для этого и придумали же!
Зачем вообще на хостинге мак адреса и veth?
venet куда вести будет? Я имею в виду, кто будет раскладывать пакеты по виртуалочкам после их прихода на физический интерфейс? И сможет ли он это делать со скоростью в несколько сотен kpps?
Как кто? Ядро :)
Попробуйте провести сранивнительные тесты: вот даже разрабочики пишут в вике, что veth с мак-адресами это небольшой оверхед, а venet работает практически без него (особенно, если пакеты летают между контейнерами, не выходя и входя в физический интерфейс)
Попробуйте провести сранивнительные тесты: вот даже разрабочики пишут в вике, что veth с мак-адресами это небольшой оверхед, а venet работает практически без него (особенно, если пакеты летают между контейнерами, не выходя и входя в физический интерфейс)
А антиспуфинг как накладывать?
Он не нужен: из контейнера Вы не сможете поменять IP-адрес для venet интерфейса, разве что каким-то zero-day эсплойтом
IP из контейнера только для veth меняется.
IP из контейнера только для veth меняется.
И raw sockets для veth запрещены? То есть послать hping'ом с rand-source'ом ничего не получится?
в том-то и дело, что разрешено. veth предоставляет много возможностей, практически столько же, сколько физический интерфейс.
А с venet у Вас ничего не получится.
veth есть смысл использовать категорически не для хостинга, а при инсталляциях контейнеров в офисах: dhcpd, tftpd сервер, например, без veth работать не будут.
Но зачем Вам мак адреса для интернет-сервера? на хостинге не нужно ничего, кроме venet в контейнере!
А с venet у Вас ничего не получится.
veth есть смысл использовать категорически не для хостинга, а при инсталляциях контейнеров в офисах: dhcpd, tftpd сервер, например, без veth работать не будут.
Но зачем Вам мак адреса для интернет-сервера? на хостинге не нужно ничего, кроме venet в контейнере!
вот вы вроде умный человек, а говорите странные вещи.
на forum.nag.ru есть ветка оного товарища.
а теперь скажите, что мешает делать то же самое? в рамках одной машины?
на forum.nag.ru есть ветка оного товарища.
intel C602 + 2x Xeon E2670 + 2x Intel-520
36ГБит/с 4,3Мпакетов
а теперь скажите, что мешает делать то же самое? в рамках одной машины?
Не знаю. На моей текущей работе делала кластер с двумя FreeBSD балансерами на pf, он даже не SMP, хотя трафик(почтовый) летит через него приличный.
Перед этим делала балансеры на Linux LVS, там хоть и есть SMP, но трафик был на пару порядков меньше.
В общем, я никогда не сталкивалась в качестве архитектора системы с тем трафиком, что по Вашей ссылке, только когда дежурной работала несколько лет назад, там такое видела на балансерах. Но видеть и быть архитектором системы это разное.
Перед этим делала балансеры на Linux LVS, там хоть и есть SMP, но трафик был на пару порядков меньше.
В общем, я никогда не сталкивалась в качестве архитектора системы с тем трафиком, что по Вашей ссылке, только когда дежурной работала несколько лет назад, там такое видела на балансерах. Но видеть и быть архитектором системы это разное.
>Перед этим делала балансеры на Linux LVS, там хоть и есть SMP, но трафик был на пару порядков меньше.
как-то так… на ipvs
как-то так… на ipvs
Так это может бриджа все же проблемы? У опенвз много неприятных моментов под сильной нагрузкой, но с сетью проблем не видел еще ))
Инструмент не подходит, не бывает универсальных инструментов. Нельзя проекты, не живущие спокойно даже на железной машине еще и виртуализировать. При типовых среднестатистических профилях нагрузки все работает нормально.
Я вообще не заморачиваюсь пакетами в секунду, есть у нас сетевики, это их проблема по большему счету.
Инструмент не подходит, не бывает универсальных инструментов. Нельзя проекты, не живущие спокойно даже на железной машине еще и виртуализировать. При типовых среднестатистических профилях нагрузки все работает нормально.
Я вообще не заморачиваюсь пакетами в секунду, есть у нас сетевики, это их проблема по большему счету.
3. Оверселлинг никуда не девается.
Вы так говорите, как будто бы оверселлинг это плохо для клиента: все хорошо в меру, пока LA на ноде приемлимое(все же знают, что обыно на OVZ машинах оно в несколько раз больше, чем на stadalone на этом же железе?), часть клиентов все равно не использует большую часть своих ресурсов. См. в топике абзац про теорию игр.
Еще раз про оверселлинг: ИМХО, оверселлинг это общее благо для клиента и для хостера, пока хостер продает не используемые ресурсы. Но некоторые нехорошие хостеры на этом не останавливаются, и начинают продавать уже используемые, так что у них VPS клиентов, например, вечно в swap сидят.
Чем больше заработает хостер, тем лучше для клиента: хостер сможет купить лучшее оборудование, нанять более опытный и доброжелательный к клиентам саппорт, даже если владелец хостинга все положит себе в карман, это тоже благо для клиента: вспомните нерентабельный макхост, с его долгами перед датацентром!
Чем больше заработает хостер, тем лучше для клиента: хостер сможет купить лучшее оборудование, нанять более опытный и доброжелательный к клиентам саппорт, даже если владелец хостинга все положит себе в карман, это тоже благо для клиента: вспомните нерентабельный макхост, с его долгами перед датацентром!
Оверселлинг имеет право быть только при одном единственном условии: когда моему крону потребуются ресурсы, я их получу в полном объёме без каких-либо задержек.
Выполнение этой гарантии нереально сложно, как технически, так и административно.
Выполнение этой гарантии нереально сложно, как технически, так и административно.
Сложно, если виртуалок до 10-15, хотя вполне вероятно (это часто случай гипервизоров), и невероятно НЕ выполнение, если гостевых систем под 50-100.
В OpenVZ, за счет большой плотности контейнеров, можно безопасно оверселлить раза в два: теория вероятности не даст сразу 25 клиентам резко и одновременно увеличить потребление ресурсов.
В OpenVZ, за счет большой плотности контейнеров, можно безопасно оверселлить раза в два: теория вероятности не даст сразу 25 клиентам резко и одновременно увеличить потребление ресурсов.
Буквально недавно разбирались с одним из шаблонов виртуалок — в 4:04 рост нагрузки на диски примерно в 40 раз. Выяснилось — пропущенная раномизация в кроне, плюс софт, который ставился в cron.daily.
То есть брали и по крону синхронно предъявляли.
Пичок на 00:00 я вполне глазами вижу, и он совсем не из-за забытого недорандома — просто люди, когда решают «когда запускать» прописывают у себя нули. Независимо, но одинаково. Типовой час пик.
То есть брали и по крону синхронно предъявляли.
Пичок на 00:00 я вполне глазами вижу, и он совсем не из-за забытого недорандома — просто люди, когда решают «когда запускать» прописывают у себя нули. Независимо, но одинаково. Типовой час пик.
Диски это слабое место, да, там неполная изоляция (причем не только у OpenVZ!)
А вот ОЗУ-ЦПУ вы, если хостинг оверселлит только простаивающие ресурсы, вы получите всегда, когда они Вам понадобятся.
А вот ОЗУ-ЦПУ вы, если хостинг оверселлит только простаивающие ресурсы, вы получите всегда, когда они Вам понадобятся.
А как он определяет, простаивающие они или нет? Я имею в виду не усреднённое значение, а вот «прямо сейчас». Если у меня нечто на 25% мощи сервера (по CPU, например), обычная утилизация у меня 5%, то очевидно, что простаивающие 20% будут перепроданы. А теперь вопрос: а если я внезапно захочу свои 25% мощи, а из этих 20% 10% занято, что будет?..
А с памятью ещё веселее. Допустим, по тарифу 4Гб. Процессы болтаются в 300Мб. 2Гб из этих 4 кому-то отдали. Потом ещё кому-то. И на выходе на хосте 4Гб свободно. Час Х. Три человека по гигабайту предъявили внезапно, и тут я свои 4 хочу. А есть 1. И?
А с памятью ещё веселее. Допустим, по тарифу 4Гб. Процессы болтаются в 300Мб. 2Гб из этих 4 кому-то отдали. Потом ещё кому-то. И на выходе на хосте 4Гб свободно. Час Х. Три человека по гигабайту предъявили внезапно, и тут я свои 4 хочу. А есть 1. И?
Допустим, у нас на OpenVZ ноде 32 Gb озу,
32*1024/500=65
Можно безопасно продавать до сотни, по тому, что утилизация памяти у практически всех будет около 50%.
Хотя в реальном мире сотня пятьсот мегабайтных контенеров скорее всего потребуют очень скорострельный raid контроллер и SAS 15k, но не суть.
Как Вы себе представляете то, что бы ресурсы одномоментно потребовало 30-40 контейнеров? Такого не бывает, вероятнее, что обезьяна, стуча по клавишам, случайно напечатает поэму :)
А вот при плотности в 10-15-20 xen-доменов на dom0, характерной для xen-хостеров, когда вас будут оверселлить по CPU, гораздо вероятнее, что Вы свои ресурсы недополучите :)
4Gb VPS-ки на OpenVZ зло. Я делала такие контейнеры для сервисов в офисах, но покупать и продавать такое на OVZ не очень правильно.
32*1024/500=65
Можно безопасно продавать до сотни, по тому, что утилизация памяти у практически всех будет около 50%.
Хотя в реальном мире сотня пятьсот мегабайтных контенеров скорее всего потребуют очень скорострельный raid контроллер и SAS 15k, но не суть.
Как Вы себе представляете то, что бы ресурсы одномоментно потребовало 30-40 контейнеров? Такого не бывает, вероятнее, что обезьяна, стуча по клавишам, случайно напечатает поэму :)
А вот при плотности в 10-15-20 xen-доменов на dom0, характерной для xen-хостеров, когда вас будут оверселлить по CPU, гораздо вероятнее, что Вы свои ресурсы недополучите :)
4Gb VPS-ки на OpenVZ зло. Я делала такие контейнеры для сервисов в офисах, но покупать и продавать такое на OVZ не очень правильно.
Как Вы себе представляете то, что бы ресурсы одномоментно потребовало 30-40 контейнеров?
Поставили бэкапы в кроне на, скажем, 4 утра, когда внешняя нагрузка статистически минимальна.
на практике не наблюдается. Таки от HTTP нагрузка гораздо больше(внимание, мы сейчас говорим об ОЗУ/CPU).
А вот бэкап централизованный, хостера, он да, влияет на производительность, но им проще управлять.
Я другое видела: как серверы шаред-хостинга убивает яндекс или гуголь в час-в два ночи :) Буквально один сайт. На OVZ такого не бывает никогда: ну точнее, убивается контейнер, который агрессивно индексируют, а его соседи по серверу ничего не замечают.
А вот бэкап централизованный, хостера, он да, влияет на производительность, но им проще управлять.
Я другое видела: как серверы шаред-хостинга убивает яндекс или гуголь в час-в два ночи :) Буквально один сайт. На OVZ такого не бывает никогда: ну точнее, убивается контейнер, который агрессивно индексируют, а его соседи по серверу ничего не замечают.
а вот скажите мне вот какую простую вещь: fsync внутри контейнера приведёт к сбросу данных на диск только для него?
2. OpenVZ не имеет адекватных средств по изоляции виртуалок друг от друга. Пара примеров: mount list (позволяет сильно напрячь ядро из самого дешёвого контейнера), entropy drain.
Что я делаю не так?
[root@web33u ~]# time mount list
mount: can't find /root/list in /etc/fstab or /etc/mtab
real 0m0.125s
user 0m0.000s
sys 0m0.001s
[root@web33u ~]#
Проблема точно существует?
В госте:
while true; mount / / -o bind;done
(в тексте ошибка от крипткидди).
Оставьте на часика два и попытайтесь посмотреть команду mount от рута или с соседнего контейнера.
while true; mount / / -o bind;done
(в тексте ошибка от крипткидди).
Оставьте на часика два и попытайтесь посмотреть команду mount от рута или с соседнего контейнера.
:))) а еще, можно сделать цикл, который будет делать директорию, потом в ней еще одну, а в следующей еще одну. Если число инодов достаточное, можно создать проблемы хостеру (работает на шаред хостинге в OpenVZ), ему придется писать скрипт, который спустится в самый низ, и начнет удаление от туда.
Еще OVZ ноду можно убить, таря миллионы файлов.
Мне кажется, нужно попросить разработчиков ограничить число mount --bind для контейнера, что бы было в user_beancounters. Наверняка эту фичу реализовать совсем не сложно.
.
Только вот… стопроцентной изоляции нет нигде! Даже если у Вас дедик, вы можете уложить всех ваших соседей, если на вас пойдет большой UDP- DDoS, маршрутизаторы хостера могут не справиться
Еще OVZ ноду можно убить, таря миллионы файлов.
Мне кажется, нужно попросить разработчиков ограничить число mount --bind для контейнера, что бы было в user_beancounters. Наверняка эту фичу реализовать совсем не сложно.
.
Только вот… стопроцентной изоляции нет нигде! Даже если у Вас дедик, вы можете уложить всех ваших соседей, если на вас пойдет большой UDP- DDoS, маршрутизаторы хостера могут не справиться
100% изоляцию можно получить, организовав собственные сессии с аплинками. У нас есть крупные клиенты, которые именно так держат свои сервера, полностью автономно.
Что же касается «пойдёт большой DDoS» — про 400 гигабит я, конечно, читал, но своими глазами не видел больше 5 гигабит. 5 гигабит спокойно перевариваются (хотя жертву и придётся на отдельный хост переносить из-за гигабитного порта до коммутатора — сам коммутатор уже 20Гбитами до маршрутизатора идёт).
Что же касается «пойдёт большой DDoS» — про 400 гигабит я, конечно, читал, но своими глазами не видел больше 5 гигабит. 5 гигабит спокойно перевариваются (хотя жертву и придётся на отдельный хост переносить из-за гигабитного порта до коммутатора — сам коммутатор уже 20Гбитами до маршрутизатора идёт).
… Да, насчёт изоляции.
В этом и есть разница между гипервизорами и контейнерами. У гипервизоров конфликт бывает только за конечное число легко измеряемых ресурсов (IO, memory, CPU, network), а у контейнеров точек исчерпания ресурсов общего ядра очень много, и процесс их затыкания beancounter'ами напоминает процесс затыкания дырявого корыта на плаву. Одно заткнули, с другого потекло.
В этом и есть разница между гипервизорами и контейнерами. У гипервизоров конфликт бывает только за конечное число легко измеряемых ресурсов (IO, memory, CPU, network), а у контейнеров точек исчерпания ресурсов общего ядра очень много, и процесс их затыкания beancounter'ами напоминает процесс затыкания дырявого корыта на плаву. Одно заткнули, с другого потекло.
В этом и есть разница между гипервизорами и контейнерами. У гипервизоров конфликт
бывает только за конечное число легко измеряемых ресурсов (IO, memory, CPU, network),
а OVZ/PVC хорошо изолирует по CPU :)) почитайте про cpuunits, и cpulimit. Там выше была целая ветка обсуждения: OpenVZ даже, если хостер желает быть честным, позволяет считать фактическую производительность, и давать контейнеру работать с одной скоростью даже на разных CPU (ведь мегагерцы это те еще абстрактные попугаи).
Насчет network, как раз с помощью tc в OpenVZ можно сделать самодельные скрипты, которые будут шейпить контейнеры. Не нравится, что скрипты самодельные? Саппорт Параллельса мне говорил, что они добавят шейпинг в виртуозу, где она будет легко рулится через API с помощью биллинга хостера (не знаю, добавили, или еще нет)
> Если хостер Вам нагло не врет
По опыту работы с тем же МастерХостом, провайдеры в России любят оверселить «по самые немогу», притом на прямые вопросы отвечают просто — «ничего делать с вашим хост-сервером не планируем». Я к тому, что оверсел в России — это не «лучше сервера и выше з/п ТП», это скорее плюс в карман владельцам, либо возможность подольше не выводить из сервиса старые, перегруженные сервера, куда уже даже память не лезет.
Оверсел еще и к тому ведет, что, случись хостеру жить без этой «фичи», он бы в сервер с 64 Гб памяти засунул бы 120-126 виртуальных машинок по 512 Мб памяти (еще не страшно за качество работы каждой машины?), и они давили бы друг друга по IO и CPU, но хоть как-то бы жили. Когда, «спасибо» волшебной возможности дважды продать то же самое (в ГК это называется обман, но — о чем мы, это же мир ИТ!), в тот же сервер впихивают машин 160-180, и IO (внезапно?!) растет вообще до небес, после чего ТП только и может, что кивать на «мелкий шрифт» в договоре, мол, «никто Вам ничего конкретного не обещал». Совсем-совсем неправда, что, выбрав хостинг с оверселом, клиент автоматом оказывается на машине с надежным быстрым SSD-массивом, скорее, из наличия оверсела можно предположить жлобство и повышенную экономичность этого хостинга. До добра такое редко когда доводит (см. выше про то, что на стоимость серверов и оплату ТП в лучшую сторону это не повлияет).
Но за попытку убедить нас всех идти на оверселеный хостинг, право, могу поблагодарить. Что убедить у Вас получилось, не скажу, но аргументы послушать было интересно.
По опыту работы с тем же МастерХостом, провайдеры в России любят оверселить «по самые немогу», притом на прямые вопросы отвечают просто — «ничего делать с вашим хост-сервером не планируем». Я к тому, что оверсел в России — это не «лучше сервера и выше з/п ТП», это скорее плюс в карман владельцам, либо возможность подольше не выводить из сервиса старые, перегруженные сервера, куда уже даже память не лезет.
Оверсел еще и к тому ведет, что, случись хостеру жить без этой «фичи», он бы в сервер с 64 Гб памяти засунул бы 120-126 виртуальных машинок по 512 Мб памяти (еще не страшно за качество работы каждой машины?), и они давили бы друг друга по IO и CPU, но хоть как-то бы жили. Когда, «спасибо» волшебной возможности дважды продать то же самое (в ГК это называется обман, но — о чем мы, это же мир ИТ!), в тот же сервер впихивают машин 160-180, и IO (внезапно?!) растет вообще до небес, после чего ТП только и может, что кивать на «мелкий шрифт» в договоре, мол, «никто Вам ничего конкретного не обещал». Совсем-совсем неправда, что, выбрав хостинг с оверселом, клиент автоматом оказывается на машине с надежным быстрым SSD-массивом, скорее, из наличия оверсела можно предположить жлобство и повышенную экономичность этого хостинга. До добра такое редко когда доводит (см. выше про то, что на стоимость серверов и оплату ТП в лучшую сторону это не повлияет).
Но за попытку убедить нас всех идти на оверселеный хостинг, право, могу поблагодарить. Что убедить у Вас получилось, не скажу, но аргументы послушать было интересно.
Но за попытку убедить нас всех идти на оверселеный хостинг, право, могу поблагодарить. Что убедить у Вас получилось, не скажу, но аргументы послушать было интересно.
Дело в том, что на гипервизорах Вас оверселлят по CPU, дисковым iops, и сети.
Поэтому тезис о том, что «openvz оверселлит, а xen нет», является просто-напросто ложью. Ну и… я попыталась объяснить, что оверселлинг это не так плохо, как его рисуют некоторые не чистые на язык Xen-хостеры, сами втихаря оверселя.
Тут с Вами согласен. Я не очень просто поддерживаю ваше процитированное высказывание («Если хостер Вам нагло не врет...»), о том, что оверсел на OpenVZ суть хорошо.
Оверсел всегда плохо. По крайней мере тем, что не дает делать то, что от машины ожидаешь, и за что (согласно тарифу) и платишь.
Еще хуже, когда он есть, а о нем хостер говорит, что его нет. За такое (тут уж, правда, не в технологии дело) руки надо обрывать.
Так и приходишь к мысли, что либо идти к приличным (мало, но таких есть), либо брать физический сервер, со всеми вытекающими.
Я, кстати, встречал хостера, который прямо говорил, что с высоким потреблением CPU и диска клиент им на виртуалке не интересен (и сам будет недоволен, и другие будут жаловаться), и что под такую нагрузку советует взять сервер, даже готовы были скидку на сервер сделать, чтобы все оказались довольны. Таким людям руку жать хочется! :) Кстати, российские ребята, так что не все в России совсем плохо — но таких, как они, мало.
Оверсел всегда плохо. По крайней мере тем, что не дает делать то, что от машины ожидаешь, и за что (согласно тарифу) и платишь.
Еще хуже, когда он есть, а о нем хостер говорит, что его нет. За такое (тут уж, правда, не в технологии дело) руки надо обрывать.
Так и приходишь к мысли, что либо идти к приличным (мало, но таких есть), либо брать физический сервер, со всеми вытекающими.
Я, кстати, встречал хостера, который прямо говорил, что с высоким потреблением CPU и диска клиент им на виртуалке не интересен (и сам будет недоволен, и другие будут жаловаться), и что под такую нагрузку советует взять сервер, даже готовы были скидку на сервер сделать, чтобы все оказались довольны. Таким людям руку жать хочется! :) Кстати, российские ребята, так что не все в России совсем плохо — но таких, как они, мало.
Советуют ладно, но бывает, что выгоняют. То есть купил, грубо говоря, гигагерц CPU, нагрузил его на 100% и тебе аккаунт блочат.
Я, кстати, встречал хостера, который прямо говорил, что с высоким потреблением CPU и диска клиент им на виртуалке не интересен
Про CPU какой-то бред, от этого хостера нужно бежать. А вот за потребление i/o, да, могут выгнать на дедик.
Для Openvz
1. Не освещена проблема разделяемой памяти. Использование апача на OpenVZ рисковое занятие. (хотя может уже не актуально? просветите пожалуйста.)
2. Не освещена проблема загрузки модулей. Ну тут, конечно, всё от хостера зависит. Чаще всего нужны tun и dm-crypt, но их нет.
1. Не освещена проблема разделяемой памяти. Использование апача на OpenVZ рисковое занятие. (хотя может уже не актуально? просветите пожалуйста.)
2. Не освещена проблема загрузки модулей. Ну тут, конечно, всё от хостера зависит. Чаще всего нужны tun и dm-crypt, но их нет.
1. Не освещена проблема разделяемой памяти. Использование апача на OpenVZ рисковое занятие. (хотя может уже не актуально? просветите пожалуйста.)
Как раз писала об этом. ulimit в стартовом сценарии Апача решает
2. Не освещена проблема загрузки модулей. Ну тут, конечно, всё от хостера зависит.
Маленькие хостеры обычно соглашаются, а вот большие нет: не хотят иметь разный состав модулей на разных нодах. У больших все стандартизировано, и серверы поставлены неинтерактивно по сети с помощью, например, редхатовского кикстарта. Они не любят нестандарт, по тому, что сложно администрировать десятки и тем более сотни сильно отличающихся физических машин.
Почему в топиках, защищающих OpenVZ, никогда не пишут про вопиющую жесть — в OpenVZ в каждом контейнере ограничивается виртуальная память вместо RES/RSS? Или это как-то поправлено в последнее время?
Виртуальная память «бесплатна» везде, кроме OpenVZ (на реальных машинах и XEN/KVM), и многие программы ее выделяют с учетом того, что она «бесплатна» — ну java-машина, например, какая-нибудь. В том числе и ОС: для каждого потока место под стек выделяется заранее в виртуальной памяти (8Мб обычно).
Что это означает — под OpenVZ многопоточные программы могут занимать занимать в несколько раз больше памяти, чем на реальных машинах. И так и происходит, один и тот же простейший стек (LAMP из коробки) может на реальной машине требовать в 2 раза меньше памяти, чем под OpenVZ. Проблема не надуманная — мне кажется, что, например, дурная слава многопоточного Apache идет процентов на 50 из-за контейнеров с OpenVZ.
Т.е. для клиента цифры «512M RAM» под OpenVZ — это такое маркетинговое недоговаривание (т.е. вранье). 512-то 512, но это совсем не те 512, что просто на компьютере или при виртуализаци XEN/KVM (больше похоже на «недоделанные» 256). Даже если не вспоминать про OOM Killer. При этом ни разу не видел, чтоб писали как-то по-другому или поясняли этот вопрос.
Виртуальная память «бесплатна» везде, кроме OpenVZ (на реальных машинах и XEN/KVM), и многие программы ее выделяют с учетом того, что она «бесплатна» — ну java-машина, например, какая-нибудь. В том числе и ОС: для каждого потока место под стек выделяется заранее в виртуальной памяти (8Мб обычно).
Что это означает — под OpenVZ многопоточные программы могут занимать занимать в несколько раз больше памяти, чем на реальных машинах. И так и происходит, один и тот же простейший стек (LAMP из коробки) может на реальной машине требовать в 2 раза меньше памяти, чем под OpenVZ. Проблема не надуманная — мне кажется, что, например, дурная слава многопоточного Apache идет процентов на 50 из-за контейнеров с OpenVZ.
Т.е. для клиента цифры «512M RAM» под OpenVZ — это такое маркетинговое недоговаривание (т.е. вранье). 512-то 512, но это совсем не те 512, что просто на компьютере или при виртуализаци XEN/KVM (больше похоже на «недоделанные» 256). Даже если не вспоминать про OOM Killer. При этом ни разу не видел, чтоб писали как-то по-другому или поясняли этот вопрос.
что это означает — под OpenVZ многопоточные программы могут занимать занимать в несколько раз больше памяти, чем на реальных машинах
Вообще-то я об этом писала выше. В стартовом скрипте апача можно использовать ulimit, и проблема, о которой Вы рассказали, нивелируется.
Хм, в статье про VIRT и RSS ничего не увидел. Видел про своп, но это немного другая проблема. Ткнете в нужное место?
Ну и ulimit — это не решение, а костыль :) Причем это костыль только многопоточности (=="… в том числе ОС"); при других вариантов использования виртуальной памяти (заммэпить файл, например?) это не помогает ведь? В итоге минное поле получается какое-то — ставишь программу и не знаешь, будет ли она работать нормально или отожрет гиг памяти просто так.
Ну и ulimit — это не решение, а костыль :) Причем это костыль только многопоточности (=="… в том числе ОС"); при других вариантов использования виртуальной памяти (заммэпить файл, например?) это не помогает ведь? В итоге минное поле получается какое-то — ставишь программу и не знаешь, будет ли она работать нормально или отожрет гиг памяти просто так.
C выходом vSwap в OpenVZ осталось только два параметра: physpages и swappages.
physpages — лимитирует физическую память (RAM) для контейнера.
swappages — это свап.
Это все равно не очень честно, но очень близко к реальным значениям именно физической памяти. А виртуальная — да пусть хоть до конца космоса простирается. Если приложение захочет больше, чем есть физической, придет сначала всвап, потом оомкиллер.
При неправильной конфигурации еще сюда вклинится честный свап на хостноде, вот это уже плохо и пострадает вся ферма со всеми контейнерами. Ну, аккуратнее надо просто админу быть и понимать что делать.
physpages — лимитирует физическую память (RAM) для контейнера.
swappages — это свап.
Это все равно не очень честно, но очень близко к реальным значениям именно физической памяти. А виртуальная — да пусть хоть до конца космоса простирается. Если приложение захочет больше, чем есть физической, придет сначала всвап, потом оомкиллер.
При неправильной конфигурации еще сюда вклинится честный свап на хостноде, вот это уже плохо и пострадает вся ферма со всеми контейнерами. Ну, аккуратнее надо просто админу быть и понимать что делать.
Поделюсь своим опытом с виртуозо.
Как-то темной ночкой, на виртуалке через SSH набираю convert *.jpg бла-бла-бла в директории, где 500 картинок лежат, по 300-500 килобайт каждая. Жамкаю ентер — а оно тупо берет и зависает. В смысле насмерть зависает. Дозвонился до провайдера — он смог оживить машину только нажатием кнопки на системнике.
Следующей ночкой с ТП провайдера эксперимент повторили, и еще несколько аналогичных поставили. Пришли к выводу, что под пиковой «шоковой» нагрузкой виртуоззо действительно подвешивает хоста.
С KVM такого эффекта получить не смогли.
Как-то темной ночкой, на виртуалке через SSH набираю convert *.jpg бла-бла-бла в директории, где 500 картинок лежат, по 300-500 килобайт каждая. Жамкаю ентер — а оно тупо берет и зависает. В смысле насмерть зависает. Дозвонился до провайдера — он смог оживить машину только нажатием кнопки на системнике.
Следующей ночкой с ТП провайдера эксперимент повторили, и еще несколько аналогичных поставили. Пришли к выводу, что под пиковой «шоковой» нагрузкой виртуоззо действительно подвешивает хоста.
С KVM такого эффекта получить не смогли.
У меня таких случаев (на >100 физических нод с виртуозо, rhel5-based ядро) не было. По симптомам похоже на то, что развалился рейд, а последний оставшийся в нем диск тоже начал сыпаться.
а вы дайте один контейнер на растерзание местной публике. сразу оценим ))
Не дам. Выше сама привела несколько способов, как хостеру можно создать проблемы.
Только вот и дедик может растерзать соседей, устроив udp-поток через свой коммутатор, особенно хорошо получится с гигабитным аплинком.
Xen-KVM гости тоже смогут уложить физическую машину :)
Кстати, таких любителей-затейников как автор треда, хостеры обычно выключают. Ему попался добрый, склонный к эксперементам саппорт :))))
Но что imagemagick может уложить физическую машину на полтысячи картинок, это бред.
Только вот и дедик может растерзать соседей, устроив udp-поток через свой коммутатор, особенно хорошо получится с гигабитным аплинком.
Xen-KVM гости тоже смогут уложить физическую машину :)
Кстати, таких любителей-затейников как автор треда, хостеры обычно выключают. Ему попался добрый, склонный к эксперементам саппорт :))))
Но что imagemagick может уложить физическую машину на полтысячи картинок, это бред.
так как нет накладных расходов на запуск гостевых ядер и переключение контекстов
Рискую быть закидынным камнями, но откуда вы взяли такую глупость по поводу отсутствия переключения контекстов?
Хотите сказать что все контейнеры в OpenVZ работают в одном адресном пространстве?
Да, с ноды видны все процессы. Но внутри видны процессы только свои, лишние скрываются, а номера виртуализируются, то есть pid init-а равен единице.
Поэтому процесс, запущенный в Xen и KVM всегда будет работать медленнее, чем в OpenVZ
Поэтому процесс, запущенный в Xen и KVM всегда будет работать медленнее, чем в OpenVZ
Я не про процессы, а про отсутствие переключения контекстов.
Не разбирался, но по моему, утвержение безосновательное ибо слабо представляю как же так безопасно заставить работать много контейнеров в пределах одного адресного пространства, чтобы не было переключения контекстов между задачами.
Вовсе необязательно. Если посмотреть на технологию сбоку, то разницы нет, везде двухэтапная планировка выполнения задачи (сначала в гостевой ОС и потом в гипервизоре) и никаких дополнительных технологий по ускорению выполнения задачи у OpenVZ нет.
Думается мне, что если Вы возьмете виртуалку на xen и контейнер на OpenVZ, запустите на обоих тестовый код на Си, который будет в цикле считать 1 << 11 несколько млн итераций, то разницы не увидите (при условии, что на гипервизорах не будет сильной конкуренции за ресурсы)
Не разбирался, но по моему, утвержение безосновательное ибо слабо представляю как же так безопасно заставить работать много контейнеров в пределах одного адресного пространства, чтобы не было переключения контекстов между задачами.
Поэтому процесс, запущенный в Xen и KVM всегда будет работать медленнее, чем в OpenVZ
Вовсе необязательно. Если посмотреть на технологию сбоку, то разницы нет, везде двухэтапная планировка выполнения задачи (сначала в гостевой ОС и потом в гипервизоре) и никаких дополнительных технологий по ускорению выполнения задачи у OpenVZ нет.
Думается мне, что если Вы возьмете виртуалку на xen и контейнер на OpenVZ, запустите на обоих тестовый код на Си, который будет в цикле считать 1 << 11 несколько млн итераций, то разницы не увидите (при условии, что на гипервизорах не будет сильной конкуренции за ресурсы)
Не разбирался, но по моему, утвержение безосновательное ибо слабо представляю как же так безопасно заставить работать много контейнеров в пределах одного адресного пространства, чтобы не было переключения контекстов между задачами.
Точно так же, как работает cgroups. У нас одно ядро, одно адресное пространство, но есть группы процессов, к которым применяются ограничения(namespaces).
Думается мне, что если Вы возьмете виртуалку на xen и контейнер на OpenVZ, запустите на обоих тестовый код на Си, который будет в цикле считать 1 << 11 несколько млн итераций, то разницы не увидите (при условии, что на гипервизорах не будет сильной конкуренции за ресурсы)
В том-то и дело, что разница будет! В топике есть ссылка как раз на бенчмарк OpenVZ vs Xen.
Про переключение контекстов в OpenVZ
Таки попробую и проверю.
В том-то и дело, что разница будет! В топике есть ссылка как раз на бенчмарк OpenVZ vs Xen.
Таки попробую и проверю.
Но адресное пространство у контейнеров одно. Кстати, unix bench по вашей ссылке для Xen-а такой характерный: раза в два с половиной меньше, чем для native и .OpenVZ
Почитал тут немного, действительно вместо переключений контекса openvz следит за попытками использовать чужую память и просто ограничивает в случае необходимости.
В таком случаем более уместно сравнивать паравиртуализацию на xen c openvz, а не эмуляцию аппаратной части в xen c openvz.
В таком случаем более уместно сравнивать паравиртуализацию на xen c openvz, а не эмуляцию аппаратной части в xen c openvz.
В таком случаем более уместно сравнивать паравиртуализацию на xen c openvz, а не эмуляцию аппаратной части в xen c openvz.
Нет, совсем не уместно. Паравиртуализация подразумевает гостевое ядро с устройствами ввода-вывода (я о сети, дисках, итд) устроенными очень просто, не эмулирующими скази-иде-сата контроллеры, видеокарту, и др.
Есть еще паравиртуальные драйверы, когда ядро специально не модифицировано для использования простых устройств, но эти устройства, простые, реализованы драйверами.
OpenVZ, LXC, Jails, Solaris Containers же суть то же, что и chroot: как chroot организует не виртуальный диск, а лишь свое пространство адресов в файловой системе, так и openvz всего навсего организует namespaces для таблиц маршрутизации, правил iptables, номеров процессов, и тд.
Контейнеры это вообще не виртуализация, это просто такой навороченный chroot, который выглядит как виртуалка, и который работает практически со скоростью нативного «железа».
на OpenVZ нельзя FUSE, на Xen — можно. вернее, даже не так: большинство хостеров на OpenVZ запрещают FUSE. на Xen — нет.
Хостерам просто не хочется делать вот это:
openvz.org/FUSE
В силу ряда причин.
Одна из них, контейнер с такой штукой нельзя смигрировать онлайн для балансировки нагрузки. Делала бы сейчас OVZ хостинг средних размеров, просто предупреждала бы клиентов, что их могут неожиданно выключить на несколько минут, при перевозе на менее загруженный сервер, если у них OpenVPN или, скажем, FUSE.
openvz.org/FUSE
В силу ряда причин.
Одна из них, контейнер с такой штукой нельзя смигрировать онлайн для балансировки нагрузки. Делала бы сейчас OVZ хостинг средних размеров, просто предупреждала бы клиентов, что их могут неожиданно выключить на несколько минут, при перевозе на менее загруженный сервер, если у них OpenVPN или, скажем, FUSE.
Соглашусь, что каждая из систем виртуализации может лучше подходить для одних задач и не быть оптимальной для других. При должной глубине понимания той или иной системы, в принципе, реализовать задачи можно и на той, и на другой. Конечно, отождествлять системы, у которых различные уровни виртуализации по отношению друг к другу — не надо. Априори, использовать кастомные ядра для машин в OpenVZ/Virtuozzo не получится. С другой стороны, использовать машину на OpenVZ/Virtuozzo проще и легче, чем на Xen/KVM. Когда уровня виртуализации приложений — достаточно, зачем накручивать больше?
Есть другой вопрос. Тут пишут, что VPS/VDS на OpenVZ/Virtuozzo, при замеченных нагрузках от машины на ноде, выключают, или останавливают. Дело в том, что Xen-машину так же остановят, если увидят больше потребление ресурсов. Здесь вопрос более юридический, чем технический — кто за что блокирует. Безусловно, есть компании, которые, наоверселлив свыше крыши, при каждом чихе машины блокируют. Надо уходить от таких.
Есть другой вопрос. Тут пишут, что VPS/VDS на OpenVZ/Virtuozzo, при замеченных нагрузках от машины на ноде, выключают, или останавливают. Дело в том, что Xen-машину так же остановят, если увидят больше потребление ресурсов. Здесь вопрос более юридический, чем технический — кто за что блокирует. Безусловно, есть компании, которые, наоверселлив свыше крыши, при каждом чихе машины блокируют. Надо уходить от таких.
На Xen/KVM тоже выключают. Более того, иногда выключают дедики (за, например, udp DDoS на сайт на вашем дедике).
OpenVZ это не шаред хостинг, наоборот, значимая часть клиентов OpenVZ это «выгоненцы» с шареда с тяжелыми скриптами. В отличие от сервера шаред-хостинга, где 500-1000 клиентов на сервер, и за неделю-две кого-то обязательно выключают, OpenVZ-виртуозо VPS-ки выключают очень редко. На > 100 физических машин под виртуозой на моей прошлой работе одну VPS выключали в среднем раз в два-три месяца, и то это заканчивалась обычно тем, что с клиентом договаривались, что он диски больше грузить не будет, а не выгонянием на dedecated-сервер
OpenVZ это не шаред хостинг, наоборот, значимая часть клиентов OpenVZ это «выгоненцы» с шареда с тяжелыми скриптами. В отличие от сервера шаред-хостинга, где 500-1000 клиентов на сервер, и за неделю-две кого-то обязательно выключают, OpenVZ-виртуозо VPS-ки выключают очень редко. На > 100 физических машин под виртуозой на моей прошлой работе одну VPS выключали в среднем раз в два-три месяца, и то это заканчивалась обычно тем, что с клиентом договаривались, что он диски больше грузить не будет, а не выгонянием на dedecated-сервер
Вот из-за DDoS VPS-ки выключали чаще :( Или клиенты сами писали-звонили, что из-за DDoS у них лег VPS. Но проблему DDoS на моей прошлой работе иногда решали успешно фильтрацией зарубежных IP.
Да, все так и есть. Либо же могут «зайти» на машину и остановить нагружающий систему процесс. Кстати, Вы справедливо замечали — HN вполне себе живет с большой нагрузкой по процессору или памяти, при LA 800 и более, например. Видел HN с LA за 1000, и ничего. А вот при DoS'ах да, если просядет канал, будут загибаться все ноды на HN. Просто в Xen многое так же — тот же xentop отображает потребление основных ресурсов доменами, можно так же выключать. Более беспокоит то, что в России многие не брезгуют оверселлингом. Я все-таки считаю, что это плохо, то есть плохо, когда чрезмерно. Конечно, держать машины количеством вровень с физическими параметрами сервера — неразумно. Однако и в несколько раз больше пихать тоже не стоит. Если оверселл разумный — HN живет прекрасно. Но в России немало сильно перебирают, и вместо размазывания по другим HN, не имением оных, к примеру, по финсоображениям (что не редко есть), выталкивают клиентов на дедики. клиент, правда, также должен разбираться в размещаемых проектах на VPS. Иначе однажды появится бяка, а он не знает, что делать. Здесь как бы тоже юридический вопрос. Выключать такого, терять деньги на нем, под угрозой ухода, а не перехода на дедик, или разбираться в его контенте. Мало кто будет делать последнее.
Я правильно понял, что этой статье более 5ти лет?
www.hpl.hp.com/techreports/2007/HPL-2007-59R1.pdf
www.hpl.hp.com/techreports/2007/HPL-2007-59R1.pdf
Вот Вам ссылка на страничку с несколькими более свежими тестами:
openvz.org/Performance
А почему Вы думаете, что с тех пор что-то принципиально изменилось? Под гипервизором всегда софт будет работать медленнее, чем под native системой, а под контейнерами, OS-Level virtualization, практически с такой же скоростью, как нейтив, можно лишь считанные проценты туда-сюда перетасовать, но это соотношение по производительности никак не изменить, по тому, что такова их природа.
openvz.org/Performance
А почему Вы думаете, что с тех пор что-то принципиально изменилось? Под гипервизором всегда софт будет работать медленнее, чем под native системой, а под контейнерами, OS-Level virtualization, практически с такой же скоростью, как нейтив, можно лишь считанные проценты туда-сюда перетасовать, но это соотношение по производительности никак не изменить, по тому, что такова их природа.
Вот — habrahabr.ru/qa/39269/, живой пример отстойности openvz
Sign up to leave a comment.
Попытка развенчания мифов об OpenVZ, или VPS на OpenVZ vs Xen/KVM/Hyper-V/etc