0,0
рейтинг
21 апреля 2013 в 15:54

Разработка → Попытка развенчания мифов об OpenVZ, или VPS на OpenVZ vs Xen/KVM/Hyper-V/etc

Попытка развенчания мифов об OpenVZ, или VPS на OpenVZ vs Xen/KVM/Hyper-V/etc



По какой-то непонятной для меня причине на Хабрахабре сложилось негативное отношение к технологии OpenVZ вообще, и к OpenVZ хостингу в частности. Этот пост попытка развенчать мифы, касающиеся OpenVZ хостинга, Хотя на мой взгляд, OpenVZ так же едва ли не лучшее решение для разделения моногенных (Linux-only сервисов) внутри предприятия на собственных серверах.

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

Итак, тезис: бюджетные Linux VPS на OpenVZ, как правило, работают быстрее и стабильнее, чем бюджетные VPS, использующие гипервизоры. Дорогие VPS на гипервизорах, в «облаках» или с фиксированным тарифным планом, лучше, чем дорогие VPS на OpenVZ.



Так как топик опубликован не только в хабе Виртуализации, прошу не обижаться тех, кто администрирует фермы с большим количеством виртуальных машин и нод: я должна напомнить менее профессиональным читателям, что такое VPS

Так что такое VPS, и какие они бывают? VPS это Виртуальный Выделенный Сервер, который условно можно считать «настоящим» выделенным сервером, при этом администратор VPS имеет полный (в UNIX/Linux root) доступ к VPS-серверу, и может устанавливать любое программное обеспечение, совместимое с выбранной для VPS операционной системой, и используемой технологией виртуализации.
Синонимом термина VPS является VDS. На «буржуйском» VPS расшифровывается как Virtual Private Server, а VDS как Virtual Dedecated Server.

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

Разделяют две группы технологий для реализации услуги VPS:

а) Виртуализацию
б) Контейнеры

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

Наиболее популярные гипервизоры: VmWare ESXi(за пределами мира хостинга лидирующее решение для виртуализации), Xen, KVM, Hyper-V.

Контейнеры не создают, в отличае от виртуализации, для каждого VPS свою полноценную операционную систему, а создают на одном ядре большое количество изолированных окружений(name spaces), что позволяет не тратить хостеру ресурсы сервера впустую, а отдать их непосредственно VPS. Так же плюс контейнеров
заключается в том, что память и другие ресурсы, такие как дисковое пространство, не выделяются гостевой системе целиком (например, размер lun, отданного в распоряжение виртуальной машине в качестве диска, уже нельзя уменьшить).

Наиболее популярными(а так же технологически лидирующими, и лидирующеми по количеству инсталляций) технологиями контейнерных VPS являются Parallels Virtuozzo Containers и OpenVZ.

Главные недостатки заключаются в том, что на базе контейнеров можно предоставлять VPS только на той же системе, что и хост-система (для OpenVZ и Virtuozzo это Linux, в принципе, и так самая популярная ОС для VPS, основанных на любых
технологиях).

В целом, на базе гипервизоров можно построить услугу VPS, более качественную, стабильную и мощную, чем аренду выделенного сервера:

Мощная хост-система с топовыми CPU, поделенная с помощью гипервизора на десяток-полтора частей, с внешними дисками на быстрой дисковой полочке с десятками шпинделей, и High Available решением, перезапускающим VPS на новой ноде в
случае аппаратного сбоя хост-системы, заведомо стабильнее, производительнее, маштабируемее (всегда можно перейти на следующий тарифный план, или заказать новый VPS, который Вам развернут за минуты из шаблона) чем, возможно, любой самый дорогой физический сервер, который можно взять в аренду: крупные операторы вообще предпочитают сдавать в аренду «серверы», собирая их из десктопных комплектующих, даже без поддержки ECC-памяти, и продавая не очень разбирающимся людям мегагерцы десктопных процессоров, таких как Corei7, при этом стабильность работы такого железа в режиме 7/24 это не их проблемы.

При этом, такие VPS часто закономерно, как лучшая услуга, оказываются _дороже_ чем выделенные серверы, да и затраты на оборудование адекватно организованный хостинг на гипервизорной технологии требует очень не маленькие, поэтому такие сервисы как Amazone EC2, или, например, VPS от Leaseweb на VmWare ESXi с дисками на SAN с raid60 и стоят недешево: хостер не может продавать услугу ниже ее себестоимости.

К сожалению, среди пользователей услуги VPS господствует миф, который мы сейчас развенчаем:

«VPS на Xen лучше, чем VPS на OpenVZ/Virtuozzo»

На вопрос «чем лучше» обычно отвечают, что «хостер на OVZ оверселлит, и врет, и продает мои, честно купленные, потребителем услуги ресурсы другим клиентам, поэтому все тормозит! На Xen нельзя оверселлить!»

Обычно люди не понимают, что возможность обмануть клиента по сотне пунктов у хостера есть всегда, и технология тут совсем ни при чем…

Этот миф исскуственно подогревается некоторыми, вероятно, не очень добросовестными компаниями, предоставляющими дешевый Xen-хостинг.
Дело в том, что качественных VPS на гипервизорах, за те же деньги, что продаются VPS на OpenVZ, получить невозможно.

При эксплуатации хостинговых серверов часто возникает потребность, например, выключить физическую машину для профилактики, перевозки в другой дата-центр, апгрейда, что бы предоставить больше ресурсов клиентам на новых тарифах,
так как вычислтительная техника продолжает развиваться по закону Мура, удваивая вычислительную мощь каждые два года), да и в случае, если сервер ведет себя нестабильно, неплохо бы перенести VPS клиентов на новый сервер. Еще чаще возникает необходимость балансировки нагрузки: на одной ноде VPS продали слишком много, а на другой слишком мало. дешевые Xen хостеры вынуждены или выключать часть клиентов, и перевозить их offline на недогруженный сервер, или не обращать внимание на жалобы клиентов на перегруженном сервере : авось кто-то уйдет, и тормозить у остальных VPS перестанут!

Так вот, для того, что бы не выключать для клиентов сервис на несколько часов, нужна технология живой миграции, а она не совместима с дешевыми Xen VPS, так как требует от хостера инвестиций в SAN и сеть построения данных, и тогда уже нет смысла и закупать дешевые серверы: VPS на гипервизорах, или как сейчас часто говорят, в «облаках» это более качественная и «продвинутая» услуга, чем обычный сервер, и совсем не конкурент «контейнерным» VPS, прежде всего по цене.

OpenVZ и Virtuozzo контейнеры позволяют прозрачно для клиентов, online, переносить VPS с физического сервера на физический сервер без дорогостоящих инвестиций в сеть хранения данных.

Что касается «оверселлинга», это миф, так как наоборот, возможность оверселлинга для клиента хостера благо, так как ни один VPS, если он работает стабильно, не находится 100% времени возле пределов своего тарифного плана (иначе сервисы на VPS будут работать нестабильно и медленно, и тарифный план был выбран неверно).

При использовании обычных, выделенных, невиртуализированных серверов (colocation или dedicated) большая часть ресурсов сервера так же простаивает, и клиент платит за эти холостые такты.

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

При десятках VPS на физический сервер вероятность того, что всем клиентам одновременно потребуются их ресурсы, стремится к нулю. Зато она часто существенна при количестве VPS до десяти-пятнадцати на сервер, что часто встречается у Xen-хостеров, таким образом оверселлинг по CPU для «честного» Xen хостера гораздо более вероятен, чем оверселлинг по памяти для хостера OpenVZ

Можно добавить, что в рамках контейнерной технологии выше производительность, так как нет накладных расходов на запуск гостевых ядер и переключение контекстов: например, можно посмотреть бенчмарк Xen vs OpenVZ компании HP, в котором можно увидеть, что разница очень и очень существенна:
www.hpl.hp.com/techreports/2007/HPL-2007-59R1.pdf

Так же в адрес Xen часто раздается критика по поводу производительности дисковой подсистемы, причем даже со стороны разработчиков других гипервизоров, того же KVM, да и Xen-хостеры часто лукавят: оверселлинг по CPU в Xen так же возможен.

Кроме того, VPS на Xen, KVM, Hyper-V с локальными дисками, без SAN, всегда катастрофически медленнее VPS на OpenVZ с локальными дисками из-за технологии vzswap.
Я бы сказала, что vzswap это такая убер фича OpenVZ VPS, которая, правда, включена не у всех OVZ хостеров.
Клиент, купивший VPS на гипервизоре, делает у себя swap файл. Когда его VPS «ложится» от, например, мощного DDoS, его приложения уходят в swap, от интенсивного ввода-вывода страдают соседи по физическому серверу. Очень тяжело помешать Вашему соседу по физической машине создать такой файл.
Напомню, если кто-то не знает, или забыл, виртуальную память можно представить как RAM(планки памяти DDR/DIMM/SIMM на x86/x86_64 компьютерах) + swap (файл или раздел подкачки).
В технологии OpenVZ свапинг осуществляется централизованно ядром, клиенту выделяется виртуальная память в качестве «RAM» и… виртуальная память в качестве «swap». Память vzswap тоже виртуальна! Только исскуственно замедленна, и обычно находится не в физическом swap, а в физическом RAM. Когда VPS начинают DDoS'ить, и она уходит в swap от десятков-сотен процессов апача, или сотен тысяч sql-запросов, VPS естественным образом замедляется, так как vzswap медленная память! Но диск физического сервера при этом не используется, так как ядро будет сбрасывать в настоящий swap только те данные, которые долго не использовались, что очень радикально скажется на производительности ввода-вывода для всех VPS.

В заключение хотелось бы напомнить о парадоксе заключенных из Теории Игр, текст из википедии:

Двое преступников, А и Б, попались примерно в одно и то же время на сходных преступлениях. Есть основания полагать, что они действовали по сговору, и полиция, изолировав их друг от друга, предлагает им одну и ту же сделку: если один свидетельствует против другого, а тот хранит молчание, то первый освобождается за помощь следствию, а второй получает максимальный срок лишения свободы (10 лет). Если оба молчат, их деяние проходит по более лёгкой статье, и каждый из них приговаривается к 0,5 года. Если оба свидетельствуют против друг друга, они получают минимальный срок (по 2 года). Каждый заключённый выбирает, молчать или свидетельствовать против другого. Однако ни один из них не знает точно, что сделает другой. Что произойдёт?


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

Тут некоторые Xen-хостеры, нападая на OpenVZ, часто используют низменные наклонности человеческой натуры, желание сыграть эгоистично в игре «парадокс заключенных», а так же врут, лукаво умалчивая про то, что они оверселлят процессор: у них на одном ядре CPU может быть несколько VPS, которые будут друг другу мешать.

Резюмируя, на сегодня лучшим выбором бюджетного VPS является только OpenVZ/Virtuozzo, а «гипервизорные» и «облачные» VPS, уже теснят услугу аренды физических выделенных серверов: если Вам нужна гибкость и стабильность услуги, и под проект есть бюджет, о таких VPS стоит задуматься уже сейчас.

