Проект OpenVZ проводит опрос (http://goo.gl/forms/orYmy0SjFB) среди своих пользователей, который позволит лучше понять потребности интересующихся проектом людей, оценить сценарии использовании контейнеров OpenVZ, изучить окружение в котором применяются контейнеры и т.д. Голосование продлится до 1 июля 2015.
Напомним, что в соответствии с предложенным (http://www.opennet.me/opennews/art.shtml?num=41350) ранее планом, недавно был открыт (http://www.opennet.me/opennews/art.shtml?num=42113) исходный код ядра RHEL7 с патчами для контейнерной виртуализации, которое войдет в новую версию OpenVZ. Также введен в строй новый репозиторий (https://src.openvz.org/projects) исходного кода. Тем самым инициирован открытый процесс разработки проекта. В данный момент ведётся (http://lists.openvz.org/pipermail/devel/2015-May/thread.html) активное портирование патчей в ядро RHEL7 и подготовка к публикации исходного кода пользовательских утилит.
URL: https://plus.google.com/+OpenVZorg/posts/bciB99aeo25
Новость: http://www.opennet.me/opennews/art.shtml?num=42275
Поздно. Docker наше все!
Он же дырявый и на Go написан!!!
А чего все тут на Go кидаются в каждой новости?Какие у него _объективные_ минусы?
> А чего все тут на Go кидаются в каждой новости?
> Какие у него _объективные_ минусы?Очевиднейший:
---
The linkers in the gc tool chain (5l, 6l, and 8l) do static linking. All Go binaries therefore include the Go run-time, along with the run-time type information necessary to support dynamic type checks, reflection, and even panic-time stack traces.A simple C "hello, world" program compiled and linked statically using gcc on Linux is around 750 kB, including an implementation of printf. An equivalent Go program using fmt.Printf is around 1.9 MB, but that includes more powerful run-time support and type information.
--- http://golang.org/doc/faq#Why_is_my_trivial_program_such_a_l...Причём в этом ответе они передёргивают аж два раза: во-первых, мало кому нужен именно статический сишный hello; во-вторых, этот "more powerful runtime" вряд ли кто-то станет выковыривать из бинарника, которому такая внагрузка ровным счётом никаких плюсов не даёт.
Что само по себе настораживает.
Ну насколько я знаю при создании языка предполагалось использовать его для системных вещей, утилит.
На память приходит OCS-Inventory. Их агенты под разные системы пишутся каждый отдельно и со своими тараканами. Есть версия "standalone unix agent" (тоже статически собирается), так он в таком виде тоже мегабайты занимает.
На Go можно было бы написать код один для нескольких платформ и собирать под нужную. Мне как админу 2 мегабайта выделить под агента не влом. Статическая сборка позволит использовать его на любых системах с любыми версиями компонентов.
Я к тому, что с точки зрения опытного программиста, может Go и плохо, но оно же не должно быть только для программистов, если позиционируется как некий системный инструмент?Или я картину вижу не совсем всю?
PS
Сам пишу скрипты в рамках своих админских задач, софт как таковой не пишу.
Есть разница между "можно статически" и "только статически".
> Есть разница между "можно статически" и "только статически".Ну есть еще gccgo, он собирает не статически. Да и правильнее сравнивать GO не с сями а с питоном и руби. Его странно позиционируют, как системный, но если посмотреть примеры, то большинство использует его именно для веб-сервисов. А мало кто пишет веб-сервисы на сях, обычно шарашат на скриптовых языках. И если сложить интерпретатор, его библиотеки да еще apache/nginx, то тут 5яти мегабайтный гошный бинарник, уже и выигрывает.
> Ну есть еще gccgo, он собирает не статически.Но гуглем по дефолту сватается другое и с странными подходами.
> Да и правильнее сравнивать GO не с сями а с питоном и руби.
Они тем более не компилят статически по дефолту, и тем более не сравнимы по скорости ни с си ни с го, так что сравнение получается так себе.
> именно для веб-сервисов. А мало кто пишет веб-сервисы на сях,
Там весьма зависит от. Есть и всякие плюсовые шаблонизаторы и прочая. И там еще вопрос кто куда и с кем сравнится.
Миша ты того ... устарел слегка :) В Go - не "только статически", но надо ручками юзать другой линкер и прочий гимор. Да сделают, куда денутся :)
> Миша ты того ... устарел слегка :)Так это ж хорошо :)
PS: спасибо Вам и Александру (#17) за уточнение.
> но надо ручками юзать другой линкер и прочий гимор."А если вот так посмотреть - то вовсе даже и не кривой" :)
>> А чего все тут на Go кидаются в каждой новости?
>> Какие у него _объективные_ минусы?
> Очевиднейший:
> The linkers in the gc tool chain (5l, 6l, and 8l) do static linking.
> All Go binaries therefore include the Go run-timeэто практическая реализация принципов UNIX-way и KISS.
что не удивительно, потому что Go делали те же самые люди,
которые перед тем делали UNIX.называть это минусом - как-то странно.
> во-вторых, этот "more powerful runtime" вряд
> ли кто-то станет выковыривать из бинарника, которому такая внагрузка ровным счётом
> никаких плюсов не даёт.плюсы есть - деплоймент новой версии приложения оказывается тривиальным процесом,
нет никаких проблем с зависимостями. Причем, памяти в процессе работы такая программа
будет занимать меньше, чем аналогичная программа на Java, потому что тут нет JIT
и бинарный код формируется прямо в процессе компиляции, а не во время исполнения.
> плюсы есть - деплоймент новой версии приложения оказывается тривиальным процесом,Как-то у меня был проект, на плюсах, который нам в итоге пришлось собирать статически. И вот я так доложу - деплоймент на площадку 6 статически собранных бинарей, в сумме тянувших на гиг с лишним, был нифига не тривиальным занятием. Точнее, конечно, тривиальным, когда не надо быстро, а когда надо быстро - там-то и начинался весь секес.
>> А чего все тут на Go кидаются в каждой новости?
>> Какие у него _объективные_ минусы?
> Очевиднейший:Новое оно. Все шишки ещё только предстоит набить :-(
Остальное - всё фигня, и решаемая и уже над многим из - работают.
> Какие у него _объективные_ минусы?Используется всякой хипстотой, считающей что за них подумает компилер и рантайм. В системных тулзах это ессно ведет к туевой хуче дыр всех мастей (и Docker в этом плане очень показателен). А еще зачем-то все в статику линкует.
...а в OVZ очевидный минус - требуют левое кастомное ядро. Это очень жирный минус.
> ...а в OVZ очевидный минус - требуют левое кастомное ядро. Это очень
> жирный минус.Есть ещё один минус. Ядро тоже не безбажно, а кастомное ядро с такого размера патчсетом - вдвое более не безбажно. Соответственно если в PV падает ядро - у вас падает только VM, если в OpenVZ падает ядро - падает вся нода. PV-механизмы тоже не безбажны, но гипервизоры всё-таки помельче по размеру будут, чем ядро. Ну и юзерспейс с PV-часть гипервизора всё-таки не взаимодействует, а вот контейнеры с ядром... Т.е. шансов уронить контейнерную ноду куда больше.
> Есть ещё один минус. Ядро тоже не безбажно, а кастомное ядро с
> такого размера патчсетом - вдвое более не безбажно.Ошибаетесь -- люди из ovz team нашли и починили немало багов, включая весьма неприятные и ни разу не относящиеся к их парафии.
> Соответственно если в PV падает ядро - у вас падает только VM, если в
> OpenVZ падает ядро - падает вся нода. PV-механизмы тоже не безбажны,
> но гипервизоры всё-таки помельче по размеру будут, чем ядро.Занятные сравнения. А если падает ядро на железке? :) А мельче ли гипервизоры, чем ovz?..
> Занятные сравнения. А если падает ядро на железке? :) А
> мельче ли гипервизоры, чем ovz?..В данном случае гипервизор надо сравнивать именно с ядром в целом, так как в работе OpenVZ участвует львиная доля кода самого ядра. И если бахнется ядро - всем будет пофиг, бахнулся там код OpenVZ, или что-то ещё. Ну и любая мало-мальски серьёзная дыра в ядре (в любом коде, хоть OpenVZ, хоть нет) превращается в дыру всей ноды. C гипервизором же, повторюсь, юзерспейс виртуалок взаимодействует либо никак, либо крайне ограниченно. В итоге сначала придётся получать рута на VM, потом искать настолько же серьёзную дыру в гипервизоре.
> В данном случае гипервизор надо сравнивать именно с ядром в целом,
> так как в работе OpenVZ участвует львиная доля кода самого ядра.А в работе KVM? :)
Если что, у меня стабильные ovz-шные ядра в падениях не замечены. Были проблемы с ранними 2.6.32, особенно пока не дочитал до места про "теперь обязательно сконфигурируйте --ram/--swap, старых privvmpages&co недостаточно".
а nf_conntrack ip_conntrack_disable_ve0=1 не зацепило?да, я в курсе, что оно систему не роняет, но неработающий stateful firewall без толковой диагностики -- это неприколько. до сих пор надо руками править, чтобы оно заработало.
> Поздно. Docker наше все!Правильно, тёплое круче мягкого!
> Поздно. Docker наше все!расскажете мне, как обновить контейнер, слушающий на 80 порту, без даунтайма?
docker-way: завершить старый, подождать (даунтайм), поднять новый.
ну, либо извращаться с редиректами на iptables на хост-системе.
>> Поздно. Docker наше все!
> расскажете мне, как обновить контейнер, слушающий на 80 порту, без даунтайма?*Почти* http://www.luffy.cx/en/blog/2015-hotfix-qemu-venom.html docker-way.
> docker-way: завершить старый, подождать (даунтайм), поднять новый.
>>> Поздно. Docker наше все!
>> расскажете мне, как обновить контейнер, слушающий на 80 порту, без даунтайма?
> *Почти* http://www.luffy.cx/en/blog/2015-hotfix-qemu-venom.html docker-way.а причём тут docker? там про qemu рассказывают.
>> *Почти* http://www.luffy.cx/en/blog/2015-hotfix-qemu-venom.html docker-way.
> а причём тут docker? там про qemu рассказывают.Апгрейд с downtime=0 === Не искать лёгких путей.
Ну, мож, и не докер. Но кроваво-энтерпрайзно точно. [И да, кластер-шардер из докеров -- тоже!]
>>> *Почти* http://www.luffy.cx/en/blog/2015-hotfix-qemu-venom.html docker-way.
>> а причём тут docker? там про qemu рассказывают.
> Апгрейд с downtime=0 === Не искать лёгких путей.
> Ну, мож, и не докер. Но кроваво-энтерпрайзно точно. [И да, кластер-шардер из
> докеров -- тоже!]маленький нюанс: xen/kvm можно live-мигрировать с хоста на хост. а докер нельзя.
я больше скажу: даже в openvz можно: https://openvz.org/Checkpointing_and_live_migrationа докер нет. есть criu, но это не live migration.
>> Поздно. Docker наше все!
> расскажете мне, как обновить контейнер, слушающий на 80 порту, без даунтайма?++Отдельное спасибо за вкусный corner-case этой свистоперделки.
на здоровье. у меня есть нехилый опыт докера в продакшне и я действительно считаю, что докер пока многого не умеет и должен быть лучше.на данный момент я его переел: недостатки перевешивают плюсы.
а основной плюс докера: соединение configuration management с запуском виртуалок. очень хорошая идея, но докер пока сыроват. впрочем, если openvz таки нормально скрестят с ансиблем, нафиг тот докер.
> расскажете мне, как обновить контейнер, слушающий на 80 порту, без даунтайма?через Blue/Green Deployment.
тут теория: http://martinfowler.com/bliki/BlueGreenDeployment.html
тут практика: http://arojgeorge.ghost.io/a-continuous-delivery-example/
>> расскажете мне, как обновить контейнер, слушающий на 80 порту, без даунтайма?
> через Blue/Green Deployment.
> тут теория: http://martinfowler.com/bliki/BlueGreenDeployment.html
> тут практика: http://arojgeorge.ghost.io/a-continuous-delivery-example/я в курсе, что это такое. итак, практическая задача: обновить docker-контейнер, слушающий на 80 порту, без даунтайма (переключить со старого на новый).
у docker вариант один: делать балансировщик на iptables. по линкам даже это не рассказано.
вы знаете другие варианты?
> практическая задача: обновить docker-контейнер, слушающий
> на 80 порту, без даунтайма (переключить со старого на новый).
> у docker вариант один: делать балансировщик на iptables. по линкам даже это
> не рассказано.
> вы знаете другие варианты?да, в качестве балансировщика использовать nginx или haproxy.
> в качестве балансировщика использовать nginx или haproxy.ну-ну. лучше бы возможность переключить порт, на который забинден контейнер.
нет, можно сделать так: старый контейнер слушает на 8080, новый на 8081, а nginx'у мы говорим, куда коннектиться, через jenkins, например. но всё равно кривовато.
> ну-ну. лучше бы возможность переключить порт, на который забинден контейнер.
> нет, можно сделать так: старый контейнер слушает на 8080, новый на 8081,
> а nginx'у мы говорим, куда коннектиться, через jenkins, например. но всё
> равно кривовато.особенно кривовато это становится, когда у нас новый контейнер становится старым. ну нахрена эти пляски на пустом месте?
> лучше бы возможность переключить порт, на который забинден контейнер.
> нет, можно сделать так: старый контейнер слушает на 8080, новый на 8081,
> а nginx'у мы говорим, куда коннектиться, через jenkins, например. но всё
> равно кривовато.поздравляю, вы только что изобрели метод Blue/Green Deployment.
> особенно кривовато это становится, когда у нас новый контейнер становится старым.
других вариантов нет.
> ну нахрена эти пляски на пустом месте?
чтобы получить zero downtime deployment.
>> лучше бы возможность переключить порт, на который забинден контейнер.
>> нет, можно сделать так: старый контейнер слушает на 8080, новый на 8081,
>> а nginx'у мы говорим, куда коннектиться, через jenkins, например. но всё
>> равно кривовато.
> поздравляю, вы только что изобрели метод Blue/Green Deployment.
>> особенно кривовато это становится, когда у нас новый контейнер становится старым.
> других вариантов нет.есть: мы апдейтим код прямо в контейнере и говорим graceful reload демону.
но это не docker-way. там своё разделение на container- и user-provided filesystem, т.е. при обновлении системы или приложения мы натыкаемся на это.
моя претензия к докеру не в том, что если мы хотим два контейнера, нам надо переключаться между ними. а в том, что мы можем хотеть обновить один (из того же женкинса выбираем, из какого тэга/ветки): обновить код, сделать graceful reload. а в докере это свистопляски т.к. не вписывается в идеологию.
>>> лучше бы возможность переключить порт, на который забинден контейнер.
>>> нет, можно сделать так: старый контейнер слушает на 8080, новый на 8081,
>>> а nginx'у мы говорим, куда коннектиться, через jenkins, например. но всё
>>> равно кривовато.
>> поздравляю, вы только что изобрели метод Blue/Green Deployment.
>>> особенно кривовато это становится, когда у нас новый контейнер становится старым.
>> других вариантов нет.
> есть: мы апдейтим код прямо в контейнере и говорим graceful reload демону.далеко не весь софт запускается в виде "демонов"
и далеко не весь софт умеет делать graceful reload.поэтому, в общем случае - кроме Blue/Green Deployment других вариантов нет.
например, весь софт, который написан на Java не умеет делать graceful reload.> но это не docker-way. там своё разделение на container- и user-provided filesystem,
> т.е. при обновлении системы или приложения мы натыкаемся на это.разумеется. docker-way - это делать новый контейнер для новой версии софта.
> моя претензия к докеру не в том, что если мы хотим два
> контейнера, нам надо переключаться между ними. а в том, что мы
> можем хотеть обновить один (из того же женкинса выбираем, из какого
> тэга/ветки): обновить код, сделать graceful reload. а в докере это свистопляски
> т.к. не вписывается в идеологию.да, потому что докер реализует подход http://martinfowler.com/bliki/ImmutableServer.html
>> мы апдейтим код прямо в контейнере и говорим graceful reload демону.
> далеко не весь софт запускается в виде "демонов"ну не на cgi-скриптах на перле же. и не из inetd.
> и далеко не весь софт умеет делать graceful reload.
> например, весь софт, который написан на Java не умеет делать graceful reload.в java-мире (скорее, конкретных приложениях, чем технологии) много чего нельзя. но это не значит, что так и должно быть.
конкретно в части graceful reload -- те стеки, с которыми я работаю, это умеют. чего и вам желаю.
>> и далеко не весь софт умеет делать graceful reload.
>> например, весь софт, который написан на Java не умеет делать graceful reload.
> в java-мире (скорее, конкретных приложениях, чем технологии) много чего нельзя.
> но это не значит, что так и должно быть.это так есть. в общем случае этим методом задача не решаема.
> конкретно в части graceful reload -- те стеки, с которыми я работаю,
> это умеют. чего и вам желаю.а что это за стеки такие?
unicorn, uwsgi.даже в банально php (хоть mod_php, хоть php-fpm) проблем с этим на практике тоже, скорее, нет.
так что жуйте свою жабу, но нам рассказывать, что это нормально -- не надо.
> так что жуйте свою жабу, но нам рассказывать, что это нормально -- не надо.Программировать на языке Java - это нормально.
https://www.youtube.com/watch?v=kLO1djacsfg
> Программировать на языке Java - это нормально.Почему-то звучит как оправдание :)
>> Программировать на языке Java - это нормально.
> Почему-то звучит как оправдание :)Скорее уж как констатация факта.
http://habrahabr.ru/post/201612/
Java навсегда! 12 причин длительного доминирования Java
> Скорее уж как констатация факта.Вы сделали несколько ошибок в фразе "фанатские вопли".
> Java навсегда! 12 причин длительного доминирования Java
Мне этот булшит не интересен. Мне достаточно того что это переросточный и очень проблемный рантайм с кучей бестолковостей. Пусть им изен пользуется :)
> это переросточный и очень проблемный рантайм с кучей бестолковостейпо сравнению с чем?
> по сравнению с чем?Да почти со всем. Я знаю только 1 вещь которая в этом плане хуже - дотнет. Который суть "догнать и перегнать яву!" от микрософта. Надо сказать что это у них получилось. Рантайм получился еще жирнее и еще проблемнее. Поздравляю с почетным соседством.
>> по сравнению с чем?
> Да почти со всем.Например?
> docker-way: завершить старый, подождать (даунтайм), поднять новый.И давно haproxy отменили?
> расскажете мне, как обновить контейнер, слушающий на 80 порту, без даунтайма?
> docker-way: завершить старый, подождать (даунтайм), поднять новый.Возможно, http://www.opennet.me/opennews/art.shtml?num=42315
>> расскажете мне, как обновить контейнер, слушающий на 80 порту, без даунтайма?
>> docker-way: завершить старый, подождать (даунтайм), поднять новый.
> Возможно, http://www.opennet.me/opennews/art.shtml?num=42315и давно criu поддерживает live migration? это чисто save-restore. я выше об этом писал.
пруф: http://criu.org/Usage_scenarios: With CRIU it's possible to periodically duplicate process on another box.ничего про live-миграцию. это не оно.
>> расскажете мне, как обновить контейнер, слушающий на 80 порту, без даунтайма?
>> docker-way: завершить старый, подождать (даунтайм), поднять новый.
> Возможно, http://www.opennet.me/opennews/art.shtml?num=42315Там doom секунд на 5 на видео замирает. Да, tcp-соединение(vnc) не успевает таймаут словить. Но, где кончается то замирание и начинается даунтайм[!=0], я вас.
Они ещё где-то применяются? Паравиртуализация стала настолько дешёвой, а для изоляции - cgroups настолько выросли, что необходимость в openvz уже сильно сомнительна. Хотя, конечно, ploop - ценная вещь сама по себе, даже без OpenVZ.
видимо, поэтому опрос как бы спрашивает "ну! ну! что нам сделать, чтобы вы нас купили?!"
написать самим обертку вокруг cgroups влом ?
> написать самим обертку вокруг cgroups влом ?Посмотрите, на какой основе cgroups вообще возникли и кто их пилит, что ли...
> Посмотрите, на какой основе cgroups вообще возникли и кто их пилит, что ли...Им бы еще неплохо вовремя понять что вся эта трахoмyдия с кастомными ядрами - всех уже подутомила. Это нынче приводит к тому что OVZ многими воспринимается как геморная и obsoleted штука. Такая политика партии зарубает много применений. При том чаще всего у разработчиков и прочих заинтересованных, которым в результате все это становится вообще не надо.
Вон опенвртшники - нынче сватают докер-шмокер как один из варантов сборочной среды. На этом месте мог бы в принципе быть и OVZ. Но не будет. Потому что вкатывать какие-то кастомные ядра на машину разработчика - даром никому не надо. А OVZ сватают это как основной сценарий использования. Что безнадежно протухло по современным меркам.
> Потому что вкатывать какие-то кастомные ядра на машину разработчика
> - даром никому не надо. А OVZ сватают это как основной сценарий использования.
> Что безнадежно протухло по современным меркам.Для серверов-то протухло, здрасьте? А на десктоп и не сватали, хотя я таких людей знаю.
> Для серверов-то протухло, здрасьте? А на десктоп и не сватали, хотя
> я таких людей знаю.Ещё не протухло, но активно подтухает. С ядром от RH7 у OpenVZ'шников всё печально и уныло, релизу уже год почти, а OpenVZ так и нет. А новое ядро там с легкостью все накладные расходы на ту же паравиртуализацию окупит.
> Для серверов-то протухло, здрасьте?Да привет уж. С практической точки зрения - лучше всего когда разработчики разрабатывают в том же окружении которое на десктопе. Потом наименьшее количество проблем. А если это принципиально иная среда - там грабли обпрыгивать задолбаешься. А хуже OpenVZ в сложности обкатки на локальных окружениях у разработчиков только MS Azure какой-нибудь. Я бы не стал их поздравлять с таким соседством и сравнением.
> А на десктоп и не сватали, хотя я таких людей знаю.
Ну отлично, а я буду считать такие подходы неудобными и полагать что их вынос в obsoleted - правильно и заслуженно.
> С практической точки зрения - лучше всего когда разработчики
> разрабатывают в том же окружении которое на десктопе.Ага, а потом их гоняют по всему околотку диагнозом "pussy.exe".
> А хуже OpenVZ в сложности обкатки на локальных окружениях у разработчиков только
> MS Azure какой-нибудь. Я бы не стал их поздравлять с таким соседством и сравнением.Бред сивой кобылы в лунную ночь, стыдно должно быть.
wget http://nightly.altlinux.org/p7/permalink/altlinux-p7-server-...
qemu -enable-kvm ... -m 512M -cdrom altlinux-p7-server-ovz-latest-x86_64.iso
> Ага, а потом их гоняют по всему околотку диагнозом "pussy.exe".У микрософта как раз с этим большие проблемы. Эти упыри даже для своего ажура-абажура не смогли сделать разработчикам локальную среду где те могли бы прототип гонять. Получился столь эпичный кластерфак, что ажур-абажур с этим кастомным рантаймом наглухо не взлетел. Разрабатывать под это оказалось просто нереальным гемором. Я это видел и это был жестокий трэш и угар. Ну а вместо pussy.exe им в своем абажуре пришлось в результате разучивать что такое ubuntu.iso, чтобы у них хоть какие-то клиенты были. Что все-таки по своему улыбает, что ни говори :P.
> Бред сивой кобылы в лунную ночь, стыдно должно быть.
Ну это так, единственная сравнимая параллель (в плане вопиюще дepьмового отношения к разработчикам софта) которую я смог вспомнить.
> wget http://nightly.altlinux.org/p7/permalink/altlinux-p7-server-...
> qemu -enable-kvm ... -m 512M -cdrom altlinux-p7-server-ovz-latest-x86_64.isoЗБС решение: чтобы сбацать контейнер надо сначала запустить другую систему в полном виртуализаторе. Не, народ, с такими подходами вы стопроцентно идете в пешее эротическое путешествие. Мне _такие_ решения не нyжны даже если мне за это приплатят. Я даже не знаю как вам понятнее объяснить что такие семейства технологий должны идти на...й и быть размочены конкурентами в ноль. Так работать нельзя, люди!
>> Ага, а потом их гоняют по всему околотку диагнозом "pussy.exe".
> У микрософта как раз с этим большие проблемы.Так то же самое предлагаете и оправдываете -- тащить с десктопа на сервер то, что "привычно разработчику". Ровно с этим "доводом" некрософт и лез на серверы, помнится.
>> wget http://nightly.altlinux.org/p7/permalink/altlinux-p7-server-...
>> qemu -enable-kvm ... -m 512M -cdrom altlinux-p7-server-ovz-latest-x86_64.iso
> ЗБС решение: чтобы сбацать контейнер надоНе "нуна", а "мона".
> сначала запустить другую систему в полном виртуализаторе.
Вы спрашивали "локальную среду где те могли бы прототип гонять"? Нате, пожалста, здесь и сейчас. И это гораздо разумнее, чем тащить гитовые ядра на _все_ серверы из-за какого-то девелупера с синдромом последней версии.
Поймите, если бы Вы ровно так же незаслуженно ругали какую убунту -- тоже бы сказал, что неправы.
плюсую
опрос заполнил, убедился что главные вопросы там именно на эту тему
тока результаты опроса или я не нашел или опубликуют потомили не опубликуют
> Они ещё где-то применяются? Паравиртуализация стала настолько дешёвой, а для изоляции -
> cgroups настолько выросли, что необходимость в openvz уже сильно сомнительна. Хотя,
> конечно, ploop - ценная вещь сама по себе, даже без OpenVZ.Применяется. Во первых ещё не на столько она дешёвая стала паравиртуализация, во вторых, гибкость в управлении у OpenVZ и прочих контейнеров лучше.
> Они ещё где-то применяются?
Активно используем OpenVZ в инфраструктуре CI/CD. Практика эксплуатации показала, что на серверах с Xeon E5-2680 2.70GHz мы можем относительно комфортно запускать до 3-х LAMP-контейнеров (в которых далеко не "hello world" крутится) на ядро. В пиках бывает до 5 контейнеров на ядро, но это уже не так комфортно :) Что будет с сервером если запустить такое-же количество VM я даже представить себе боюсь.
> Активно используем OpenVZ в инфраструктуре CI/CD. Практика эксплуатации показала, что
> на серверах с Xeon E5-2680 2.70GHz мы можем относительно комфортно запускать
> до 3-х LAMP-контейнеров (в которых далеко не "hello world" крутится) на
> ядро. В пиках бывает до 5 контейнеров на ядро, но это
> уже не так комфортно :) Что будет с сервером если запустить
> такое-же количество VM я даже представить себе боюсь.Вообще, взрослые дядьки десятками виртуалки на одной хардварной ноде запускают, в || даже релизные тесты такие есть :). Но там ключевые моменты - развести на разные ноды тех, кто будет жрать IO и процессор, ну и чтобы памяти всем хватило.
Но вообще cgroups / lxc - в той же весовой категории, что неудивительно, учитывая происхождение этих самых lxc, разве что не настолько mature. Но, в принципе, некоторым уже хватает.
> Паравиртуализация стала настолько дешёвойЗапускаем KVM виртуалку с virtio. Активно грузим дисковый IO в виртуалке и смотрим, как процесс qemu отжирает 150% CPU хост системы. Ну уж нет.
> Запускаем KVM виртуалку с virtio. Активно грузим дисковый IO в виртуалке и
> смотрим, как процесс qemu отжирает 150% CPU хост системы. Ну уж
> нет.Запускаем Xen виртуалку в PV. Активно грузим дисковый IO... и понимаем, что он упёрся либо в шину, либо в сеть (если iSCSI). Ну а если у вас требуемая пропускная способность дисковой системы для одной VM такая, что способна хотя бы два гиговых линка под iSCSI нагрузить полностью - нахрена вам в таком случае виртуализация? Всё равно больше одной такой машины на типовом железе запускать смысла нет. Кстати, в случае Xen PV qemu банально выкидывается из цепочки.
> Запускаем Xen виртуалку в PV. Активно грузим дисковый IO...и получаем просадку в 20-30% по сравнению с bare metal.
>> Запускаем Xen виртуалку в PV. Активно грузим дисковый IO...
> и получаем просадку в 20-30% по сравнению с bare metal.что с зеном сделали за послетние пять лет что из 2% стало 20?
пять лет назад тоже 20 было, сам помню.говорят, квм чуть получше в плане io, но всё равно процентов 15.
у контейниризации оверхед гораздо меньше.
> пять лет назад тоже 20 было, сам помню.el5 + диски виртуалок из lvm
> пять лет назад тоже 20 было, сам помню.не было такого никогда
давай прувы или gtfo
> Ну а если у вас требуемая пропускная способность дисковой системы для одной VM такая, что способна хотя бы два гиговых линка под iSCSI нагрузить полностью - нахрена вам в таком случае виртуализация?В виртуалке всего лишь запущен emerge-webrsync
Где Centos7? Доколе??!!
> Проект OpenVZ проводит опрос среди своих пользователейсвоих системных администраторов