• Virtuozzo переходит на открытую модель разработки
    +1
    Так мы тоже умеем: openvz.org/Vzctl_for_upstream_kernel
  • Virtuozzo переходит на открытую модель разработки
    +1
    пардон, около 3000
  • Virtuozzo переходит на открытую модель разработки
    +2
    Не боимся, у нас уже около 3000 коммитов в ядро.

    $ 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

    Ваш К.О.
  • Virtuozzo переходит на открытую модель разработки
    +6
    Боюсь вас разбудить, но Docker и LXC именно наши технологии и используют — те, что мы влили в ванильное ядро (network namespace, pid namespace, IPC namespace, разные улучшения для cgroups и так далее — всего около 2000 патчей).

    Ваш К.О.
  • Что такое VPS и с чем его едят – инфографика о виртуальных серверах
    +2
    В целом довольно неплохо, за исключением того, что создаётся впечатление, что контейнеры (они же 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.
  • FastVPS: Как мы меняли платформы виртуализации
    0
    Так, я попутал поддержку NFSv4 внутри контейнера и для ploop. Ploop, если мне опять не изменяет память, работает поверх nfs — 3 или 4.

    NFSv4 для контейнера уже есть, но выключена по дефолту, потому что недотестирована. From openvz.org/Download/kernel/rhel6-testing/042stab078.7/changes:
    [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.

  • FastVPS: Как мы меняли платформы виртуализации
    0
    Впервые про такое слышу. Если не трудно, ткните меня носом в багзиллу.
  • FastVPS: Как мы меняли платформы виртуализации
    0
    К сожалению у меня это именно каталог:


    Почему «к сожалению»? Каталог, в нём файлы, берите и делайте бекап, хоть таром, хоть рсинком.

    Чтобы создать ploop контейнер:

    # yum install ploop
    # vzctl create 12345 --layout ploop
    


    Чтобы всегда по умолчанию создавались ploop контейнеры, нужно прописать VE_LAYOUT=ploop в /etc/vz/vz.conf
  • FastVPS: Как мы меняли платформы виртуализации
    0
    На какой файловой системе могут размещаться образы виртуальных машин? Гарантированно поддерживаются ext4 и Parallels Storage,


    плюс ещё nfs3 (и nfs4 — в тестировании)
  • FastVPS: Как мы меняли платформы виртуализации
    0
    а реально ли из контейнера получить доступ на чтение блочного имаджа или это на грани фантастики?


    Да, как обычно, надо лишь дать доступ к девайсу:

    # vzctl set 1011 --devnodes ploop53835p1:rw --save
    Setting devices
    CT configuration saved to /etc/vz/conf/1011.conf
    
    # vzctl enter 1011
    entered into CT 1011
    
    # file /dev/ploop53835p1
    /dev/ploop53835p1: block special
    
    # dd if=/dev/ploop53835p1 of=/file bs=1M count=10
    10+0 records in
    10+0 records out
    10485760 bytes (10 MB) copied, 0.105055 s, 99.8 MB/s
    
    # file /file
    /file: Linux rev 1.0 ext4 filesystem data, UUID=9b82bff8-c625-4c63-b550-9efe561cf3e9 (needs journal recovery) (extents) (large files) (huge files)
    
  • FastVPS: Как мы меняли платформы виртуализации
    +1
    «Со стороны пользователя» — это значит «внутри контейнера»? Если так, то при использовании OpenVZ на ploop dd if=/dev/sda1 of=/backup.img изнутри контейнера вы сделать сможете (только девайс будет называться /dev/ploopNNNp1), но проблема в том, что /backup.img будет лежать на том же девайсе.

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

    По поводу бекапа на openvz в целом. Если не использовать ploop (файловая система в файле), то с точки зрения хоста контейнер — это просто каталог (какой-нибудь /vz/private/12345), его и надо бекапить. Если использовать ploop, то можно сделать очень изящные инкрементальные бекапы на блочном уровне с использованием ploop snapshots. Кое-что на эту тему тут openvz.org/Ploop
  • FastVPS: Как мы меняли платформы виртуализации
    +1
    «Централизованное хранилище» — не совсем корректный термин. Имеется в виду не NFS или там какой-нибудь SAN/NAS, а кластерная распределённая файловая система Parallels Cloud Storage, которая входит в состав Parallels Cloud Server. Её смысл вкратце такой — дисковое пространство всех нод сливается в один кластер, на котором и лежат контейнеры. Там, конечно, есть и избыточность, подобная RAID-ам, и локальность данных, и (что особенно важно) высокая скорость. Можно посмотреть доклад Кирилла Коротаева на YAC2012 — video.yandex.ru/users/ya-events/view/813/user-tag/yac%202012/
  • FastVPS: Как мы меняли платформы виртуализации
    +2
    Так же, не знаю, поправили или нет, 1 виртуалка в openvz может полностью загрузить хост ноду.


    В OpenVZ довольно грамотный CPU scheduler. При этом, если CPU limits не выставлены и больше никто ничего не делает, то почему бы и не полностью загрузить хост? Если хотите организовать вариант «собака на сене» (пусть лучше CPU будет простаивать, но виртуалке не давать больше N%) — пожалуйста, используйте CPU limits. В противном случае есть cpu units, когда у каждого контейнера (и у хоста) есть свой вес, и шедалер раздаёт всем кванты пропорционально их весам. Можно, конечно, использовать и units, и limits, плюс к тому vcpu (ограничение по кол-ву процессорных ядер) и cpu affinity (привязка конкретных контейнеров к конкретным ядрам). Мне кажется, это практически все варианты покрывает. Или вы что-то другое имели в виду?