UPDATE Судя по комментариям, и тому негативу, что мне написали в личке, не все поняли, что этот топик не против Xen, Kvm, VmWare и др. гипервизоров в хостинге, он наоборот за них, когда хостинг использует сеть SAN или хотя бы DAS, топик немножко против дешевых Xen хостеров, и в первую очередь, топик написан за OpenVZ
Ксения Лисовская @sHaggY_caT
карма
61,2
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (278)

  • +5
    крупные операторы вообще предпочитают сдавать в аренду «серверы», собирая их из десктопных комплектующих

    кажется это камень в огород одного неплохого немецкого хостера. а вообще всё же просто: не хотите попасть на оверселинг — покупайте физический сервер. жалко денег на администрирование физического железа? страдайте от оверселлинга.
    • 0
      Именно так и есть, автор много раз (не в этой статье) упоминает о не-серверном железе от хетзнера. Не иначе как в угоду своей компании :)
      • 0
        Да нет же :) У меня нет своей компании (полтора года назад была, бизнес закрыт). Я обычная наемная офисная служащая (UNIX администратор) в настолько крупной компании, что я в ней просто винтик. Разумеется, никто мне права писать от имени этой компании не давал.

        Кстати, у меня у самой дедик у того хостера, у кого «серверы» из PC :) И да, там стоит OpenVZ, на которой раздаются VPS знакомым (за сервер платит один из личных клиентов)
        • 0
          А этот клиент в курсе, что он платит за вэдээски вашим знакомым? :)
          • +1
            Он в курсе, что он оплачивает целиком сервер для меня, получая на нем две VPS под свои задачи.
            Остальной сервер мой. Это его оплата моих услуг ему.
    • 0
      а вообще всё же просто: не хотите попасть на оверселинг — покупайте физический сервер. жалко денег на администрирование физического железа? страдайте от оверселлинга.


      В моем топике высказан очень спорный тезис о том, что оверселлинг это не плохо, а наоборот хорошо: хорошо и для хостера, и [b]для клиента[/b]. Понимаю, что вникнуть в это тяжело, но попробуйте хотя бы не отвергать его сразу!

      В качестве обоснования привела пример из теории игр. Можно Вас попросить перечитать мой топик еще раз? Может быть, это заставит Вас изменить точку зрения на оверселлинг?
      • +3
        Может Вы заодно вспомните про IOPS — и как это все хорошо :)
        Если по CPU и RAM жить еще можно — то вот по диску — это будет эпик фэйл.
  • 0
    В статье куча несуразности, например:
    Так же плюс контейнеров
    заключается в том, что память и другие ресурсы, такие как дисковое пространство, не выделяются гостевой системе целиком (например, размер lun, отданного в распоряжение виртуальной машине в качестве диска, уже нельзя уменьшить).


    Такое впечатление, что писал человек, приверженный openvz, то есть не беспристрастно.

    Чего стоят только абзацы о миграции в реальном времени.

    PS: С Вами знаком еще с opennet, там Вы проявляли себя более лояльно.
    • +4
      Это не несуразность :) Вы заходили когда-нибудь под рутом на хост-систему с OpenVZ или FreeBSD Jails?
      Загляните вот сюда:

      ls /vz/{root,private}/[VEID]/

      и увидите файловую систему контейнера. Как Вы думаете, файлы VPS-ок, сложенные в файловой системе хост-системы, и файлы, которые находятся внутри файлов или, например, внутри LUN рейд контроллера, займут столько же места? Как бы не так!

      А фичи того же KVM вроде baloon технологии, для оверселлинга ОЗУ, можно включить только с согласия администратора VPS, и для хостинга не годятся!
      • +3
        Не хочу превращать данный диалог в холивар, но достаточно одного пункта, который играет решающюю роль при выборе openvz vs XEN/KVM, для знающего человека, берущего VPS в аренду, это возможность использовать своё ядро.
        В openvz, прикрутить модуль или поменять ядро не представляется возможным или только с бубном и письмами, а это значит, что сервер неполноценен.
        • +2
          Вам так часто нужно собственное ядро или собственный модуль? Особенно на дешевом VPS хостинге? Можете привести примеры?
          Кстати маленькие, дешевые OVZ хостинги очень часто могут пойти Вам на встречу, и загрузить нужный Вам модуль, дав Вашему VPS права на доступ к его устройству в /dev
          • –3
            Несомненно часто, и не только мне, а, я считаю, многим.
            Нет кишит вопросами про то, как добавить модуль в iptables на openvz — никогда не интересовались?
            а tap/tun вопросом под openvz, неужели ни разу не сталкивались?

            Да просто осознание того, что ты заплатил на неполноценный сервер, уже угнетает душу :)
            • +5
              OpenVPN прекрасно работает в контейнере под OpenVZ. Почему некоторые OVZ хостеры запрещают с ним работать, для меня совершенно не понятно.
              Модули iptables тоже можно добавить на ноду.

              В общем, это вопрос отношений с хостером.

              Да просто осознание того, что ты заплатил на неполноценный сервер, уже угнетает душу :)


              Мое ИМХО (не обижайтесь пожалуйста!) Вы стали жертвой широкомасштабной агитации против OpenVZ на хабрахабре.
              Мой топик преследовал только одну цель: исправить положение, и объяснить, что OVZ не так плох, как его на хабрахабре рисуют, а Xen, KVM, hyper-V VPS-ки не настолько хороши, если хостер не использует для хранения виртуалок SAN/DAS, а данные VPS лежат локально. \
              Честное слово, у меня нет никакого коммерческого интереса! Просто обидно за, на мой взгляд, потрясающую технологию (OpenVZ), хотела лишь защитить ее от несправедливых нападок!
              • –9
                Никаких обид лично на себя не принимаю, но эти Ваши слова, про «жертв широкомасштабной агитации», камень в огород всего Хабр-сообщества, которое так считает — Вам это не кажется?

                • +6
                  Создав этот топик, я пошла на определенный риск, уйти катастрофически в минуса по репутации, и впредь всегда молчать на Хабра Хабре, но было слишком обидно за репутацию OpenVZ, настолько, что захотелось переломить ситуацию, и объяснить, что не все то белое, что кажется белым, и не все то черное, что кажется черным.
                  Иногда над ситуацией, где хороший VPS, а где " неполноценный", стоит подумать еще раз.
                  • +1
                    Не переживайте вы так… Профессионалов прежде всего отличает умение использовать инструменты по назначению.

                    Админ, который действительно понимает, что такое производительность, системные ресурсы и время администратора, не будет использовать xen, там где можно обойтись контейнером. И контейнеры там, где не требуется серьезная изоляция и можно обойтись отдельным аккаунтом. Лично для меня тут нет предмета для обсуждения…

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

                    Для тех, кто в мыслит категориями «круто, не круто», администрирование это очевидно хобби, и всерьез их воспринимать вряд ли стоит…
            • –2
              Да просто осознание того, что ты заплатил на неполноценный сервер, уже угнетает душу :)


              Лично для меня это основная причина :)
            • +1
              Да просто осознание того, что ты заплатил на неполноценный сервер, уже угнетает душу :)

              Отличный аргумент для профессионала…
              • +1
                Шашечки кому-то важнее, чем ехать 0))
        • 0
          своё ядро ценой потери sendfile/splice/tee и других чудесных системных вызовов?
      • 0
        Файлы? Для контейнеров? Всегда выделял виртуалкам LVM-разделы. Кстати, поменять их размер можно и без перезагрузки.
        • +1
          Я тоже на KVM/Xen выделяю виртуалкам LVM тома, хотя у LVM есть много недостатков. Если Вы внимательно прочитаете пост, то увидите там:

          например, размер lun, отданного в распоряжение виртуальной машине в качестве диска, уже нельзя уменьшить


          LVM том вы тоже не сможете оверселлить. Это не промышленная SAN с дедубликацией и даже не ZFS.
          LVM том Вы сможете сделать для VPS клиента меньше только при смене клиентом тарифного плана, и продать то место, что не не использует, не выйдет. Ладно, если у Вас SATA диски, а если сверхдорогие SSD? Или дороговатые SAS?
          • 0
            LVM тома оверселлить можно.
            С версии ядра 3.2 или 3.3, не помню ужо.
            • +2
              Угу, а еще Live Migration уже есть в KVM fedora между стораджами. Только сколько регрессий в этих ядрах?
              Может быть, у меня не точка зрения большинства, но мне больше нравится ядро RHEL6 на сервере.
              • +2
                И еще, наверняка ведь есть деградация производительности при включенной дедубликации? Она даже на промышленных SAN иногда ощущается :(

                LVM и так мягко говоря не быстрый, если сделать снапшот, и имеет кучу других проблем, так вы еще и дедубликацию включаете: ничего этого не нужно на дешевой машине с OpenVZ: все данные клиентов на одной файловой системе, есть Live Migration, есть vzswap
                • +2
                  А кто сказал про дедупликацию? Я говорю про то, что можно создать LVM томов на больший объём, чем есть в vg. Писать после заполнения всего vg не дадут, само собой. Никакой деградации в производительности здесь нет.

                  LVM — быстрый. По крайней мере, достаточно быстр для своих задач. Оверхед от его использования не сильно превышает оверхед от использования аналогичного количества партиций на диске. Снапшоты — медленные, если в них писать. Но чего вы ещё ждете от них О_о? Вы бы ещё сказали, что galera медленно коммитит UPDATE в базы.

                  По поводу все «данные клиентов на одной файловой системе» — тут тоже все не так просто. Openvz с большим количеством виртуалок по IO проседает намного сильнее, чем LXC с lvm томами. Главная причина, понятное дело, квоты. Но их можно отключить. Но есть и вторая причина — уровень абстракции, при помощи которого ovz ограничивает виртуалки в пределах этой фс (короче, simfs). Эта штука — достаточно медленная в условиях большого количества конкурентных запросов. И с этим вы уже ничего не сделаете. Более того, при 8 виртуальных машинах на SATA-дисках (enterprise-дисках) у вас 8 виртуалок в KVM на LVM томах будут получать суммарно больше IO, чем 8 виртуалок через simfs без квот.
                  • 0
                    Можно тесты в студию?
                    И Вы опять таки забываете про vzswap, а еще про vzfs, может, Вы и ее тестили?

                    А что касается lvm, с ним постоянно у многих возникают странные проблемы (у меня никогда не было, так как я с ним всегда аккуратно обращалась) шаг влево-щаг вправо расстрел.

                    Я думаю, для Вас не секрет, что у многих в телекоме предубеждение против LVM, и многие его просто не используют.
                    • +1
                      vzfs — «virtuozzo feature».

                      vswap не поможет вам, если у вас mass IO в сторадж. Помогут хорошие fs-cache, да кто ж о них у хостеров думать будет. А свой собственный fs-cache мне не дают в openvz, да.

                      > у многих возникают странные проблемы
                      В линуксах всё повторяет кривизну рук владельца. У меня вот сеть всегда плохо работает, да…

                      Про тесты записал в тудушку, в блоге опубликую.
                      • +3
                        Очень жду… Но пока (не обижайтесь, пожалуйста!) позвольте сомневаться в Ваших выводах.
                        У меня OpenVZ даже на офисных задачах (не говоря о хостинговых!) делает по производительностильности KVM и очень существенно.
                        Бенчмарков я не делала, но в топике запостила бенчмарки HP xen vs openvz
                        Хотя в офисах обычно использовала комбинированные ядра KVM+OpenVZ (что бы Windows виртуализировать).

                        Кажется, мне тут готовы приписать ненависть XEN/KVM или ESXi, тогда как при наличии бюджета я бы и хостинг, и в офисе серверную инфраструктуру сделала с гипервизором (а не контейнерами) и виртуалками на полочке с дисками, хотя бы с «хвостами» SAS для двух серверов.
                        • 0
                          > делает по производительностильности KVM и очень существенно.
                          Это уж точно ересь. Ради такого я даже танк достану и постреляю в одинаковые конфиги.
                          Я могу поверить, что openvz выигрывает при большом количестве машин (8 или больше), но раньше — вряд ли. А уж при виртуализации 1в1 делает vz в хвост и гриву.
                          В те же тесты внесу тогда обстрел одинаковой конфигурации.

                          > гипервизором (а не контейнерами)
                          openvz — тоже гипервизор.

                          > приписать ненависть XEN/KVM или ESXi
                          ненависть приписать не готовы, а вот излишнюю любовь к ovz — вполне. Ну и любовь к rhel.
                          Ещё раз — не нужно писать столь безапелляционные посты. Openvz ни плох, ни хорош. Это инструмент. Инструмент, который хорошо работает при одних условиях и плохо при других. Вы же описываете всё столь безоблачно, что прочитавший вас сисдамин с 5ю сотнями dom0 машин должен пойти и снести оттуда весь lxc и понаставить ovz.
                          (кстати, lxc я бы вам в офисе настоятельно порекомендовал — вам же изоляция непробиваемая не нужна и вы администрируете сами виртуалки тоже?).
                          • +2
                            Изоляция это практически всегда и изоляция безопасности. Даже для офисного сервера.
                            Кстати, в LXC нет аналога не только vzswap (lxc.cgroup.memory.memsw.limit_in_bytes это не аналог. Почему, написала в топике), но и аналога cpulimit, а так же нет того изящного решения, что есть в OVZ с cpuunits (читали же про бенчмарк, и cpuunits, которые power of node?).
                            Без этого, а так же без Live Migration он не нужен. Гасить «сервер» в офисе без hotswap, и тем самым переводить кучу сервисов в down, совсем не хочется (как и работать во внерабочее время)

                            openvz — тоже гипервизор.


                            Вы серьезно? Может и jails гипервизор, и chroot? Если Вы в этом уверены, сделайте доброе дело, исправьте википедию!
                            • 0
                              Эм. Как это нету? В любом линуксе есть аналог vswap — swap-файл в ramfs ;)
                              С учетом того, что ovz пока не очень хорошо освобождает vswap, когда нужна память под приложения — получается вполне себе сравнимое решение.

                              cpuunits есть — cpuset.sched_load_balance
                              cpulimit по количеству ядер — cpuset.cpus (а в lxctl и он не нужен, само разберется). Возможности выдать «полтора ядра» действительно нет.

                              Живой миграции нет, пока. Впрочем, есть checkpointing — его хватает.

                              Ну ок, вам lxc не подходит. Мне ovz не подходит. На том пока и сойдемся =)
                              • +2
                                Эм. Как это нету? В любом линуксе есть аналог 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, они даже пишутся похоже!
                                • +2
                                  Что за vzswap такой никому неизвестный?

                                  Про vswap же на каждом заборе написано.

                                  CPUunits отродясь определял приоритет запросов к CPU между виртуалками. Как раз то же самое делает и cpuset.sched_load_balance. Что-то изменилось?

                                  cpulimit, кстати, есть — cpu.shares. 100% процессорного времени — 1024 единицы. Непривычно первое время и нужно переписывать при миграции на машину с другим количеством ядер, но, опять же — нельзя сказать «нету».
                                  • +2
                                    Что за 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
                                      Ы. Забавно. Поковыряюсь, спасибо.

                                • –2
                                  Я вам скажу как админ более 1к VPS на OpenVZ.
                                  Если бы не желание клиентов такой гадости на наших серверов бы не было.
                                  Вечные глюки с checkpoint, с остановкой квот и хардлоками.
                                  Огромный оверхед на клиентских квотах.
                                  В общем — ну нафиг, лучше мы будем иметь меньшую маржу, но будем давать клиентам безглючную услугу на XEN.
                                  Главное чтобы клиенты это поняли и не нужно пытаться их переубеждать что «говно не так плохо пахнет».
                                  • +3
                                    По-моему, все наоборот: продвинутые клиенты не любят OpenVZ (так как якобы оверселлинг в отличие от «честного Xen»), большинству клиентов справедливо просто пофик, им важно, что бы было дешево и качественно, а OVZ нравится бизнесу.
                                    Если Вы думаете, что нет глюков у Xen и у KVM, имхо, Вы живете в виртуальной реальности :))
                                    • +1
                                      Тогда расскажите о «глюках XEN».
                                      А то уже 5 лет с ним работаю и неисправимого конфигом глюка не видел.
                                      • +2
                                        Как будто бы багтрекер xen-а всегда был пуст, и в нем ничего не было :)
                                        Вы сами понимаете, о чем пишите?
                                        Например, масса глюков и регрессий с паравиртуализированными ядрами были.
                                        FreeBSD только недавно вот научилась не падать в DomU
                                        • 0
                                          А фряха пока официально и не поддерживается. Допилят — тогда и посмотрим.
                                          • +2
                                            А как там драйвера для Windows поживают от коммюнити? Давно ли синие экраны прекратились, что Вы об этом уже забыли?
                                            • 0
                                              Давно.
                                              Уже года 2 не видел.
                                              • 0
                                                Просто Вы написали же, что глюков нет, и никогда не было. Никаких. Это же ложь!
                                                Вы откройте багртрекер xen-а и посмотрите: их там тысячи!
                                                • 0
                                                  Я такого не писал.
                                                  Вы читаете только то что вам хочется.
                                            • –1
                                              Почти 5 лет на XCP+XenServer. Не видел экранов.
                                              Хотя не. Вру. Недавно встретил баг на древней виртуалке с 2к3 после переезда на xcp 1.6, решилось установкой старой версии дров/тулзов. Там дисковые io тормозили, если у системы больше одного ядра. Если бы не жадность админа из отдела, заказавшего ее, то мы бы баг не заметили. :)
                                              • +1
                                                на XenServer проприетарные драйвера для Windows, а не драйвера от коммюнити.
                                                XenServer нужно сравнивать не с GPL-ым OpenVZ, а с тоже частично проприетарной Virtuozzo
                                                • 0
                                                  Странно. А в xcp тогда какие, если она сама под GPL? Надо будет на досуге глянуть диск с исходниками на предмет исходников дров/тулзов.
                                                  • +1
                                                    Лучше старые релизы посмотрите :)

                                                    Это то, с чем лично я столкнулась: паравиртуальные драйвера GPL для Windows в Центоси были совершенно неюзабельны, а вот в XenServer были относительно нормальными.
                                                • 0
                                                  XCP забываете.
                                      • 0
                                        Присоединяюсь. Тоже хотелось бы услышать.
                                        За все время хапнул глюки в xen только два раза — включил openvSwitch когда его впилили, но официально не включили. Второй раз — когда попробовал вкомпилить в ядро dom0 одну экспериментальную, но очень нужную штуку. Но в обоих случаях я ССЗБ :)
                                  • 0
                                    Кстати, про глюки чекпоитинга: угу, иногда сам выгружается vzcpt, например. Но это же лечится костылём в кроне!
                                    • 0
                                      Да чего там, давайте тогда уж сразу патчи OVZ на ядро править.
                                      Зачем оно надо когда есть стабильные технологии?
                                      Дедлоки на mount кстати уже больше года в багтрекере висят.
                                      Пока глухо.
                                      • +1
                                        можно номер бага? Кажется, я поняла, о чем Вы говорите.
                                        А зачем Вы делаете перекрестный mount между контейнерами?
                                        • 0
                                          Номер бага искать лень.
                                          Помню что открывали ребята из fastvps.
                                          Я не делаю никаких перекрестных mount.
                                          openvz делает не полный umount при остановке.
                                          И «доделать» его нельзя.
                                          Только перезапуск ноды.
                                          • +2
                                            Ага, тоже сталкивалась с этим на ядре пятой шапки. На шестой шапке проблема встречаться перестала (во всяком случае я не сталкивалась).
                                            Это не баг, это возможности Linux ядра. Дело в том, что процессы в статусе D линукс ядро, по команде kill -9 $PID, научилось убивать не сразу.
                                            Сейчас уже умеет :)
                                            В общем, мимо кассы.
                                            • 0
                                              Речь о 2.6.32.
                                              Блокирующие процессы не убиваются.
                                              Проблема ядерная.
                                              Так что мимо кассы вы.
                                              • +1
                                                в Bugzilla OpenVZ есть несколько багов с DeadLock. Сейчас они все закрыты, кроме 2156 (его пометили как Dublicate 2110)

                                                Причем у меня это проблема не наблюдается.

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

                                                Разработчики вот патч написали для тестового ядра :) Скоро исправят в production ядре. Баги есть везде, главное, что бы их исправляли.
                                                • 0
                                                  У кого-то есть желание тестить баги на живых клиентах?
                                                  XEN 4.1 работает как часы.
                                                  XEN 4.2 также на тестовом проблем не показывает, но на продакт пока не ставим.
                                                  Частые обновления ядра на ноде — зло.
                                                  Конечно если вам не жалко свои нервы и своих клиентов… Кактус вас ждет…
                                                  • +1
                                                    У _меня_ нет этой проблемы. У кого есть, могут откатиться, поискав непроблемное ядрышко, или дождаться фикса.
                                                  • –1
                                                    И еще: у меня нет опыта работы с Xen-хостингом в качестве администратора. Я использовала до трех Xen нод и дешевую хранилку для офисной виртуализации, и low-cost лотерею с drbd и двумя нодами под Центосью, поэтому сразу вспомнила о багах паравиртуализированных систем.
                                                    Уверена, что приверженец VmWare, который использовал Xen, назвал бы Вам кучу проблем Xen-а на больших инсталляциях!
                                                    Да тут на ХабраХабре и были такие топики.

                                                    Ваше заявление о том, что с Xen нет и никогда не бывает, и не может быть никаких проблем и глюков, оно очень спорное: баги бывают даже в прошивках коммутаторов Циски.
                                                    Мне тяжело его опровергнуть, так как я не видела большого Xen хостинга.
                                                    А Вы явно предвзяты. Вот, другой администратор OVZ, Xen, LXC не настолько ненавидит OVZ, как Вы :)
                                                    • +2
                                                      Вы не объективны, т.к. вы не работали с Xen.
                                                      Я не предвзят т.к. в одинаковом количестве содержу и XEN и OVZ ноды, также есть LXC для работы внутренних систем. но это другая история.
                                                      • 0
                                                        Я работала с Xen, но на не массивных инсталляциях. OpenVZ, и особенно Virtuozzo, администрировала на массивных (более ста физических машин).
                                                        Так же я видела Xen-хостинги у моих собственных клиентов (когда занималась аутсорсингом), дешевые и не очень.
                                                        Так что с Вашим обвинением в необъективности несогласна :)

                                                        Качество Xen-VPS всегда так хорошо скачет вверх, когда за 256мегабайт ОЗУ на сервере в Европе просят от 20 долларов.
                                                        Обычно у хостера в этом случае хватает денег на SAN.
                              • 0
                                а чекпоинтов нет =(
                            • 0
                              > Вы серьезно? Может и jails гипервизор, и chroot? Если Вы в этом уверены, сделайте доброе дело, исправьте википедию!
                              Даже исправлять ничего не буду — en.wikipedia.org/wiki/Hypervisor
                              Гипервизор — это сущность, которая создаёт и управляет виртуальными машинами. Способ реализации не важен.

                              Chroot — нет, там ничего не виртуализируется. Jail — да, гипервизор в чистом виде, с виртуализацией сети, стораджа (если нужно), виртуализацией CPU (проброс 2х ядер CPU из 32х — это тоже своего рода виртуализация, а не просто ограничение по ресурсам).
                              • +2
                                Объясните мне пожалуйста, чем принципиально отличается chroot от OpenVZ, jails, или Solaris Zones?
                                А в chroot как раз виртуализируется файловая система :)))
                                Это называется name spaces: может быть на файловую систему, как у jails, а может быть и на сетевой стек, iptables, ppid процессов, и тд.
                                Кстати, как там с виртуализацией сетевого стека в LXC? Все так же кисло как и три года назад? А iptables никогда не будет?
                                • 0
                                  > Объясните мне пожалуйста, чем принципиально отличается chroot от OpenVZ, jails, или Solaris Zones?
                                  В chroot не виртуализируются устройства. Доступ к физическим ресурсам просто «ограничивается». Да и не я придумал, что chroot — не гипервизор =)

                                  В openvz есть simfs, отдельные сетевые устройства, уровень абстракции вокруг виртуальной памяти (адреса памяти отличаются от тех, которые у того же блока памяти на dom0) и так далее. Вполне себе взрослый гипервизор.
                                  В jail — аналогично. Про солярку ничего не скажу.

                                  > Кстати, как там с виртуализацией сетевого стека в LXC?
                                  А что с ним было не так? Классический вариант — бридж на dom0 + eth в виртуалке никуда не делся. Macvlan тоже можно использовать. Netfilter у каждого контейнера независим (конечно, conntrack включенный на одной виртуалке включит его их и на остальных, но это последствия shared-ядра). А правила писать можно сколько влезет.

                                  Там главные проблемы вокруг /proc сейчас. Его никто не хочет виртуализировать (дорого и медленно), а пересечения /proc разных виртуалок дают кучу неприятных моментов — от проблем с sysctl до возможности пострейсить или по-gdbшить чужой процесс, если знать pid.
                                  • +2
                                    Мне все-таки нравится определение, что гипервизор это (микро)ядро, крутящееся на dom0, и запускающее гостевые ядра.

                                    В этом и есть принципиальная разница между Os-level virtualization (chroot, jail, openvz, solaris zones, etc) и гипервизоров (Xen,KVM, Vmware, Hyper-V)

                                    а что касается того, что chroot не виртуализирует devfs и proc, а должен был? LXC тоже не виртуализирует, например, таблицы iptables, просто chroot такой вот примитивный контейнер.
                                    • 0
                                      > Мне все-таки нравится определение, что гипервизор это (микро)ядро, крутящееся на dom0, и запускающее гостевые ядра.
                                      Это определение так называемого «native hypervisor». Собственно, в той же статье про это и написано. Openvz — hosted hypervisor. Просто другой тип виртуализации, но это всё ещё виртуализация. Более того, есть ещё виртуализация как сущность, а не как виртуализация ОС (java, например). Но там действительно нет гипервизора (точнее, принято так считать).

                                      Ну то есть гипервизор — это не какое-то ядро, а просто сущность, управляющая гостевыми машинами. И запускает она не ядра, а именно машины.

                                      > а что касается того, что chroot не виртуализирует devfs и proc, а должен был? LXC тоже не виртуализирует, например, таблицы iptables, просто chroot такой вот примитивный контейнер.
                                      chroot (без всяких патчей, само собой — одна пачка таких патчей ныне называется openvz, а другая — lxc) — не виртуализирует вообще ничего. LXC же виртуализирует что-то (и iptables, кстати). В частности, lxc не виртуализирует сторадж никоим образом (это отдаётся на откуп dom0 — чаще всего это lvm тома), зато сеть — вполне. К тому же, адреса памяти всё же отличаются, нельзя просто взять и сходить в чужую =) В chroot — вполне.
                                      • +1
                                        chroot виртуализирует пути в файловой системе :)

                                        как lxc и ovz имеют init с правильным ppid, и / в котором есть и /bin и /var, так и в chroot есть /bin (но ppid, таблиц маршрутизации и подобного нет)
                                        • +1
                                          > chroot виртуализирует пути в файловой системе :)
                                          Гм. Не совсем. Он его подменяет для всех системных вызовов. Так что это филькина грамота, если внутри chroot'a вы root.
                                          Кстати, почитал умности (или неумности, уж слишком скользкая тема) всякие.
                                          Ключевое отличие здесь в том, что внутри chroot вы не сможете запустить целиком гостевую ОС (и перезапускать её целиком отдельно от dom0). Это механизм виртуализации процессов по корневому каталогу, а не механизм виртуализации ОС. Как следствие — гипервизором его считать нельзя.
                                          • +1
                                            Мне все же не нравится определение «гипервизор» в отношении OpenVZ/jails/Zones/etc, по тому, что и там тоже нельзя «запустить гостевую ОС целиком». В OVZ контейнере /boot например чисто декоративный… Какая это «запущенная целиком» гостевая ОС?

                                            Не вижу разницы с chroot: в нем, зато, как и в LXC, можно запустить один бинарник :)
                                            • 0
                                              > Какая это «запущенная целиком» гостевая ОС?
                                              Её можно включить целиком и выключить целиком. И есть сущность, которая этим занимается. Да и, кстати, исходя из определения ОС — загрузчик в ней как раз и не обязателен. Ядро обязательно — да. Но никто и не говорит, что ядро должно быть выделенным ^_^

                                              > Не вижу разницы с chroot: в нем, зато, как и в LXC, можно запустить один бинарник :)
                                              Но в LXC можно запустить целую ОС. А в chroot — нельзя. А ещё нельзя одним махом поубивать все процессы, запущенные в chroot (в виде демонов). Для этого нужно что-то написать. Вот когда появится сущность, которая будет сама следить за тем, что запустили в чрутах и уметь убивать всё это — можно будет говорить о зарождении гипервизора. Но уже есть LXC — он и есть гипервизор для chroot-ов.
                                  • 0
                                    >Там главные проблемы вокруг /proc сейчас.

                                    кстати, /proc нынче в lxc тоже изолирован. даже всякие conntrack hashsize )))
                                • +1
                                  >Кстати, как там с виртуализацией сетевого стека в LXC?

                                  там как раз всё хорошо. я даже статью писал на эту тему.

                                  что вы хотели сказать фразой «всё кисло»?
                                  вот сейчас ipset не умеет жить в неймспейсах и его к этому приучают.
                                  iptables уже достаточно давно умеет.
                                  в ethtool добавили флажок netns-local, показывающий можно ли интерфейс отдать в неймспейс(например, чтобы так не сделали с lo).
                                  в iw есть уже достаточно давно phy set netns, позволяющий закинуть беспроводной интерфейс внутрь контейнера.

                                  через ip netns exec можно запустить pppd(можно разные ppp терминировать в контейнере).

                                  а теперь вопрос. вот у вас есть ядро с openvz и вы хотите туда ipset.
                                  сколько боли и страданий доставит процесс добавления?
                                  • –1
                                    а теперь вопрос. вот у вас есть ядро с openvz и вы хотите туда ipset.
                                    сколько боли и страданий доставит процесс добавления?


                                    Зато там работает ядерный NFS, OpenVPN, и ipsec :)
                                    • 0
                                      >Зато там работает ядерный NFS, OpenVPN, и ipsec :)

                                      это тут причём?

                                      а про ipsec я тоже могу рассказать, да.
                            • 0
                              >Кстати, в LXC нет аналога не только vzswap

                              во-первых 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. в ядре уже почти всё для этого есть.

                            • 0
                              >Кстати, в LXC нет аналога не только vzswap

                              во-первых 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. в ядре уже почти всё для этого есть.
                              • 0
                                criu проект команды OpenVZ/Virtuozzo, впрочем Вы это наверняка знаете.
                                Они все делают правильно: уменьшают размер патча на ядро, что бы пропал главный аргумент против OpenVZ, что используется патченный кёрнель.
                                • +1
                                  вы так говорите, словно есть какая-то конфронтация с openvz.
                                  по факту, openvz в rhel6 использует ту же инфраструктуру ядра, что и lxc.
                                  более того, k001 писал про vzctl, который ограниченно поддерживает ядра 3.х и не требует патчей.
                                  • 0
                                    вы так говорите, словно есть какая-то конфронтация с openvz.


                                    в OpenVZ вике даже есть статья такая:

                                    wiki.openvz.org/Vzctl_for_upstream_kernel

                                    Конфронтация есть разве что в головах администраторов. Я пыталась донести мысль, которую разделяют и разработчики, что OVZ более законченное решение.

                                    А вообще топик не об этом же. Он о том, что гипервизоры рулят на дорогом оборудовании, а дешевые Xen-хостеры очень много лукавят (особенно, про «честность» Xen и оверселлинг OVZ), ну и о том, что OVZ заслуживает лучшего имиджа, чем у него сложился на хабра-хабре!
                                    • +1
                                      >Он о том, что гипервизоры рулят на дорогом оборудовании

                                      все эти технологии рулят на хорошем железе.
                                      просто у вас вместо взвешенной аналитики получилась весьма сумбурная статья с весьма странной аргументацией.

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

                                      вот смотрите:

                                      я никогда не возьму xen для задач с более-менее серьезным i/o (и pv-драйвера тут не спасают). т.е. раздача статического контента из виртуалки — это утопия.

                                      при этом, я бы взял xen/kvm если мне нужно внутрь гостя закинуть какое-то pci-устройство(допустим, у нас какое-то важное legacy-устройство с драйверами только под rhel3).

                                      В конце-концов, openvz можно запустать внутри виртуалки под xen/kvm :))))

                                      • 0
                                        В конце-концов, openvz можно запустать внутри виртуалки под xen/kvm :))))


                                        Ага, мы с еще одним человеком собираемся так сделать с виртуалкой Xen с Linode для одного некоммерческого фонда
              • 0
                >но мне больше нравится ядро RHEL6 на сервере.

                оууу… следите за руками:

                1) сначала их просят в багзилле: пацаны, смотрите какую клёвую штуку придумал Tom Herbert
                2) потом выходит апдейт с бэкпортом rps в el6.
                3) а потом выясняется, что портировали криво, а фикс тривиален

                так что рассказывать про регрессии не надо )))
                longterm-ядра не уступают в стабильности ядрам из el6.
                • 0
                  Другие примеры, уже про регрессии long ядер, наверняка есть. Phoronix вот постоянно публикует, и в чем-то новые ядра всегда чуть тормознее, чем более старые (а в чем-то быстрее).
                  У RHEL, имхо, более гладко с этим!

                  А еще, не забывайте, что железячным вендорам серверного оборудования иногда тяжело поддерживать драйвер в main line, проще один раз в несколько лет написать под RHEL.
                  • 0
                    >Другие примеры, уже про регрессии long ядер, наверняка есть.

                    вот понимаете, разница между тем что написали вы и я — наличие конкретики.

                    >Phoronix вот постоянно публикует, и в чем-то новые ядра всегда чуть тормознее, чем более старые (а в чем-то быстрее).

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

                    моё железо(dvb-карточки) не поддерживается в rhel6, но поддерживается и прекрасно работает в 3.4-longterm за исключением одной модели(драйвер ddbridge). бэкпортировать это в 3.4 было совсем несложно.

                    вообщем, сам процесс разработки слабо отличается у longterm и rhel-ядер.
                    т.е. сначала release, а потом: fix,fix,fix…

                    только число тестеров для longterm-ядер больше(а не только сотрудники redhat)

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

                    упомянутый мной e1000e есть в мейнлайне. только разного уровня свежести.
            • 0
              >LVM том вы тоже не сможете оверселлить. Это не промышленная SAN с дедубликацией и даже не ZFS.

              lvm может быть организован на lun, полученном по iscsi со стораджа с zfs. так что я бы не был столь категоричен.

              >LVM том Вы сможете сделать для VPS клиента меньше только при смене клиентом тарифного плана, и продать то место, что не не использует, не выйдет.

              thin provisioning в lvm есть.

              >Ладно, если у Вас SATA диски, а если сверхдорогие SSD? Или дороговатые SAS?

              если даже в рамках локальных дисков, то есть bcache.
            • 0
              >LVM том вы тоже не сможете оверселлить. Это не промышленная SAN с дедубликацией и даже не ZFS.

              lvm может быть организован на lun, полученном по iscsi со стораджа с zfs. так что я бы не был столь категоричен.

              >LVM том Вы сможете сделать для VPS клиента меньше только при смене клиентом тарифного плана, и продать то место, что не не использует, не выйдет.

              thin provisioning в lvm есть.

              >Ладно, если у Вас SATA диски, а если сверхдорогие SSD? Или дороговатые SAS?

              если даже в рамках локальных дисков, то есть bcache.
          • 0
            >LVM том вы тоже не сможете оверселлить. Это не промышленная SAN с дедубликацией и даже не ZFS.

            lvm может быть организован на lun, полученном по iscsi со стораджа с zfs. так что я бы не был столь категоричен.

            >LVM том Вы сможете сделать для VPS клиента меньше только при смене клиентом тарифного плана, и продать то место, что не не использует, не выйдет.

            thin provisioning в lvm есть.

            >Ладно, если у Вас SATA диски, а если сверхдорогие SSD? Или дороговатые SAS?

            если даже в рамках локальных дисков, то есть bcache.
            • 0
              Боюсь Вас обидеть, но зачем копипастить одно и то же сообщение несколько раз для ответа на разные сообщения?
              • 0
                это какой-то глюк =( мне хабр выплюнул «ошибка в ajax-запросе», попробуйте ещё раз.
                кто ж знал, что он всё-таки добавил комментарий.
  • +2
    Еще чаще возникает необходимость балансировки нагрузки: на одной ноде VPS продали слишком много, а на другой слишком мало. дешевые Xen хостеры вынуждены или выключать часть клиентов, и перевозить их offline на недогруженный сервер, или не обращать внимание на жалобы клиентов на перегруженном сервере: авось кто-то уйдет, и тормозить у остальных VPS перестанут!
    Про Live Migration на Xen и KVM автор не знает? Между тем очень просто всё настраивается даже на арендованном хецнеровском железе.
    • 0
      Вот и я о том же. :)
      Автор не работал с этим, и не может себе представить насколько это удобно по сравнению с openvz.
      • 0
        Что удобнее? DRBD что ли? А Если у Вас есть SAN, то это совсем другая ценовая категория VPS!
        • 0
          с каких пор ещё один сервер с пачкой дисков, zfs и iscsi-таргетом — это сразу другая ценовая категория?
          • 0
            3-4U x86 сервер под сторадж это категорически другая ценовая категория. Он стоит как несколько 1U нод, на которых можно запускать OpenVZ, и в которых уже есть слоты для дисков.
            Которая приближается по цене к самым дешевым «мелкобрендовым» полочкам с дисками.

            Мы с 4U машинами на моей текущей работе с ZFS уже намучались под почтовые стораджи :(
            Насколько лучше работает старый-старый нетап, Вы себе представить не можете!

            Кстати, если расскажите, как победить на ZFS тормоза при заполнении, я буду Вам очень благодарна! Если использовать заполненную процентов на 70-80, или даже наполовину, что бы i/o не проседало, гигабайт получается слишком дорогим, и сравнимым по стоимости с мелкобрендовыми «хранилками»
            • 0
              >3-4U x86 сервер под сторадж это категорически другая ценовая категория. Он стоит как несколько 1U нод, на которых можно запускать OpenVZ, и в которых уже есть слоты для дисков.

              нормальный 1U стоит ~ 2500$. дисковая полка на 36 дисков — где-то столько же (не сочтите за рекламу, первое что в гугле нашлось).

              при этом там 2 блока питания и нормальное охлаждение. другое дело, что это за собой потянет карточки на 10GE и наличие свитча хотя бы с двумя портами на 10GE.

              >Кстати, если расскажите, как победить на ZFS тормоза при заполнении

              читали?
              ну и паттерн использования, условия и проч-проч. это ж не лечение по фотографии.
              да и лучше вам этот вопрос задать отдельно в Q&A.
              • 0
                нормальный 1U стоит ~ 2500$. дисковая полка на 36 дисков


                Так это полка, а не сервер. Полки (DAS) мне самой нравятся, на них классно бюджетные кластеры городить без всяких iscsi и тем более FC.

                читали?


                Да. Не помогает :( Ладно, Вы правы, это отдельный вопрос.
                • 0
                  >Так это полка, а не сервер. Полки (DAS) мне самой нравятся, на них классно бюджетные кластеры городить без всяких iscsi и тем более FC.

                  ну так берёте полку, сервер с контроллером и вперед. в чём проблема?
                  а зачем вам FC? такие фантастические требования к латентности дисков?
                  если так, можно взять FCoE, дешевле будет.

                  • 0
                    затем, что zfs тормозит :(

                    Полочка хороша подключить ее к двум серверам, сделать поверх нее кластерный сlvm и гонять между ними виртуалки на KVM или xen. А вот под хранилище уже не очень.
                    Даже древний-древний нетап, отдающий директории с миллионами файлов (Maildir) просто несравненно быстрее, чем ZFS. ZFS еще хоть как-то справляется, пока занято половина объема, как приближается к 90%, начинается коллапс :(

                    Мы на допотопный нетап сложили самые страшные Maildir'ы
                    • 0
                      zfs — это инструмент.

                      наличие у человека дома фортепиано не делает его виртуозом, как и наличие спортивного болида в гараже не делает гонщиком.

                      у некоторых людей используется хитрый бутерброд из 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.
                      • 0
                        пробовали zil, быстрее когда незаполненно, но когда незаполненно, i/o почти устраивает. Когда заполненно, и с zil тоже тормозит :(
                        Поэтому убрали SSD диски.

                        Может память правда добавить?
                        • 0
                          что именно с zil вы делали?
    • +1
      Для Live Migration на Xen Вам нужно общее блочное устройство. Если им будет drbd, то у Вас будет или просадка производительности, или асинхронная синхронизация между нодами, которая чревата потерями данных при hard reset.

      Для KVM уже есть Live Migration без СХД :) Но в продакшен ее пока не видно: в RHEL6 ее еще нет, есть в Fedora (насчет Debian и Ubuntu LTS не знаю)
      • +1
        Распределённое хранилище — скорее благо, чем зло, серьёзно поднимает отказоустойчивость. Учитывая, что трафик внутри дц бесплатен, проблемы не вижу.
        • 0
          Распределенное хранилище это благо :) Особенно если это какой-то Xyratex бюджетный хотя бы…
          А вот насчет drbd это уже очень спорно, особенно для хостинга. Вы отдаете себе отчет, что при асинхронной репликации у Вас может быть потеря данных? Если Вы кластеризируете собственный сервис (то есть вы администратор сервиса!) вы, скажем, будете использовать в MySQL innodb, а если Вы не админите гостевую систему, и там у клиента MyISAM?
          • 0
            А что мешает хранилище организовать на GlusterFS какой-нибудь? Данные терять не должно, единственное, малость производительность всё же просядет.
            • +2
              Вот-вот. А на 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 и более быстрой дисковой подсистемы
              • 0
                Все же в OpenVZ не полноценный Live Migration, там просто холодная и горячая виртуализация.
                При чем вовремя горячей синхронизации виртуалка ставится на паузу пока rsync засинхронизируется.
                А на большом количестве файлов это может занимать минуты.
                А ведь еще ОЗУ надо перекинуть, что тоже время.
                Можно с таким же успехом мигрировать XEN виртуалки в несколько проходов.
                Никакого отличия.
                • 0
                  холодная и горячая виртуализация = холодная и горячая синхронизация
                • +1
                  Вы можете написать свой скрипт, и добавить еще один rsync (я именно так и сделала)

                  Решение для Xen-а в студию, пожалуйста: то-то их все возили оффлайн до недавнего времени.
                  • +1
                    Для чего делать еще один rsync?
                    Чтобы еще замедлить миграцию?
                    Остановка на время сравнение rsync-ом никуда не денется.
                    Для XEN:
                    mount -o ro…
                    rsync
                    rsync
                    save
                    scp
                    restore

                    В общем тоже что на OVZ, только плюс mount.
                    • +1
                      Для чего делать еще один rsync?


                      Для того, что бы уменьшить даунтайм. C тремя rsync-ами (последний перед чекпоинтингом), если файлов не миллионы, даунтайм меньше.

                      Интересное у Вас решение, поставила Вам плюс. Почему его никто не использует? Вот Microsoft у себя сделала подобную миграцию для Hyper-V, может быть, есть какие-то подводные камни?

                      • 0
                        тьфу ты, не последний перед чекпоитингом, а один лишний перед ним.
                        Понятно, что после чекпоитинга, перед стартом дампа памяти на новой ноде нужно сделать еще один rsync.
                  • 0
                    Какой скрипт, какой rsync, какое решение? Right-click, выбрали пул/сервер, выбрали SR, ушли пить кофе. Или тоже самое, но через xapi. У юзера максимум один пинг теряется — даже сессии не рвутся.
      • +3
        XCP 1.6 есть миграция без общего стораджа и уже в продакшене.
        • +2
          Если уже в продакте, расскажите. У нас последние пусконаладочные работы ведутся.
  • +4
    Чушь вы написали. Любой, кто копался поглубже с любой из систем виртуализации — засмеет вас. Особенно про «оффлайн» миграцию.

    А с openvz есть куча очевидных проблем. Главная из них — openvz у всех старый (обновлять dom0-ноды действительно муторно). Про Vswap (всё же не VZswap) не все слыхали, а уж используют так вообще единицы. «Ванильное „ядро от openvz не поддерживает новые процессоры/сетевые карты/etc. Ну то есть оно подтягивается со временем, но обычно нельзя просто купить последнюю железку и запустить на ней ovz. Либо ядрышко руками собирать. С ipv6 там ппц, и проще его не использовать. Ну и так далее.
    • +2
      Но при том, если знать, как использовать ovz и правильно её готовить — то да, в некоторых местах оно и лучше.

      От цены тут ничего не зависит. Всегда всё зависит от умений того, кто настраивал dom0-ноду. Кто-то сделает из KVM реактивный пулемет, кто-то из vbox, а кто-то даже ovz тюнить не умеет.
    • –2
      Про Live Migration без полочки с дисками на Xen см. ветку выше.

      А про драйвера, RHEL6 ядра, на которых базируется свежий OpenVZ, поддерживают все серверное железо.
      Более того, все производители серверов (не PC машин, которые выдают за серверы в некоторых датацентрах, а именно серверов!) обязательно выпускают драйверы под RHEL6 и обычно RHEL5 ядра.
      Под ванильные ядра линукса, с номерами 3.*, очень часто не выпускают, так что ситуация обратная той, что Вы написали.
      Свежая вебкамера или новый принтер может быть действительно не будут работать под RHEL6 based OpenVZ ядром, но зачем это для хостинга??

      Вы уверены, что Ваш ответ, в свою очередь не чушь? Прочитайте комментарии. Я понимаю, что топик провокационный, и на хабрахабре сложилось определенное мнение об OpenVZ: в этом и был смысл и его новизна: если не переубедить, то уговорить задуматься: а так ли все, как тут считает большинство?
      • +1
        > А про драйвера, RHEL6 ядра, на которых базируется свежий OpenVZ, поддерживают все серверное железо.
        Ага. То-то у меня машинки на SB без сети наливались долгое время =)
        И ещё там очень забавно работал Turbo Boost. Некоторые назвали бы это «не работал».

        > Более того, все производители серверов (не PC машин, которые выдают за серверы в некоторых датацентрах, а именно серверов!) обязательно выпускают драйверы под RHEL6 и обычно RHEL5 ядра.
        Вот только пока openvz-шники эти патчи вкрутят в своё ядро — железо перестаёт быть актуальным и в закупках участвует уже более новое.

        > на хабрахабре сложилось определенное мнение об OpenVZ
        У меня до сих пор больше сотни dom0 машин с openvz. На мнение хабрахабра в данном вопросе мне наплевать, честно =)

        Нет, я не говорю что openvz плохой. Я говорю о том, что его нужно уметь готовить (и потратить на его изучение больше времени, чем на любой другой гипервизор, кроме разве что lxc). В нём неимоверно много глюков, проблем и отставаний от общего технического прогресса.
        Если у вас говно мамонта ставят вместо серверов — пжалста, у вас проблем не будет. Если вы не собираетесь воевать с ipv6 — аналогично. Если у вас не процессоры серии 55хх (слава богу, они ушли) и не raid10 — вы тоже будете жить спокойно. И таких если наберется десятка два.
        • +1
          Ага. То-то у меня машинки на SB без сети наливались долгое время =)
          И ещё там очень забавно работал Turbo Boost. Некоторые назвали бы это «не работал».


          А можно номер бага в багзилле OVZ? И воспроизводилась ли проблема на RHEL6 ядре? Какой именно у Вас был сервер? Давайте почитаем комментарии разработчиков…
          • 0
            Про проблемы с Xeon 55xx я слышала, и даже с ними сталкивалась(мы дропнули закупку нод с этими CPU, и купили их, когда они существенно просели в цене). На мой взгляд, их пофиксили очень быстро, еще до того, как цена на эту линейку опустилась с маркетингово-запредельной как на новинку.
            Предлагаю вспомнить о том, что смешные баги бывают и в Xen, и тем более в KVM. Вообще сложного софта без багов не бывает, мне кажется, Вы утрируете.
            • 0
              Проблему с отстреливанием 3х дисков из raid10 в 55хх вне rhel с ovz так и не починили ;)
              • 0
                Ну могу сейчас найти тот самый баг, но на сколько я помню, его как раз уже закрыли.

                Кстати, поделитесь, а Вы что, на LXC продаете клиентам VPS-ки??
                • –1
                  Продаю я их на 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.
                  • –1
                    Может быть, я делаю что-то не так?

                    [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
                    • 0
                      > Может быть, я делаю что-то не так?
                      Вас не ддосят и veth не делает oops)?

                      > Что LXC в обозримом будущем будет готов для хостинга я, извините, не верю :(
                      Его готовность для хостинга на текущий момент описывается словом «никогда». Это _очень_ быстрое решение для виртуализации в _своей_ инфраструктуре. Очень хорошо интегрированное в систему, не использующее каких-либо древних костылей. Со всеми вытекающими. Если чужим людям нужны руты на ваших виртуалках, но не нужны на соседних с ними — lxc вам не подойдет, однозначно. Если пользователям виртуалок нужен контроль ресурсов потребляемых конкретной виртуалкой (и не через cgroup, как это смотрю я, а через top/htop/etc) — то вам тоже мимо.

                      > Оно до сих пор умеет не больше, чем Linux VServer 2005-го года, который давно проиграл войну OpenVZ
                      Вот только количество накладных ресурсов на lxc поражает воображение ;) В отличие от того же vserver, да. Вы не теряете ни в дисках, ни в процессоре, ни в памяти, ни в IO. Если использовать macvlan — то и гигабит мелких пакетов по сети можно спокойно «прокачать». Теряете вы только на контекст-свичах, но не больше, чем если бы вы всё то же самое запустили в одной bare-metall.
                      • +1
                        veth не делает oops)?


                        Зачем veth на хостинговом сервере?? also, Когда мы занимались аутсорингом офисных клиентов, не было и проблем с veth, который прокачивал через себя трафик с гигабитного линка для Samba-контейнера. Какие были сетевые карточки я не помню, к сожалению, но материнская плата была самая что ни на есть десктопно PC-юковая.

                        Я сперва думала, что придется отказаться от маков для контейнера с Samba, и гонять файловый трафик через venet, но все получилось.

                        Если использовать macvlan — то и гигабит мелких пакетов по сети можно спокойно «прокачать».


                        Вы же в курсе про Venet, да?
                        • 0
                          Ы. Почитал ваш пост, задумался.

                          [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 спасет =)
                          • +1
                            Мне кажется, что-то с железом :(
                            Как раз venet всегда работает идеально, так как это локальная петля по сути…
                            А veth работает с небольшим оверхедом.
                          • 0
                            К слову про бриджи и veth: я как раз сейчас колупаюсь с поднятием dhclient внутри ovz-контейнера, и третий день не могу побороть дропание dhcp reply в бридже. Все другие типы пакетов (от arp до http) ходят, а эти ни в какую. Что это может быть?
                            • 0
                              а tcpdump -i БРИДЖ на ноде и в контейнере что говорит?
                              • 0
                                то есть в контейнере конечно tcpdump -i eth0
                              • 0
                                В бридж пакеты приходят, из бриджа не выходят. Внутри контейнера картина такая же, как на хостовой ноде tcpdump -i vethNN: только request'ы.
                                • 0
                                  iptables, конечно, сброшен?
                                  А попробуйте создать пустой дефольтный контейнер (лучше другой дистрибутив, чем у вас сейчас), и повторить опыт с ним.
                                  • 0
                                    iptables -F сделано, с форвардингом чего только не делал, /proc/sys/net/bridge/bridge-nf-* в самых разных комбинациях испробовано. Контейнер как раз пустой дефолтный (единственный на этой машине), только что пересоздал для чистоты эксперимента. Снаружи шапка 6, внутри 5.9
                                    • 0
                                      Сделайте контейнер с убунтой. Еще… попробуйте поставить старое ядро(существенно старее вашего), и попробовать воспроизвести проблему с ним. Если не воспроизводится, это баг, с ним в buzilla.openvz.org.
                                      • 0
                                        В общем, победил. Первое и основное: openvz странно работает с виртуальной e1000 (ESX), нужно менять тип сетевухи на vmx3; второе — brctl setfd 0 $bridge_name; третье — броадкаст mac на vzeth$number, iptables -A FORWARD -j ACCEPT, 1 в bridge_nf_iptables;
                  • +1
                    >В 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.
                    ну и поддержка неймспейсов объектами ядра.
          • 0
            Нет, конечно. Зачем мне было грызть кактус? Все новые машины с тех пор у меня под lxc, благо условия позволяют.
      • +2
        Вам выше неоднократно сказали — если не разбираетесь в Xen и в технологиях виртуализации отличных от виртуозы, то лучше промолчать, а не говорить, тем более так безапелляционно. Xen уже давно умеет live storage и live pool migration. То есть полочка не нужна. Виртуоза это умеет? Несколько лет назад когда я ее ковырял точно не умела.
        А по поводу виртуозы. Обычно я большинству знакомых рекомендую, если они видят на сайте хостера это слово, сразу сайт закрывать и искать дальше. Свои модули в ядро — умоляем хостера, свою версию ядра — не, облом. 20 инстансов апача и память кончилась, но ведь влезало даже на rpi при тестах. А, ну да, виртуоза память иначе считает и надо тюнить все. Да ну ее в пень такую «виртуализацию». Хотя под некоторые проекты — каюсь, грешен, рекомендовал ее :)
        • +2
          поправьте если ошибаюсь, но XenMotion разве не только для платного Citrix? А в бесплатном, GPL OpenVZ, живая миграция между стораджами(в качестве которых обычно выступают локальные диски сервера) была всегда, то есть, с серидины 2000-х годов.
          • +1
            Значит я тогда не разобрался как ее готовить, ибо не смог завести.
            Не путайте XenMotion и Storage XenMtion. Первый был всегда и в любой версии. Второй появился в XCP 1.6 и XenServer 6.1. На счет бесплатного сервера не скажу — у меня из XenServer'ов только на адванседе один из пулов, а халявного уже нет. Но в остальных пулах, которые крутятся на GPL'ном XCP, из коробки прекрасно пашет Storage XM.
            • +1
              Что Вы ключи vzmigrate посмотрели невнимательно, я не верю, Вы вроде бы профи :)

              Скорее всего, у Вас были между нодами ли CPU разных поколений (в KVM кстати круто, что он умеет Live Migration между Xeon и Opteron, в OpenVZ и Virtuozzo, к сожалению, совместимость меньше), или был не загужен какой-то модуль вроде vzcpt, или был разный список ядерных модулей на нодах (для VPS-ки был, скажем, прописан модуль iptables, которого не было на destenation ноде)
              Эти все ситуации есть в kb параллельса, ну или саппорт на такие вопросы тоже отвечает (хоть они и простые)
              • 0
                Скорее всего не доковырял. На тот момент решали делать ли два пула под винды и линукса или один общий. В результате сделали один общий и пока ни разу не пожалели.
                Я сходу с этой виртуозой пару багов словил, решения не нашел и забил. Плюс с товарищем пообщался, который хостера с виртуозой админил — много мата выслушал по поводу багов и скорости их починки, и качества саппорта. Сейчас может там все и шоколадно, но нужно было тогда.
                Сейчас несколько пулов на xen, несколько контейнеров lxc, несколько jail на фряхе. Так что по openvz/virtuozzo я точно не профи.
            • +1
              Значит я тогда не разобрался как ее готовить, ибо не смог завести.

              Не смогли запустить команду vzmigrate --online? Смешно.
              • 0
                А не мигрировали :( Сейчас уже не вспомню почему.
              • 0
                Стоит заметить, что vzmigrate --online вовсе не живая миграция. Если у контейнера скажем 5-10-100 гб оперативной памяти, то время даунтайма при vzmigrate --online будет аховским (будет ровняться времени саспенда — довольно серьезному — и последующей передачи дампа по сети).
          • 0
            Бесплатно в XCP 1.6
            • 0
              Тогда правомерно говорить, что live migration нет в части решений под Xen.
              Cloud Platform же, наверное, не всем подойдет?
              • 0
                Всем подойдет. В xcp и есть xen.
                • +1
                  Во всех дистрибутивах?
                  • 0
                    Xapi накручиваетя на большинство дистров, на которые можно установить Xen, а дальше рулится из XenCenter, а для пуристов — из под GPL-софта, которого навалом разных видов.
                    • +1
                      Это уже кто-то использует в production из Xen хостеров?
                      • 0
                        Никогда не интересовался этим вопросом. Но раз в wiki xcp этот вопрос разжевали очень подробно, то вещь популярная. Там много чего не освещено, а этот топик разжевали.
                        Тот же амазон врядли живет под чистым xen, но и врядли на XenServer/XCP. Скорее всего xen+libvirt или xapi. В свое время я подробностей не нашел.
                    • 0
                      Чисто для понимания, это возможность теоретическая. xapi в дебиане — это снапшот из гита, который с продакту никакого отношения не имеет, а вкрутить в живую ОСЬ xapi просто так не выйдет — много нюансов.
                      • 0
                        Спасибо за инфу!
                        Сам не пробовал. Судил по подробным докам в wiki. Думал оно уже достаточно стабильно.
                  • 0
                    XCP, это уже готовая платформа, которую можно использовать. Из коробки, уже много готового, если рассматривать фаш случай, вам хватит. Если смотреть на более крпуные инсталяции и предоставление этого как услуги, необходимо дорабатывать по несколким направлениям.
              • +1
                XCP=XenServer минус чуток проприетарщины и под GPL.
        • –1
          Да все она правильно говорит.
          Виртуоза — платный продукт. Openvz — нет. Вы про какой? А есть еще гибридные решения, proxmox, например, он позволяет из одной вебморды управлять и KVM, и Openvz. В такой среде работает online миграция при соблюдении некоторых условий и с небольшими допущениями. Топик не про это, но у нас даунтайм kvm виртуалки под нагрузкой чуть меньше 5ms при живой миграции. И это без всяких СХД и дорогущих ентерпрайз. Сейчас openvz запилят свой ploop, и его можно будет мигрировать также. Плюс ploop решает вопросы с затупами kjournald на хост машине.

          Пресловутые «модули в ядро» никому не нужны. Память считается? Нормально считается, это некоторые нечистые на руку оверселлеры делают антирекламу своим маркетинговым булщитом. Что там тюнить? Три параметра в конфиге уже давно.
          Ну и апачи на дешевые впски-вдски не советую, лучше что-нибудь посовременнее.

          Опенвз не нравится тем, что совсем под нагрузкой процессы внутри залипают. Порт открыт, процесс висит, но ничего не делает и ни на что не отвечает. Ну, просто под такой нагрузкой у нас вообще остальные никакие виртуалки не живут. С Java есть некоторые сложности. Нет возможности контролировать диск IO. Да это все мелочи по сравнению с плюсами.

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

          У нас все проекты внешние на openvz. Это несколько петабайт трафика, несколько десятков миллионов уников в месяц и до 6000 рпс на некоторые узлы системы.

          Я вот XEN людям не советую. Тормозной и крашится под нагрузкой. Rackspace же его использует? Ну-ну.
      • 0
        >А про драйвера, RHEL6 ядра, на которых базируется свежий OpenVZ, поддерживают все серверное железо.

        хехе. вот только интеловские e1000e плюются netdev watchdog timeout )))
        а фикс — на sourceforge.net(где можно стянуть интеловские драйвера) либо вообще git.
        могу ещё напомнить про silent panic в 2.6.9(да, это rhel4) на определённых чипах интеловских карточек при включенном tso.
        • 0
          2.6.32 уже давно.
          Вы, наверное, говорите про те времена, когда ядро было дебиановское? Очень давно такое встречал, но вроде это было в 2.6.18, оно было debian-based.
          RedHat делает славные ядра. Не нравится, что они все повыпилили правда, кроме своих редхатовских штук. В продакшне с этим проблема.
          • 0
            >2.6.32 уже давно.

            я как бы в курсе. про 2.6.9 упоминалось лишь как пример «стабильности» rhel-ядер.

            >Вы, наверное, говорите про те времена, когда ядро было дебиановское?

            вы о чём? openvz можно рассматривать серьёзно только в контексте rhel-ядер(в том числе полученных патчами на ванильные 2.6.18 и 2.6.32).

            то что вы не встречали netdev watchdog timeout — очень и очень странно.
            • 0
              <= 2.6.18stab это были дебиановские ядра. Сами разработчики openvz считают ядро rhel стабильным, нет оснований им не верить.

              2.6.9 — это 2004 год? Как бы очень и очень давно. Я думаю, что в сравнении с другими продуктами 2004 года эта штука будет достаточно «стабильной».
  • 0
    Все правильно сказано между прочим, мало того что продают на несерверном железе так еще и готовят на нем OVZ так что не знают сколько чего оно тянет и оверселят в итоге втыщу раз. И кстати про хецнер, я никогда не забуду продажу i7 серверов с старым ядром где куча фишечек просто недоступно было в системе, а все так бросались за новым мощным CPU за нищенские деньги что плевать хотели на полноценный сервер, а их диски и рейд контроллеры до сих пор заставляют нервно улыбаться.
  • 0
    Практика использования XEN/KVM/OpenVZ/Jail у крупных провайдеров, показывает что в OpenVZ/Jail соседи по серверу могут больше друг другу мешать. Ддос либо использование тяжелых неоптимизированных приложений может положить к чертям весь сервер. В KVM изоляция намного лучше. Теперь если клиент использует что-то адово тормозное, предлагаем ему переехать на KVM и о чудо, проблемы пропадают.
    • +1
      Насчет Jail соглашусь, а вот насчет OpenVZ vs Xen/KVM, при прочих равных (локальные диски, и swap в каждой виртуалке на HDD!) уже нет.
      • 0
        Попробуйте кучу виртуалок с minecraft'ом запустить на OpenVZ и KVM. Быстро почувствуете разницу. На OpenVZ будет весь сервак тормозить, на KVM все будет ok.
        • 0
          Запускала кучу гостевых систем, но не с minecraft'ом, а с разными приложениями. Все с точностью до наоборот: на OpenVZ прекрасно работает до 50, даже 100 нагруженных контейнеров.
          На KVM обычно столько (при прочих равных) просто не помещается.
  • 0
    .
    • 0
      Как интересно скачет рейтинг топика: сперва было больше десяти, а вот сейчас, сейчас он уйдет в минуса :)

      Пожалуй, попытка реабилитации OpenVZ в глазах сообщества Хабра-Хабра провалилась :(
      Один человек никогда не нивелирует многолетные труды пиар команд нескольких Xen-хостеров.
      Сорри за такую конспирологическую теорию, но я в нее верю, а вот в жидомассонский заговор нет!
      • +3
        Вся аргументация против OpenVZ состоит из «нельзя пересобрать ядро и загрузить свой модуль iptables» :)
        • 0
          Основная аргументация — для админа сервер в контейнере это как резиновая женщина. На первый. згляд вроде такая же как настоящая, но дьявол как всегда кроется в деталях :)
          На самом деле в статье и в комментах постоянно смешивают услуги хостинга и севисы предприятия, т.е. enterprise, а это несколько разные вещи с несколько разными задачами и требованиями.
        • 0
          Да что Вы говорите, почитайте комменты, аргументов приведено выше крыши…
          • 0
            Например?
  • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      Даже не интересуюсь, на какой платформе у Вас VPS, по тому, что для Xen/KVM есть только dm-ioband для жестких лимитов по i/o, который почти никто не использует по многим причинам (прежде всего, он не мантайнится).
      То есть, за, например, таренье архивов с миллионами файлов Вас могут даже выключить на любом хостинге, где не используется быстрая полочка с дисками, или SSD.
      • НЛО прилетело и опубликовало эту надпись здесь
        • 0
          DDoS-или кого-то :(
      • 0
        >для Xen/KVM есть только dm-ioband для жестких лимитов по i/o,
        cgroups+blkio-лимиты?
        • 0
          Рада, что такая фича появилась :) И что теперь dm-ioband не нужен (пришлось его юзать на пятой шапке, где cgroups не было)
          • 0
            Да, в 6 это уже работает на обычном ядре.
  • +3
    как предварительное резюме: по поводу бенчмарков HP о VPS Xen vs VPS OpenVZ возражений не было, не было и возражений по поводу vzswap. Прицепились к слабым местам в тезисах, озвучив новые фичи, вроде Storage XenMtion, которые не обязательно есть у всех Xen хостеров.

    Пока не видно, в чем дешевые Xen и KVM VPS-ки, без общего стораджа, лучше для конечного пользователя, чем OpenVZ VPS-ки. Особенно с учетом большей плотности OpenVZ VPS на ноде, а, значит, и меньшей стоимости ресурсов для конечного пользователя, или большей рентабельности хостинга, дополнительные деньги от которой low-cost хостер может потратить на качественный, умный саппорт.

    Удивительно, что никто не вспомнил старую песню о том, что Апач на OpenVZ ест меньше памяти, чем на Xen (подсказка: нужно тюнить стек, man ulimit)

  • 0
    что Апач на OpenVZ ест меньше памяти, чем на Xen (подсказка: нужно тюнить стек, man ulimit)


    То есть, наоборот больше
  • 0
    Как пользователю дешевых VDS мне, в принципе, всё равно какая технология виртуализации используется, лишь бы она мне не доставляла проблем. В администрировании я не силен и занимаюсь им, грубо говоря, вынужденно — из-за желания или заработать лишнюю копейку, или сэкономить её моим заказчикам (как правило малокомпетентым в области администрирования и разработки) для сохранения их лояльности ко мне. Но я с трудом представляю себе администрирование системы (практикую debian-based), где не все пакеты мне подконтрольны. С одной стороны, в нужных мне пакетах могут оказаться зависимости от нового ядра, а с другой — хостер может обновить ядро и оно окажется несовместимым с моим В свое время намучался по подобным причинам с обычным шаред-хостингом, то не обновиться, когда нужно, то насильно обновляют, когда не нужно, и потому скептически отношусь к технологиям на основе «клонирования ядра» и, тем более, если речь идет не только о ядре.
  • 0
    «VPS на Xen лучше, чем VPS на OpenVZ/Virtuozzo»

    XEN банально лучше тем, что у десятка хостинг провайдеров (работающих с Virtuozzo и OpenVZ) с которыми я имел дело, нельзя поставить ppp модуль ядра, потому что видите ли (по словам тех-поддержки) это сломает хост-систему. На Xen у меня такой проблемы не возникло.
    Для меня это например очень критично.
  • 0
    С одной стороны, в нужных мне пакетах могут оказаться зависимости от нового ядра, а с другой — хостер может обновить ядро и оно окажется несовместимым с моим


    В OpenVZ одно ядро, которое всегда совместимо само с собой :)

    А вот паравиртуальный домен Xen может теоретически сломаться при обновлении ядра dom0
    • 0
      Что само с собой оно совместимо, я понимаю. :) но что делать, если, утрируя, у PHP 5.5 появится зависимость от 3.9, а у хостера останется 3.8?
      • 0
        PHP не будет зависеть от ядра :))) Максимум, от glibc :)
        В VPS на любой технологии Вы можете себе поставить любую версию PHP. Точнее, иногда не можете из-за панели управления, установленной внутрь VPS, или на физический сервер. Но если поставить другую панель, или администрировать VPS(дедик) без панели, то можно «воткнуть» любую версию PHP
        • 0
          Слово «утрируя» вам ни о чем не говорит? :)
          • 0
            Ну… Вы ооочень сильно утрируете :)
  • 0
    Занятно, что автор статьи преподносит vSwap как плюс. Это костыль, который приводит к следующим проблемам:
    1) Учёт памяти страницами приводит к аварийному завершению процесса, который стал причиной выделения страницы, которая не может быть выделена. Например, все страницы забрали процессы apache, а oom-killer решил прибить mysql. Имеем битые базы.
    2) Вытеснение swap в память может иметь противоположный описанному результат. Операционная система — не дура, и откачивает редкоиспользуемые страницы, а вместо них загружает, например, дисковый кеш. Если своп от впсок будет висеть вместо дискового кеша, то общая производительность упадёт.
    3) Искуственное замедление доступа к памяти — полный бред. Много одновременных запросов -> превышение лимита на память -> ещё больше одновременных запросов -> падение.
    Мы от него используем только первую возможность, потому что она в некотором смысле повторяет поведение реальной операционной системы и все, кого это волнует, к этому привыкли.

    Кроме того, сейчас OpenVZ рекомендует переходить на ploop, что отменяет Ваши аргументы про миграцию (т.к. копирование блочного устройства будет идти одинаковое количество времени на всех гипервизорах, а, очевидно, именно это самое узкое место) и уплотнение ФС (которое приводит к очень злым проблемам при оверселлинге).

    В своё время OpenVZ действительно был нужен и полезен. Когда аппаратная виртуализация стала иметь сравнимые с текущими стабильность и оверхед, технология стала применима лишь в очень узком спектре вроде разещения на одном сервере 10000 виртуалок, каждая из которых обрабатывает по 3 запроса в день.
    • 0
      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
      • +2
        >чень категоричное заявление. Оверхед все еще большой, и, например, хоть многие и успешно запускают такие приложения как Asterisk и FreeSwitch в Xen доменах, VmWare виртуалках, на форумах айпи телефонии категорически не рекомендуют виртуализировать приложения для АйПи телефонии в чем-то, кроме OpenVZ или LXC

        как человек с инсталляцией ~ 300 астерисков в разных xen/kvm могу сказать: да, такие рекомендации есть. но связаны они в первую очередь с убегающим временем внутри виртуалки. в реальности я с этим столкнулся только 1 раз(и то, хост был наш собственный со старым ядром и xen'ом).

  • 0
    1. Начиная с XenServer 6 и XCP 1.6 поддерживается storage migration. То есть перенос возможен между пулами при наличии DAS с фактическим копированием файлов между полностью изолированными узлами. У себя в лаборатории я гонял виртуалки из одного федерального округа в другой, причём благодаря использованию 'base' части, повторные миграции будут весьма и весьма шустрыми.

    2. OpenVZ не имеет адекватных средств по изоляции виртуалок друг от друга. Пара примеров: mount list (позволяет сильно напрячь ядро из самого дешёвого контейнера), entropy drain.

    3. Оверселлинг никуда не девается.

    4. Я не видел ни одной инсталляции openvz, которая была бы способна пережить хотя бы 400kpps сетевого трафика.
    • 0
      >Я не видел ни одной инсталляции openvz, которая была бы способна пережить хотя бы 400kpps сетевого трафика.

      а в чём проблема? т.е. вот всё вышеперечисленное — это мне понятно. но пакетрейт…
      • 0
        Ну если ни в чём проблемы нет, то вы готовы для эксперимента выделить vds'ку?

        Если что, я говорю про brtools и/или роутинг.
        • 0
          #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, но тоже бридж.
          • 0
            Простите, какая из этих цифр — чило пакетов в секунду?
            • 0
              это выхлоп ifstat eth0

              • 0
                какая из этих цифр — число пакетов в секунду?
                • 0
                  #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
                  • 0
                    а irq какое на хосте в это время?
                    • 0
                      softirq? там core i7 3770 со включенным HT. равномерно по всем ядрам ~ 15-17%.
    • 0
      А какие инсталляции способны такой трафик пережить? Это уже проблемы приложения, если такой трафик есть, но борется с ним виртуалка и всего одна.
      • 0
        Любая vmware или hyper-v выживают при 400kpps. XenServer/XCP — требуют специальной обработки, но всё-таки могут пережить. OpenVZ (точнее, софтовый бридж из комплекта) не переживают.

        Заметим, в первую очередь речь идёт не о жизни конкретной виртуалки, а о том, что большой трафик в адрес одной виртуалки может полностью парализовать соседей. Заметим, не флуд в стиле «под потолок полосы», а просто большое число пакетов.

        Я одно время думал, что это только подлый DoS таким бывает, пока не наткнулся на реального клиента, у которого средний размер tcp-сессии был около 200 байт. В продакте. При не очень выдающихся байтовых показателях.
        • 0
          OpenVZ (точнее, софтовый бридж из комплекта) не переживают.


          Так может, venet нужно использовать? Его для этого и придумали же!
          Зачем вообще на хостинге мак адреса и veth?
          • 0
            venet куда вести будет? Я имею в виду, кто будет раскладывать пакеты по виртуалочкам после их прихода на физический интерфейс? И сможет ли он это делать со скоростью в несколько сотен kpps?
            • 0
              Как кто? Ядро :)
              Попробуйте провести сранивнительные тесты: вот даже разрабочики пишут в вике, что veth с мак-адресами это небольшой оверхед, а venet работает практически без него (особенно, если пакеты летают между контейнерами, не выходя и входя в физический интерфейс)
              • 0
                А антиспуфинг как накладывать?
                • 0
                  Он не нужен: из контейнера Вы не сможете поменять IP-адрес для venet интерфейса, разве что каким-то zero-day эсплойтом

                  IP из контейнера только для veth меняется.
                  • 0
                    И raw sockets для veth запрещены? То есть послать hping'ом с rand-source'ом ничего не получится?
                    • 0
                      в том-то и дело, что разрешено. veth предоставляет много возможностей, практически столько же, сколько физический интерфейс.

                      А с venet у Вас ничего не получится.

                      veth есть смысл использовать категорически не для хостинга, а при инсталляциях контейнеров в офисах: dhcpd, tftpd сервер, например, без veth работать не будут.

                      Но зачем Вам мак адреса для интернет-сервера? на хостинге не нужно ничего, кроме venet в контейнере!
            • 0
              вот вы вроде умный человек, а говорите странные вещи.
              на forum.nag.ru есть ветка оного товарища.

              intel C602 + 2x Xeon E2670 + 2x Intel-520
              36ГБит/с 4,3Мпакетов


              а теперь скажите, что мешает делать то же самое? в рамках одной машины?
              • 0
                Не знаю. На моей текущей работе делала кластер с двумя FreeBSD балансерами на pf, он даже не SMP, хотя трафик(почтовый) летит через него приличный.

                Перед этим делала балансеры на Linux LVS, там хоть и есть SMP, но трафик был на пару порядков меньше.

                В общем, я никогда не сталкивалась в качестве архитектора системы с тем трафиком, что по Вашей ссылке, только когда дежурной работала несколько лет назад, там такое видела на балансерах. Но видеть и быть архитектором системы это разное.
                • 0
                  >Перед этим делала балансеры на Linux LVS, там хоть и есть SMP, но трафик был на пару порядков меньше.

                  как-то так… на ipvs
        • 0
          Так это может бриджа все же проблемы? У опенвз много неприятных моментов под сильной нагрузкой, но с сетью проблем не видел еще ))

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

          Я вообще не заморачиваюсь пакетами в секунду, есть у нас сетевики, это их проблема по большему счету.

    • 0
      3. Оверселлинг никуда не девается.


      Вы так говорите, как будто бы оверселлинг это плохо для клиента: все хорошо в меру, пока LA на ноде приемлимое(все же знают, что обыно на OVZ машинах оно в несколько раз больше, чем на stadalone на этом же железе?), часть клиентов все равно не использует большую часть своих ресурсов. См. в топике абзац про теорию игр.
      • 0
        Еще раз про оверселлинг: ИМХО, оверселлинг это общее благо для клиента и для хостера, пока хостер продает не используемые ресурсы. Но некоторые нехорошие хостеры на этом не останавливаются, и начинают продавать уже используемые, так что у них VPS клиентов, например, вечно в swap сидят.
        Чем больше заработает хостер, тем лучше для клиента: хостер сможет купить лучшее оборудование, нанять более опытный и доброжелательный к клиентам саппорт, даже если владелец хостинга все положит себе в карман, это тоже благо для клиента: вспомните нерентабельный макхост, с его долгами перед датацентром!
      • 0
        Оверселлинг имеет право быть только при одном единственном условии: когда моему крону потребуются ресурсы, я их получу в полном объёме без каких-либо задержек.

        Выполнение этой гарантии нереально сложно, как технически, так и административно.
        • 0
          Сложно, если виртуалок до 10-15, хотя вполне вероятно (это часто случай гипервизоров), и невероятно НЕ выполнение, если гостевых систем под 50-100.
          В OpenVZ, за счет большой плотности контейнеров, можно безопасно оверселлить раза в два: теория вероятности не даст сразу 25 клиентам резко и одновременно увеличить потребление ресурсов.
          • +2
            Буквально недавно разбирались с одним из шаблонов виртуалок — в 4:04 рост нагрузки на диски примерно в 40 раз. Выяснилось — пропущенная раномизация в кроне, плюс софт, который ставился в cron.daily.

            То есть брали и по крону синхронно предъявляли.

            Пичок на 00:00 я вполне глазами вижу, и он совсем не из-за забытого недорандома — просто люди, когда решают «когда запускать» прописывают у себя нули. Независимо, но одинаково. Типовой час пик.
            • 0
              Диски это слабое место, да, там неполная изоляция (причем не только у OpenVZ!)
              А вот ОЗУ-ЦПУ вы, если хостинг оверселлит только простаивающие ресурсы, вы получите всегда, когда они Вам понадобятся.
              • +1
                А как он определяет, простаивающие они или нет? Я имею в виду не усреднённое значение, а вот «прямо сейчас». Если у меня нечто на 25% мощи сервера (по CPU, например), обычная утилизация у меня 5%, то очевидно, что простаивающие 20% будут перепроданы. А теперь вопрос: а если я внезапно захочу свои 25% мощи, а из этих 20% 10% занято, что будет?..

                А с памятью ещё веселее. Допустим, по тарифу 4Гб. Процессы болтаются в 300Мб. 2Гб из этих 4 кому-то отдали. Потом ещё кому-то. И на выходе на хосте 4Гб свободно. Час Х. Три человека по гигабайту предъявили внезапно, и тут я свои 4 хочу. А есть 1. И?
                • 0
                  Допустим, у нас на OpenVZ ноде 32 Gb озу,

                  32*1024/500=65

                  Можно безопасно продавать до сотни, по тому, что утилизация памяти у практически всех будет около 50%.
                  Хотя в реальном мире сотня пятьсот мегабайтных контенеров скорее всего потребуют очень скорострельный raid контроллер и SAS 15k, но не суть.

                  Как Вы себе представляете то, что бы ресурсы одномоментно потребовало 30-40 контейнеров? Такого не бывает, вероятнее, что обезьяна, стуча по клавишам, случайно напечатает поэму :)

                  А вот при плотности в 10-15-20 xen-доменов на dom0, характерной для xen-хостеров, когда вас будут оверселлить по CPU, гораздо вероятнее, что Вы свои ресурсы недополучите :)

                  4Gb VPS-ки на OpenVZ зло. Я делала такие контейнеры для сервисов в офисах, но покупать и продавать такое на OVZ не очень правильно.
                  • 0
                    Как Вы себе представляете то, что бы ресурсы одномоментно потребовало 30-40 контейнеров?

                    Поставили бэкапы в кроне на, скажем, 4 утра, когда внешняя нагрузка статистически минимальна.
                    • 0
                      на практике не наблюдается. Таки от HTTP нагрузка гораздо больше(внимание, мы сейчас говорим об ОЗУ/CPU).

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

                      Я другое видела: как серверы шаред-хостинга убивает яндекс или гуголь в час-в два ночи :) Буквально один сайт. На OVZ такого не бывает никогда: ну точнее, убивается контейнер, который агрессивно индексируют, а его соседи по серверу ничего не замечают.
                      • 0
                        Сжатие мало нагрузки на CPU создает?
                        • 0
                          много, если в контейнере видно только одно ядро :))
                  • 0
                    а вот скажите мне вот какую простую вещь: fsync внутри контейнера приведёт к сбросу данных на диск только для него?
                    • 0
                      Точно не знаю, я бы уточнила в рассылке. Когда узнаете ответ, скажите мне пожалуйста :)

                      Полагаю, что нет, это для всей ноды, но
                      sys.fs.fsync-enable=0 в systct.conf должно отключить возможность делать fsync внутри контейнера.
    • 0
      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 ~]#


      Проблема точно существует?
      • 0
        В госте:

        while true; mount / / -o bind;done

        (в тексте ошибка от крипткидди).

        Оставьте на часика два и попытайтесь посмотреть команду mount от рута или с соседнего контейнера.
        • 0
          :))) а еще, можно сделать цикл, который будет делать директорию, потом в ней еще одну, а в следующей еще одну. Если число инодов достаточное, можно создать проблемы хостеру (работает на шаред хостинге в OpenVZ), ему придется писать скрипт, который спустится в самый низ, и начнет удаление от туда.
          Еще OVZ ноду можно убить, таря миллионы файлов.
          Мне кажется, нужно попросить разработчиков ограничить число mount --bind для контейнера, что бы было в user_beancounters. Наверняка эту фичу реализовать совсем не сложно.
          .
          Только вот… стопроцентной изоляции нет нигде! Даже если у Вас дедик, вы можете уложить всех ваших соседей, если на вас пойдет большой UDP- DDoS, маршрутизаторы хостера могут не справиться
          • 0
            100% изоляцию можно получить, организовав собственные сессии с аплинками. У нас есть крупные клиенты, которые именно так держат свои сервера, полностью автономно.

            Что же касается «пойдёт большой DDoS» — про 400 гигабит я, конечно, читал, но своими глазами не видел больше 5 гигабит. 5 гигабит спокойно перевариваются (хотя жертву и придётся на отдельный хост переносить из-за гигабитного порта до коммутатора — сам коммутатор уже 20Гбитами до маршрутизатора идёт).
          • 0
            … Да, насчёт изоляции.

            В этом и есть разница между гипервизорами и контейнерами. У гипервизоров конфликт бывает только за конечное число легко измеряемых ресурсов (IO, memory, CPU, network), а у контейнеров точек исчерпания ресурсов общего ядра очень много, и процесс их затыкания beancounter'ами напоминает процесс затыкания дырявого корыта на плаву. Одно заткнули, с другого потекло.
            • +1
              В этом и есть разница между гипервизорами и контейнерами. У гипервизоров конфликт
              бывает только за конечное число легко измеряемых ресурсов (IO, memory, CPU, network),


              а OVZ/PVC хорошо изолирует по CPU :)) почитайте про cpuunits, и cpulimit. Там выше была целая ветка обсуждения: OpenVZ даже, если хостер желает быть честным, позволяет считать фактическую производительность, и давать контейнеру работать с одной скоростью даже на разных CPU (ведь мегагерцы это те еще абстрактные попугаи).

              Насчет network, как раз с помощью tc в OpenVZ можно сделать самодельные скрипты, которые будут шейпить контейнеры. Не нравится, что скрипты самодельные? Саппорт Параллельса мне говорил, что они добавят шейпинг в виртуозу, где она будет легко рулится через API с помощью биллинга хостера (не знаю, добавили, или еще нет)
  • +3
    > Если хостер Вам нагло не врет

    По опыту работы с тем же МастерХостом, провайдеры в России любят оверселить «по самые немогу», притом на прямые вопросы отвечают просто — «ничего делать с вашим хост-сервером не планируем». Я к тому, что оверсел в России — это не «лучше сервера и выше з/п ТП», это скорее плюс в карман владельцам, либо возможность подольше не выводить из сервиса старые, перегруженные сервера, куда уже даже память не лезет.

    Оверсел еще и к тому ведет, что, случись хостеру жить без этой «фичи», он бы в сервер с 64 Гб памяти засунул бы 120-126 виртуальных машинок по 512 Мб памяти (еще не страшно за качество работы каждой машины?), и они давили бы друг друга по IO и CPU, но хоть как-то бы жили. Когда, «спасибо» волшебной возможности дважды продать то же самое (в ГК это называется обман, но — о чем мы, это же мир ИТ!), в тот же сервер впихивают машин 160-180, и IO (внезапно?!) растет вообще до небес, после чего ТП только и может, что кивать на «мелкий шрифт» в договоре, мол, «никто Вам ничего конкретного не обещал». Совсем-совсем неправда, что, выбрав хостинг с оверселом, клиент автоматом оказывается на машине с надежным быстрым SSD-массивом, скорее, из наличия оверсела можно предположить жлобство и повышенную экономичность этого хостинга. До добра такое редко когда доводит (см. выше про то, что на стоимость серверов и оплату ТП в лучшую сторону это не повлияет).

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


      Дело в том, что на гипервизорах Вас оверселлят по CPU, дисковым iops, и сети.
      Поэтому тезис о том, что «openvz оверселлит, а xen нет», является просто-напросто ложью. Ну и… я попыталась объяснить, что оверселлинг это не так плохо, как его рисуют некоторые не чистые на язык Xen-хостеры, сами втихаря оверселя.
      • 0
        Тут с Вами согласен. Я не очень просто поддерживаю ваше процитированное высказывание («Если хостер Вам нагло не врет...»), о том, что оверсел на OpenVZ суть хорошо.

        Оверсел всегда плохо. По крайней мере тем, что не дает делать то, что от машины ожидаешь, и за что (согласно тарифу) и платишь.

        Еще хуже, когда он есть, а о нем хостер говорит, что его нет. За такое (тут уж, правда, не в технологии дело) руки надо обрывать.

        Так и приходишь к мысли, что либо идти к приличным (мало, но таких есть), либо брать физический сервер, со всеми вытекающими.

        Я, кстати, встречал хостера, который прямо говорил, что с высоким потреблением CPU и диска клиент им на виртуалке не интересен (и сам будет недоволен, и другие будут жаловаться), и что под такую нагрузку советует взять сервер, даже готовы были скидку на сервер сделать, чтобы все оказались довольны. Таким людям руку жать хочется! :) Кстати, российские ребята, так что не все в России совсем плохо — но таких, как они, мало.
        • 0
          Советуют ладно, но бывает, что выгоняют. То есть купил, грубо говоря, гигагерц CPU, нагрузил его на 100% и тебе аккаунт блочат.
        • 0
          Я, кстати, встречал хостера, который прямо говорил, что с высоким потреблением CPU и диска клиент им на виртуалке не интересен


          Про CPU какой-то бред, от этого хостера нужно бежать. А вот за потребление i/o, да, могут выгнать на дедик.
  • +1
    Для Openvz
    1. Не освещена проблема разделяемой памяти. Использование апача на OpenVZ рисковое занятие. (хотя может уже не актуально? просветите пожалуйста.)
    2. Не освещена проблема загрузки модулей. Ну тут, конечно, всё от хостера зависит. Чаще всего нужны tun и dm-crypt, но их нет.
    • 0
      1. Не освещена проблема разделяемой памяти. Использование апача на OpenVZ рисковое занятие. (хотя может уже не актуально? просветите пожалуйста.)


      Как раз писала об этом. ulimit в стартовом сценарии Апача решает

      2. Не освещена проблема загрузки модулей. Ну тут, конечно, всё от хостера зависит.


      Маленькие хостеры обычно соглашаются, а вот большие нет: не хотят иметь разный состав модулей на разных нодах. У больших все стандартизировано, и серверы поставлены неинтерактивно по сети с помощью, например, редхатовского кикстарта. Они не любят нестандарт, по тому, что сложно администрировать десятки и тем более сотни сильно отличающихся физических машин.
  • +1
    Почему в топиках, защищающих 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. При этом ни разу не видел, чтоб писали как-то по-другому или поясняли этот вопрос.
    • +1
      что это означает — под OpenVZ многопоточные программы могут занимать занимать в несколько раз больше памяти, чем на реальных машинах


      Вообще-то я об этом писала выше. В стартовом скрипте апача можно использовать ulimit, и проблема, о которой Вы рассказали, нивелируется.
      • 0
        Хм, в статье про VIRT и RSS ничего не увидел. Видел про своп, но это немного другая проблема. Ткнете в нужное место?

        Ну и ulimit — это не решение, а костыль :) Причем это костыль только многопоточности (=="… в том числе ОС"); при других вариантов использования виртуальной памяти (заммэпить файл, например?) это не помогает ведь? В итоге минное поле получается какое-то — ставишь программу и не знаешь, будет ли она работать нормально или отожрет гиг памяти просто так.
        • 0
          Хм, в статье про VIRT и RSS ничего не увидел. Видел про своп, но это немного другая проблема. Ткнете в нужное место?


          В комментариях чуть выше писала «странно, что никто не пожаловался на поведение apache на openvz»

          ulimit вообще лимиты на шелл ставит, так что не упадет ваша VPS, максимум процесс.
    • +2
      C выходом vSwap в OpenVZ осталось только два параметра: physpages и swappages.
      physpages — лимитирует физическую память (RAM) для контейнера.
      swappages — это свап.

      Это все равно не очень честно, но очень близко к реальным значениям именно физической памяти. А виртуальная — да пусть хоть до конца космоса простирается. Если приложение захочет больше, чем есть физической, придет сначала всвап, потом оомкиллер.
      При неправильной конфигурации еще сюда вклинится честный свап на хостноде, вот это уже плохо и пострадает вся ферма со всеми контейнерами. Ну, аккуратнее надо просто админу быть и понимать что делать.
      • 0
        По умолчанию просто процессы апача очень жирные. Им можно зарезать ресурсы на несколько порядков через ulimit, и все равно при той нагрузке, что возможна в контейнере, размеров стека хватит.
        • 0
          а при чем тут ulimit, если privvmpages больше не ограничиваются?
          • 0
            ulimit можно использовать на ядре пятой шапки (не все хостеры еще мигрировали...)
      • 0
        А, круто тогда, спасибо за информацию.
  • –1
    Поделюсь своим опытом с виртуозо.

    Как-то темной ночкой, на виртуалке через SSH набираю convert *.jpg бла-бла-бла в директории, где 500 картинок лежат, по 300-500 килобайт каждая. Жамкаю ентер — а оно тупо берет и зависает. В смысле насмерть зависает. Дозвонился до провайдера — он смог оживить машину только нажатием кнопки на системнике.

    Следующей ночкой с ТП провайдера эксперимент повторили, и еще несколько аналогичных поставили. Пришли к выводу, что под пиковой «шоковой» нагрузкой виртуоззо действительно подвешивает хоста.

    С KVM такого эффекта получить не смогли.
    • +1
      У меня таких случаев (на >100 физических нод с виртуозо, rhel5-based ядро) не было. По симптомам похоже на то, что развалился рейд, а последний оставшийся в нем диск тоже начал сыпаться.
      • 0
        а вы дайте один контейнер на растерзание местной публике. сразу оценим ))
        • +1
          Не дам. Выше сама привела несколько способов, как хостеру можно создать проблемы.
          Только вот и дедик может растерзать соседей, устроив udp-поток через свой коммутатор, особенно хорошо получится с гигабитным аплинком.
          Xen-KVM гости тоже смогут уложить физическую машину :)

          Кстати, таких любителей-затейников как автор треда, хостеры обычно выключают. Ему попался добрый, склонный к эксперементам саппорт :))))

          Но что imagemagick может уложить физическую машину на полтысячи картинок, это бред.
  • 0
    так как нет накладных расходов на запуск гостевых ядер и переключение контекстов

    Рискую быть закидынным камнями, но откуда вы взяли такую глупость по поводу отсутствия переключения контекстов?
    Хотите сказать что все контейнеры в OpenVZ работают в одном адресном пространстве?
    • 0
      Да, с ноды видны все процессы. Но внутри видны процессы только свои, лишние скрываются, а номера виртуализируются, то есть pid init-а равен единице.

      Поэтому процесс, запущенный в Xen и KVM всегда будет работать медленнее, чем в OpenVZ
      • 0
        Я не про процессы, а про отсутствие переключения контекстов.
        Не разбирался, но по моему, утвержение безосновательное ибо слабо представляю как же так безопасно заставить работать много контейнеров в пределах одного адресного пространства, чтобы не было переключения контекстов между задачами.

        Поэтому процесс, запущенный в Xen и KVM всегда будет работать медленнее, чем в OpenVZ

        Вовсе необязательно. Если посмотреть на технологию сбоку, то разницы нет, везде двухэтапная планировка выполнения задачи (сначала в гостевой ОС и потом в гипервизоре) и никаких дополнительных технологий по ускорению выполнения задачи у OpenVZ нет.

        Думается мне, что если Вы возьмете виртуалку на xen и контейнер на OpenVZ, запустите на обоих тестовый код на Си, который будет в цикле считать 1 << 11 несколько млн итераций, то разницы не увидите (при условии, что на гипервизорах не будет сильной конкуренции за ресурсы)
        • 0
          Не разбирался, но по моему, утвержение безосновательное ибо слабо представляю как же так безопасно заставить работать много контейнеров в пределах одного адресного пространства, чтобы не было переключения контекстов между задачами.


          Точно так же, как работает cgroups. У нас одно ядро, одно адресное пространство, но есть группы процессов, к которым применяются ограничения(namespaces).

          Думается мне, что если Вы возьмете виртуалку на xen и контейнер на OpenVZ, запустите на обоих тестовый код на Си, который будет в цикле считать 1 << 11 несколько млн итераций, то разницы не увидите (при условии, что на гипервизорах не будет сильной конкуренции за ресурсы)


          В том-то и дело, что разница будет! В топике есть ссылка как раз на бенчмарк OpenVZ vs Xen.
          • 0
            Про переключение контекстов в OpenVZ

            В том-то и дело, что разница будет! В топике есть ссылка как раз на бенчмарк OpenVZ vs Xen.

            Таки попробую и проверю.
            • 0
              Но адресное пространство у контейнеров одно. Кстати, unix bench по вашей ссылке для Xen-а такой характерный: раза в два с половиной меньше, чем для native и .OpenVZ
              • 0
                Почитал тут немного, действительно вместо переключений контекса openvz следит за попытками использовать чужую память и просто ограничивает в случае необходимости.

                В таком случаем более уместно сравнивать паравиртуализацию на xen c openvz, а не эмуляцию аппаратной части в xen c openvz.
                • 0
                  В таком случаем более уместно сравнивать паравиртуализацию на xen c openvz, а не эмуляцию аппаратной части в xen c openvz.


                  Нет, совсем не уместно. Паравиртуализация подразумевает гостевое ядро с устройствами ввода-вывода (я о сети, дисках, итд) устроенными очень просто, не эмулирующими скази-иде-сата контроллеры, видеокарту, и др.
                  Есть еще паравиртуальные драйверы, когда ядро специально не модифицировано для использования простых устройств, но эти устройства, простые, реализованы драйверами.

                  OpenVZ, LXC, Jails, Solaris Containers же суть то же, что и chroot: как chroot организует не виртуальный диск, а лишь свое пространство адресов в файловой системе, так и openvz всего навсего организует namespaces для таблиц маршрутизации, правил iptables, номеров процессов, и тд.

                  Контейнеры это вообще не виртуализация, это просто такой навороченный chroot, который выглядит как виртуалка, и который работает практически со скоростью нативного «железа».
  • 0
    на OpenVZ нельзя FUSE, на Xen — можно. вернее, даже не так: большинство хостеров на OpenVZ запрещают FUSE. на Xen — нет.
    • 0
      Хостерам просто не хочется делать вот это:
      openvz.org/FUSE

      В силу ряда причин.
      Одна из них, контейнер с такой штукой нельзя смигрировать онлайн для балансировки нагрузки. Делала бы сейчас OVZ хостинг средних размеров, просто предупреждала бы клиентов, что их могут неожиданно выключить на несколько минут, при перевозе на менее загруженный сервер, если у них OpenVPN или, скажем, FUSE.
  • +1
    Соглашусь, что каждая из систем виртуализации может лучше подходить для одних задач и не быть оптимальной для других. При должной глубине понимания той или иной системы, в принципе, реализовать задачи можно и на той, и на другой. Конечно, отождествлять системы, у которых различные уровни виртуализации по отношению друг к другу — не надо. Априори, использовать кастомные ядра для машин в OpenVZ/Virtuozzo не получится. С другой стороны, использовать машину на OpenVZ/Virtuozzo проще и легче, чем на Xen/KVM. Когда уровня виртуализации приложений — достаточно, зачем накручивать больше?
    Есть другой вопрос. Тут пишут, что VPS/VDS на OpenVZ/Virtuozzo, при замеченных нагрузках от машины на ноде, выключают, или останавливают. Дело в том, что Xen-машину так же остановят, если увидят больше потребление ресурсов. Здесь вопрос более юридический, чем технический — кто за что блокирует. Безусловно, есть компании, которые, наоверселлив свыше крыши, при каждом чихе машины блокируют. Надо уходить от таких.
    • 0
      На Xen/KVM тоже выключают. Более того, иногда выключают дедики (за, например, udp DDoS на сайт на вашем дедике).

      OpenVZ это не шаред хостинг, наоборот, значимая часть клиентов OpenVZ это «выгоненцы» с шареда с тяжелыми скриптами. В отличие от сервера шаред-хостинга, где 500-1000 клиентов на сервер, и за неделю-две кого-то обязательно выключают, OpenVZ-виртуозо VPS-ки выключают очень редко. На > 100 физических машин под виртуозой на моей прошлой работе одну VPS выключали в среднем раз в два-три месяца, и то это заканчивалась обычно тем, что с клиентом договаривались, что он диски больше грузить не будет, а не выгонянием на dedecated-сервер
      • 0
        Вот из-за DDoS VPS-ки выключали чаще :( Или клиенты сами писали-звонили, что из-за DDoS у них лег VPS. Но проблему DDoS на моей прошлой работе иногда решали успешно фильтрацией зарубежных IP.
      • 0
        Да, все так и есть. Либо же могут «зайти» на машину и остановить нагружающий систему процесс. Кстати, Вы справедливо замечали — HN вполне себе живет с большой нагрузкой по процессору или памяти, при LA 800 и более, например. Видел HN с LA за 1000, и ничего. А вот при DoS'ах да, если просядет канал, будут загибаться все ноды на HN. Просто в Xen многое так же — тот же xentop отображает потребление основных ресурсов доменами, можно так же выключать. Более беспокоит то, что в России многие не брезгуют оверселлингом. Я все-таки считаю, что это плохо, то есть плохо, когда чрезмерно. Конечно, держать машины количеством вровень с физическими параметрами сервера — неразумно. Однако и в несколько раз больше пихать тоже не стоит. Если оверселл разумный — HN живет прекрасно. Но в России немало сильно перебирают, и вместо размазывания по другим HN, не имением оных, к примеру, по финсоображениям (что не редко есть), выталкивают клиентов на дедики. клиент, правда, также должен разбираться в размещаемых проектах на VPS. Иначе однажды появится бяка, а он не знает, что делать. Здесь как бы тоже юридический вопрос. Выключать такого, терять деньги на нем, под угрозой ухода, а не перехода на дедик, или разбираться в его контенте. Мало кто будет делать последнее.
  • 0
    Я правильно понял, что этой статье более 5ти лет?
    www.hpl.hp.com/techreports/2007/HPL-2007-59R1.pdf
    • 0
      Вот Вам ссылка на страничку с несколькими более свежими тестами:

      openvz.org/Performance

      А почему Вы думаете, что с тех пор что-то принципиально изменилось? Под гипервизором всегда софт будет работать медленнее, чем под native системой, а под контейнерами, OS-Level virtualization, практически с такой же скоростью, как нейтив, можно лишь считанные проценты туда-сюда перетасовать, но это соотношение по производительности никак не изменить, по тому, что такова их природа.
  • 0
    Вот — habrahabr.ru/qa/39269/, живой пример отстойности openvz
    • 0
      У меня такого экспириенса не было. А в посте слишком мало информации: никаких конфигов(контейнера и самой ноды), версий ядра, vzctl, и тд не приведено.
      99% что кривые руки того, кто делал сетап.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.