Попытка развенчания мифов об 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
    Метки:
    Поделиться публикацией
    Комментарии 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
                                              • –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 инстансов апача и память