Боюсь вас разбудить, но Docker и LXC именно наши технологии и используют — те, что мы влили в ванильное ядро (network namespace, pid namespace, IPC namespace, разные улучшения для cgroups и так далее — всего около 2000 патчей).
В целом довольно неплохо, за исключением того, что создаётся впечатление, что контейнеры (они же VPS, «виртуализация на уровне ОС») — это такая недовиртуализация, самая простая и самая ограниченная. На самом деле это другая виртуализация, по сути ортогональная виртуальным машинам, и у неё есть свои достоинства и недостатки.
Из достоинств в инфографике упомянута высокая производительность, но совсем не упомянута не менее важная характеристика — density, то есть плотность размещения. На машине, где можно поднять 4 VMки, можно поднять 6 или больше точно таких же VPSок. В отличие от хостера, для пользователя VPS это напрямую, конечно, не важно, но важно косвенно, так как это положительно отражается на цене. Именно поэтому контейнеры так популярны у хостеров.
Интересно также сравнение VPS и выделенного сервера. Там некорректно указано, что VPS имеет меньшую производительность. Разница между этими вариантами укладывается в погрешность измерений (я имею в виду, когда VPS на машине единственный). Да, у VPS есть небольшие накладные расходы на дополнительный контроль ресурсов, но они настолько невелики, что замучаешься мерять. А как написано, это примерно в стиле «автомобиль с кондиционером имеет повышенный расход топлива».
Кроме того, я много раз встречал именно такой вариант — один VPS на машине. Несмотря на кажущуюся с первого взгляда быссмысленность такого подхода, у него есть масса преимуществ:
1. VPS не зависит от железа, его можно запускать на машинах с разным железом (важна только архитектура)
2. VPS можно «вживую» мигрировать с машины на машину, без остановки приложений.
3. VPS можно динамически лимитировать по различным параметрам. Например, посмотреть, как поведёт себя ваш сервер на менее мощном железе, скажем, ограничить VPS двумя ядрами и 4 Гб памяти. На обычной машине как минимум придётся перегружать систему и давать параметры ядру.
4. Если VPS совсем упадёт, доступ к хост-системе всё ещё остаётся. Что-то вроде бесплатной удалённой консоли, которая всегда работает.
5. VPS быстро деплоится.
Ну и пара маленьких замечаний:
1. VPN сервер вполне поднимается под OpenVZ, нужно лишь разрешить tun/tap внутри контейнера (есть провайдеры, которые делают это по умолчанию, но есть и такие, у которых не допросишься).
2. Не знаю, что имелось в виду под словом «телефония», но слышал, что как раз телефонию можно запускать только в контейнере — у VMок слишком большие задержки, для голоса это губительно. Это как раз тот пример, когда VPS лучше, чем VM.
[nfs] NFSv4 support inside a CT has been added/corrected/enhanced, plus online migration of such CTs is supported now (PSBM-17798, PSBM-17795)
NOTE: NFSv4 inside CT is currently disabled by default, can be enabled via nfs4_ct_enable sysctl on the HN.
«Со стороны пользователя» — это значит «внутри контейнера»? Если так, то при использовании OpenVZ на ploop dd if=/dev/sda1 of=/backup.img изнутри контейнера вы сделать сможете (только девайс будет называться /dev/ploopNNNp1), но проблема в том, что /backup.img будет лежать на том же девайсе.
Поэтому бекап нужно или лить сразу в сеть, или (что совсем правильно) делать снаружи, с хост системы (для чего провайдер даёт какой-нибудь интерфейс, а вообще нормальные провайдеры делают бекап сами и по вашему запросу его восстанавливают полностью или частично).
По поводу бекапа на openvz в целом. Если не использовать ploop (файловая система в файле), то с точки зрения хоста контейнер — это просто каталог (какой-нибудь /vz/private/12345), его и надо бекапить. Если использовать ploop, то можно сделать очень изящные инкрементальные бекапы на блочном уровне с использованием ploop snapshots. Кое-что на эту тему тут openvz.org/Ploop
«Централизованное хранилище» — не совсем корректный термин. Имеется в виду не NFS или там какой-нибудь SAN/NAS, а кластерная распределённая файловая система Parallels Cloud Storage, которая входит в состав Parallels Cloud Server. Её смысл вкратце такой — дисковое пространство всех нод сливается в один кластер, на котором и лежат контейнеры. Там, конечно, есть и избыточность, подобная RAID-ам, и локальность данных, и (что особенно важно) высокая скорость. Можно посмотреть доклад Кирилла Коротаева на YAC2012 — video.yandex.ru/users/ya-events/view/813/user-tag/yac%202012/
Так же, не знаю, поправили или нет, 1 виртуалка в openvz может полностью загрузить хост ноду.
В OpenVZ довольно грамотный CPU scheduler. При этом, если CPU limits не выставлены и больше никто ничего не делает, то почему бы и не полностью загрузить хост? Если хотите организовать вариант «собака на сене» (пусть лучше CPU будет простаивать, но виртуалке не давать больше N%) — пожалуйста, используйте CPU limits. В противном случае есть cpu units, когда у каждого контейнера (и у хоста) есть свой вес, и шедалер раздаёт всем кванты пропорционально их весам. Можно, конечно, использовать и units, и limits, плюс к тому vcpu (ограничение по кол-ву процессорных ядер) и cpu affinity (привязка конкретных контейнеров к конкретным ядрам). Мне кажется, это практически все варианты покрывает. Или вы что-то другое имели в виду?
$ cd git/linux
$ git pull
$ git log --format=oneline --author='@openvz.org|@parallels.com|@sw.ru|@swsoft.com|@sw.com.sg|kuznet@|gorcunov@' -E | wc -l
2739
Ваш К.О.
Ваш К.О.
Из достоинств в инфографике упомянута высокая производительность, но совсем не упомянута не менее важная характеристика — density, то есть плотность размещения. На машине, где можно поднять 4 VMки, можно поднять 6 или больше точно таких же VPSок. В отличие от хостера, для пользователя VPS это напрямую, конечно, не важно, но важно косвенно, так как это положительно отражается на цене. Именно поэтому контейнеры так популярны у хостеров.
Интересно также сравнение VPS и выделенного сервера. Там некорректно указано, что VPS имеет меньшую производительность. Разница между этими вариантами укладывается в погрешность измерений (я имею в виду, когда VPS на машине единственный). Да, у VPS есть небольшие накладные расходы на дополнительный контроль ресурсов, но они настолько невелики, что замучаешься мерять. А как написано, это примерно в стиле «автомобиль с кондиционером имеет повышенный расход топлива».
Кроме того, я много раз встречал именно такой вариант — один VPS на машине. Несмотря на кажущуюся с первого взгляда быссмысленность такого подхода, у него есть масса преимуществ:
1. VPS не зависит от железа, его можно запускать на машинах с разным железом (важна только архитектура)
2. VPS можно «вживую» мигрировать с машины на машину, без остановки приложений.
3. VPS можно динамически лимитировать по различным параметрам. Например, посмотреть, как поведёт себя ваш сервер на менее мощном железе, скажем, ограничить VPS двумя ядрами и 4 Гб памяти. На обычной машине как минимум придётся перегружать систему и давать параметры ядру.
4. Если VPS совсем упадёт, доступ к хост-системе всё ещё остаётся. Что-то вроде бесплатной удалённой консоли, которая всегда работает.
5. VPS быстро деплоится.
Ну и пара маленьких замечаний:
1. VPN сервер вполне поднимается под OpenVZ, нужно лишь разрешить tun/tap внутри контейнера (есть провайдеры, которые делают это по умолчанию, но есть и такие, у которых не допросишься).
2. Не знаю, что имелось в виду под словом «телефония», но слышал, что как раз телефонию можно запускать только в контейнере — у VMок слишком большие задержки, для голоса это губительно. Это как раз тот пример, когда VPS лучше, чем VM.
NFSv4 для контейнера уже есть, но выключена по дефолту, потому что недотестирована. From openvz.org/Download/kernel/rhel6-testing/042stab078.7/changes:
Почему «к сожалению»? Каталог, в нём файлы, берите и делайте бекап, хоть таром, хоть рсинком.
Чтобы создать ploop контейнер:
Чтобы всегда по умолчанию создавались ploop контейнеры, нужно прописать
VE_LAYOUT=ploopв /etc/vz/vz.confплюс ещё nfs3 (и nfs4 — в тестировании)
Да, как обычно, надо лишь дать доступ к девайсу:
Поэтому бекап нужно или лить сразу в сеть, или (что совсем правильно) делать снаружи, с хост системы (для чего провайдер даёт какой-нибудь интерфейс, а вообще нормальные провайдеры делают бекап сами и по вашему запросу его восстанавливают полностью или частично).
По поводу бекапа на openvz в целом. Если не использовать ploop (файловая система в файле), то с точки зрения хоста контейнер — это просто каталог (какой-нибудь /vz/private/12345), его и надо бекапить. Если использовать ploop, то можно сделать очень изящные инкрементальные бекапы на блочном уровне с использованием ploop snapshots. Кое-что на эту тему тут openvz.org/Ploop
В OpenVZ довольно грамотный CPU scheduler. При этом, если CPU limits не выставлены и больше никто ничего не делает, то почему бы и не полностью загрузить хост? Если хотите организовать вариант «собака на сене» (пусть лучше CPU будет простаивать, но виртуалке не давать больше N%) — пожалуйста, используйте CPU limits. В противном случае есть cpu units, когда у каждого контейнера (и у хоста) есть свой вес, и шедалер раздаёт всем кванты пропорционально их весам. Можно, конечно, использовать и units, и limits, плюс к тому vcpu (ограничение по кол-ву процессорных ядер) и cpu affinity (привязка конкретных контейнеров к конкретным ядрам). Мне кажется, это практически все варианты покрывает. Или вы что-то другое имели в виду?