четверг, 25 марта 2010 г.

OpenVZ для самых маленьких

Решила запостить сюда нашу внутреннюю заметку, подумала, что может быть полезно для начинающих юзеров OVZ.

Общая информация


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

OpenVZ является базисом для проприетарного, улучшенного решения с профессиональной технической поддержкой: Parallels Virtuozzo Containers (PVC). Parallels является главным спонсором проекта OpenVZ, и ей принадлежат авторские права на код. Утилиты OpenVZ лицензированы, в основном, под GNU GPL v2 (или старше)

Если сильно упростить, можно считать, что:

  • Обычная, невиртуализированная система, имеет один kernel-mode (ring0), и один user-mode, в последнем процессы не имеют прямого доступа к оборудованию, таймеру, и т д, и вынуждены использовать API ядра и другие базовые утилиты/библиотеки user-mode для доступа к оборудованию и пр. привелегированным операциям требующим вмешательства ядра 
  •  Полная виртуализация запускает под хостовой ОС, в качестве user-mode процесса, виртуальную машину неподозревающую о своей виртуальности, со своими usermode и ring0 
  •  Паравиртуализация, позволяет запускать модифицированные версии гостевых ОС, не старающихся не замечать, что они работают не на настоящем железе, а виртуализированы, и использующих модифицированные фронт-энды-драйверы для доступа к оборудованию и другим интерфейсам хост-системы, позволяет добиться существенного повышения производительности
  • Гипервизор представляет из себя тонкую специализированную ОС, занимающуюся прежде всего только выделением ресурсов для гостевых систем * контейнеры в отличае от перечисленных выше технологий, представляют из себя несколько user-mode под одним kernel-mode.

Некоторые технологии, такие как OpenVZ/PVC, позволяют так же управлять некоторыми (далеко не всеми) параметрами kernel-mode отдельно для каждого контейнера

Главным преимуществом контейнеров является практически нативная(как у невиртуализированной системы "на железе") производительность, отсуствие потерь на виртуализацию из-за отсуствия переключения ядерных контекстов (так как ring0 один, шедуллер CPU, диска тоже один, но модифицированные для работы с контейнерами)

Главными недостатками является меньшая изоляция и устойчивость по сравнению с виртульными машинами (невозможно полностью исключить влияние контейнеров друг на друга, хотя в OpenVZ/PVC оно и сведено практически к минимуму), а так же невозможность решения большей части задач, требующих модификации ядра/ особых ядерных параметров. В частности, в OpenVZ контейнере нельзя запустить обычный, ядерный NFS, OpenVPN работает прямо-таки по случайному совпадению, с помощью хака, IPsec не работает, и т д.

Основные концепции

  • Хост-система называется Hardware Node, управление контейнерами и всем сервером производится именно с нее. Так же ее иногда называют CT0, VE0(нулевой контейнер), именно такое обозначение можно встретить в конфигурационных файлах OpenVZ
  • Контейнеры в технологии OpenVZ, так и называются "контейнерами"(CT, Container), а так же Virtual Enviroment'ами (VE, гостевыми окружениями)
  • Каждый контейнер имеет доступ к пулу ресурсов, причем может иметь гарантии на ресурсы, и лимиты.
  • Темплейты - шаблоны контейнеров(с предустановленным ПО), из которых контейнеры и развертываются
Существуют группа UBC ресурсов, а так же отдельные от них дисковые квоты, квоты на потребление CPU, и приоритеты i/o

Возможности OpenVZ

  • OpenVZ предоставляет менеджмент ресурсов физического сервера для каждого контейнера. Почти все ресурсы могут быть гарантированными, и негарантированными (лишние имеющиеся в наличии на ноде, и отданные в распоряжение тех контейнеров, которым позволено пользоваться такими ресурсами в рамках своего конфига). Возможны так же жесткие лимиты на большую часть ресурсов.
Наличие отдельных ресурсов для каждого контейнера придает устойчивость сервисам, а существование негарантированных ресурсов может дать производительность шаред-хостинга, так как дает возможность использовать всю мощность физического сервера под сервисы, если он простаивает.
  • Ресурсы "второго уровня": администратору OpenVZ-контейнера можно разрешить использовать собственные дисковые квоты (по-умолчанию отключено), и ставить собственные приоритеты на процессы (renice, включено всегда), номера процессов так же виртуализированы: pid процесса init внутри контейнера всегда равен одному, хотя на HardwareNode у него(как и у остальных процессов контейнера) будет другой номер
  • OpenVZ предоставляет почти полноценный сетевой стек для каждого контейнера с собственными IP-адресами, таблицами статической маршрутизации, и даже с собственными правилами iptables, которыми можно управлять из контейнера. Количество правил для контейнера является ресурсом, который может быть установлен в конфиге. Есть возможность использовать два вида сетевых интерфейсов: venet, более производительный, и veth, с незначительным оверхедом, но предоставляющий поддержку Ethernet mac-адресов для контейнеров.
Большинство технологии контейнерной виртуализации не предоставляют полноценный сетевой стек, и не обеспечивают даже половины возможностей (например, во FreeBSD jails только во FreeBSD 8 появилась поддержка более одного IP на Jail, и какие-то зачатки своего стека для контейнера, тогда как на момент написания статьи, даже FreeBSD7 еще только начинала использоваться в production некоторыми хостерами)
  • OpenVZ предоставляет возможности так называемого Checkpointing и live-migration.
    • Live-migration - миграция контейнера с одной HardwareNode на другую без выключения контейнера. Даунтайм составляет, обычно, несколько секунд. На новую HardwareNode восстанавливается дамп памяти контейнера (с запущенными процессами)
    • Checkpointing - технология, позволяющая заморозить контейнер, и восстановить его состояние из дампа памяти. Удобно, например, для создания бэкапа контейнера, интенсивно работающего с базой данных, транзакции которой не могут быть оборваны некорректно
  • OpenVZ содержит несколько "хаков", предоставляющих нетипичные, для контейнеров, возможности (близкие к виртуализации): возможность подгружать на ноду ядерные модули, и, иногда, работать с ними из контейнеров. Например, можно "пробросить" железку в контейнер, при этом есть достаточно большая вероятность, что она в ней заработает (если работает в контексте хост-системы). Может использоваться в тех случаях, когда user-mode утилиты, требуемые драйверу, программно не совместимы с другими утилитами, которые могут быть установлены на физической машине, но следует понимать, что такое решение не всегда оправдано на отвественных системах с большим числом контейнеров, так как ядро всего одно, ошибка в ядерном драйвере устройства обрушит всю HardwareNode.
Так же занимателен факт реализации работы OpenVPN внутри контейнера (видимо, понадобилось кому-то из разработчиков). Яедрный модуль при этом, понятно, один на всю ноду, а вот user-mode демонов может быть сколько угодно много, на всю ноду, и каждый из них будет считать, что работает на "настоящем" железе

UBC, User Beancounters


В группе ресурсов UBC находится большая их часть. UBC можно посмотреть из контекста ноды для каждого контейнера в файле /proc/user_beancounters, а так же в /proc/bc/VEID/resources

[root@veweb21 /]# cat /proc/user_beancounters
Version: 2.5
   uid  resource      held    maxheld  barrier      limit failcnt
 5005:  kmemsize   7430824   14454677 21055923   21377049       0
        lockedpages      0          0      256        256       0
        privvmpages  49608      65562   243200     262144       0
        shmpages      8336       8336    21504      21504       0
        dummy            0          0        0          0       0
        numproc         45         94      240        240       0
        physpages    33338      40620        0 2147483647       0
        vmguarpages      0          0   201216     204800       0
        oomguarpages 33338      40620    26112 2147483647       0
        numtcpsock       6         14      360        360       0
        numflock         1          6      188        206       0
        numpty           1          1       16         16       0
        numsiginfo       0          2      256        256       0
        tcpsndbuf    53760     156800  1720320    2703360       0
        tcprcvbuf    98304     324096  1720320    2703360       0
        othersockbuf 26880      35840  1126080    2097152       0
        dgramrcvbuf      0       8576   262144     262144       0
        numothersock    20         25      360        360       0
        dcachesize    4248      40356  3409920    3624960       0
        numfile        970       1118     9312       9312       0
        dummy            0          0        0          0       0
        dummy            0          0        0          0       0
        dummy            0          0        0          0       0
        numiptent       14         14      128        128       0
[root@veweb21 /]#


Описание ресурсов можно прочитать в официальной документации.
  • fcnt Последняя правая колонка, fcnt, это счетчик отказа в выделении ресурса. Ненулевое значение счетчика обозначает нехватку ресурса, и, как правило, нестабильную работу приложения внутри контейнера.
Решением проблемы может быть выделение большего числа ресурсов приложению, либо перенастройка приложения так, что бы оно умерило аппетиты.
  • Колонка held означает текущее значение утилизации ресурса
  • Колонка maxheld максимальное значение за все время калькуляции ресурсов для контейнера
  • Колонка barrier Обозначает максимальное значение потребления ресурса, которое, в ряде случаев, может быть превышено(если на HN есть свободные ресурсы)
  • Колонка limit Обозначает максимальное значение потребления ресурса, которое никогда не может быть превышено контейнером
UBC лимиты так же можно просмотреть, находясь внутри контейнера: cat /proc/user_beancounters
OpenVZ позволяет "мухлевать" с выделением памяти: дело в том, что память, ассигнованная приложением, практически никогда в таком объеме ему не требуется:

[root@ovz07 ~]# vzmemcheck 
Output values in %      
 LowMem  LowMem     RAM MemSwap MemSwap   Alloc   Alloc   Alloc
   util  commit    util    util  commit    util  commit   limit
  20.66  195.31   30.89   14.34  126.26   48.51  191.00  341.16

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

[root@ovz07 ~]# vzmemcheck -v
Output values in %
veid LowMem  LowMem     RAM MemSwap MemSwap   Alloc   Alloc   Alloc
       util  commit    util    util  commit    util  commit   limit
5018   0.35    5.28    0.24    0.11    1.84    0.64    2.30    4.44
5002   0.33    5.28    0.35    0.16    1.84    0.23    8.12   12.04
9074   0.54    5.28    0.38    0.18    1.84    0.77    2.30    4.44
9073   0.71    5.28    1.92    0.89    1.84    3.79    2.30    4.44
9072   0.12    3.59    0.06    0.03    1.75    0.04    2.21    4.11
9071   0.43    5.28    2.78    1.29    1.84    1.66    2.30    4.44
9058   0.42    5.28    1.27    0.59    1.84    4.05    6.40   12.04
9035   0.37    8.04    0.30    0.14    3.18    0.20    3.64    6.39
7022   0.45    5.28    0.40    0.18    1.84    0.27    2.30    4.44
7009   0.51    5.28    0.34    0.16    1.84    0.30    2.30    4.44
7008   0.76    5.28    1.03    0.48    1.84    2.46    2.30    6.16
7007   0.46    5.28    0.33    0.15    1.84    0.29    2.30   10.43
7006   0.39    5.28    0.87    0.41    1.84    2.30    2.30    4.44
7004   0.51    5.28    0.34    0.16    1.84    0.30    2.30    4.44
7003   0.47    5.28    0.33    0.15    1.84    0.30    2.30    4.44
5022   1.30   14.12    0.62    0.29    2.31    0.91    2.77   19.12
5021   1.37    8.60    1.32    0.61    2.02    4.62    2.48   12.71
5020   1.66   10.30    1.56    0.73   63.27    5.35   63.27   94.63
5017   0.16    5.28    0.13    0.06    1.84    0.09    2.30    4.44
5016   0.48    5.28    2.29    1.06    1.84    1.48    2.30    4.44
5014   0.51    5.28    0.34    0.16    1.84    0.46    2.30    4.44
5012   0.34    5.28    0.23    0.11    1.84    0.91    2.30    4.44
5011   0.58    5.28    0.52    0.24    5.43    0.35    8.12   12.53
5010   0.45    5.28    0.97    0.45    1.84    2.19    4.20    6.40
5009   0.72    5.28    1.23    0.57    1.84    0.70    4.20    6.40
5008   2.19    8.04    3.28    1.52    1.99    2.67   12.46   16.11
5007   0.41    5.28    1.00    0.46    1.84    2.72    4.20    8.12
5006   0.41    5.28    1.18    0.55    1.84    3.96    6.40   12.04
5005   2.05    8.04    4.49    2.09    1.99    3.05   12.46   16.11
5004   0.22    5.28    0.12    0.05    1.84    0.09    5.06    9.47
5003   0.47    7.22    0.31    0.14    1.94    0.89    4.30    6.51
5001   0.53    5.84    0.35    0.16    1.87    0.47    6.19   12.07
-------------------------------------------------------------------
Summary: 20.67 195.31 30.89   14.34  126.26   48.51  191.00  341.16
[root@ovz07 ~]#

В выделении памяти OVZ-ядром есть много нюансов, вероятно, главный то, что считается аллоцирования, а не реально используемая процессами в контейнере память. Это, с одной стороны, удобно, и помогает большей изоляции, но с другой минус в том, что контейнеру может быть отказано в аллоцировании памяти тогда, когда контейнер просто хочет зарезервировать для себя много ОЗУ, а реально ее не использует.

CPU


OpenVZ позволяет ставить приоритеты CPU, и лимиты CPU. Приоритеты ставятся в специальных единицах CPUUNITS, вычисляемые по специальной формуле так, что у процессоров с разной производительностью будет разное число CPUUNITS, что бы контейнер, перевезенный на новую ноду, получал такое же количество ресурсов CPU, что и раньше. То есть, cpuunints так же являются и минимально гарантированными ресурсами CPU

  • Два контейнера с вдвое отличающимися значениями cpuunits получат, при стопроцентной загрузке процессора ноды, вдвое различающееся количество процессорного времени для своих процессов
  • Внутри контейнеров можно использовать собственные приоритеты на процессы, OpenVZ использует двухуровневый планировщик CPU
  • Лимиты CPU ставятся в процентах. Удобно поставить высокое значение CPUUNITS для приложения, требующего высокой интерактивности, но малое значение CPULIMIT, что бы оно не "завалило" HardwareNode, и наоборот, для приложения не требующего высокой интерактивности, например, для контейнера, в котором в фоне компилируются rpm-пакеты, можно поставить очень маленькие CPUUNITS, но оставить высокий лимит на CPULIMIT, что бы, когда CPU ноды не загружен, он использовался для фоновой многочасовой компиляции

С ноды проверить потребление CPU можно с помощью команд:

[root@ovz07 ~]# vzcpucheck                                                                                                           
Current CPU utilization: 193130
Power of the node: 280025

Здесь Current CPU utilization - обещанные гарантии времени CPU, вы
88;аженные в CPUUNITS, а Power of the node вычисленное значение CPUUNITS в целом для ноды
А вот потребление CPU в разрезе каждого контейнера:
[root@ovz07 ~]# vzcpucheck -v
VEID            CPUUNITS
-------------------------
0               1000
5001            2500
5003            15151
5004            1302
5005            15151
5006            20000
5007            20000
5008            15151
5009            15151
5010            8064
5011            1000
5012            1000
5014            1501
5016            1501
5017            1000
5020            20000
5021            1000
5022            1000
7003            1501
7004            1501
7006            1501
7007            1501
7008            1501
7009            1501
7022            1501
9035            1000
9058            20000
9071            1000
9072            1000
9073            1000
9074            1000
5002            15151
5018            1000
Current CPU utilization: 193130
Power of the node: 280025
[root@ovz07 ~]#

Дисковые квоты


OpenVZ поддерживает двухуровневые дисковые квоты: во-первых, квота на занимаемое место, и количество дисковых инодов (файлы, директории, сокеты, и т д) на весь контейнер, и во-вторых, квоты устанавливаемые администратором OpenVZ-контейнера для пользователей и групп контейнера.
Работа с квотами внутри OpenVZ контейнера аналогична работой с квотами внутри обычной, не виртуализированной Linux-системы
Пример просмотра квот для всего контейнера:
[root@ovz07 ~]# vzquota show 5005
vzquota : (warning) Quota is running, so data reported from quota file may not reflect current values
   resource          usage       softlimit      hardlimit    grace
  1k-blocks        3305824        15048576       15153024
     inodes         154840          600000         620000
[root@ovz07 ~]#
  • softlimit - лимит, который может быть превышен,
  • hardlimit, лимит, который не может быть превышен,
  • 1k-blocks - занятое место, в блоках по 1k
  • inodes - количество занятых inodes
Очень важно, что бы файлы попадали в контейнер штатным путем, то есть, через сеть (ssh, ftp, http, и т д), иначе квота на контейнер будет считаться неверно. В случае если есть проблемы с квотой, можно заставить OpenVZ пересчитать квоту для контейнера с помощью команды: vzquota drop и перезапустить контейнер. Квота может вычисляться достаточно долго, минуты(даже десятки минут в редких случаях), оказывая существенную нагрузку на диск (особенно в случае большого числа файлов в контейнере)

I/o приоритеты


OpenVZ использует модифицированный CFQ -планировщик для выделения отдельных "весов", приоритетов по работе с диском для каждого контейнера.

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

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

Следует иметь ввиду, что OpenVZ не лучшее решение для виртуализации серверов с серьезной дисковой нагрузкой.

Приоритет может иметь значения от 0 до 7.

vzctl set 101 --ioprio 0 --save

vzctl set 101 --ioprio 7 --save

Первая команда установит минимальный приоритет для контейнера, а вторая максимальный.

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

Конфигурационные файлы


Главный конфигурационный файл OpenVZ: /etc/sysconfig/vz В файле описываются общие (без применения к отдельным контейнерам) настройки среды OpenVZ/PVC

Конфигурационные файлы контейнеров находятся тут:
/etc/sysconfig/vz-scripts/
Например, 5014.conf - параметры контенера 5014,
5011.start - скрипт, выполняющийся после старта контейнера в контексте контейнера
5018.mount - скрипт, выполняющийся при старте контейнера (когда он переходит в состояние mounted) в контексте ноды
ve-vps256M.conf-sample - набор типовых параметров для контейнера (тарифный план)
Пример конфига контейнера:
ONBOOT="yes"
# UBC parameters (in form of barrier:limit)
KMEMSIZE="21055923:21377049"               
LOCKEDPAGES="256:256"                      
PRIVVMPAGES="243200:262144"                
SHMPAGES="21504:21504"                     
NUMPROC="240:240"                          
PHYSPAGES="0:2147483647"
VMGUARPAGES="201216:204800"
OOMGUARPAGES="26112:2147483647"
NUMTCPSOCK="360:360"
NUMFLOCK="188:206"
NUMPTY="16:16"
NUMSIGINFO="256:256"
TCPSNDBUF="1720320:2703360"
TCPRCVBUF="1720320:2703360"
OTHERSOCKBUF="1126080:2097152"
DGRAMRCVBUF="262144:262144"
NUMOTHERSOCK="360:360"
DCACHESIZE="3409920:3624960"
NUMFILE="9312:9312"
AVNUMPROC="180:180"
NUMIPTENT="128:128"

# Disk quota parameters (in form of softlimit:hardlimit)
DISKSPACE="15048576:15153024"
DISKINODES="600000:620000"
QUOTATIME="0"

# CPU fair sheduler parameter
CPUUNITS="15000"
CPULIMIT="65"

VE_ROOT="/vz/root/$VEID"
VE_PRIVATE="/vz/private/$VEID"
OSTEMPLATE="centos-5-i386-webserver"
ORIGIN_SAMPLE="vps.basic"
HOSTNAME="lamp.loc"
IP_ADDRESS="10.0.10.5"
NAMESERVER="217.10.32.4 10.0.5.51"
NETIF="ifname=eth0,mac=00:18:51:1D:90:C3,host_ifname=veth5005.0,host_mac=00:18:51:7D:4D:E0"

# Network customization section
CONFIG_CUSTOMIZED="yes"
VETH_IP_ADDRESS="10.0.5.110/24"
BRIDGEDEV="br0"

Темплейты и другая, связанная с ними информация.


В Virtuozzo так называемые EZtemplates представляют из себя "особую" rpm, в которой хранится список rpm (или deb) пакетов контейнера, что позволяет, во-первых, развертывать контейнер из свежего ПО, а, во-вторых, обновлять ПО внутри контейнера.

В OpenVZ (а так же в Virtuozzo в слегка улучшенном виде) так же доступны более "простые" темплейты, которые представляют из себя затаренную корневую систему инсталляции какого-либо дистрибутива, минус некоторые системные файлы. Из данного тарболла, так называемого "private cache", и производится развертывание новых контейнеров.
В директории /vz/template/cache/ и находятся template cache разных систем:
[root@ovz-test ~]# ls /vz/template/cache/
centos-4-x86.tar.gz           centos-5-x86.tar.gz
fedora-12-x86.tar.gz          ubuntu-9.04-x86.tar.gz
centos-5-i386-default.tar.gz  debian-5.0-x86.tar.gz  
suse-11.1-x86.tar.gz
[root@ovz-test ~]#

Так же, существует набор скриптов, предоставляющих менеджмент сети и других параметров, специфичных для дистрибутива:

ls /etc/vz/dists/
altlinux-2.4.conf             default
owl.conf                      sles-9.conf
altlinux-3.0.conf             distribution.conf-template
redhat-7.0.conf               sles.conf
altlinux-4.0.conf             fedora-7.conf
redhat-7.1.conf               suse-7.3.conf
altlinux.conf                 fedora-8.conf
redhat-7.2.conf               suse-8.0.conf
arch-0.7.conf                 fedora-9.conf
redhat-7.3.conf               suse-8.1.conf
arch-0.8.conf                 fedora-core-1.conf
redhat-8.0.conf               suse-8.2.conf
arch.conf                     fedora-core-2.conf
redhat-9.conf                 suse-9.0.conf
centos-3.conf                 fedora-core-3.conf
redhat.conf                   suse-9.1.conf
centos-4.conf                 fedora-core-4.conf
rhel-3.conf                   suse-9.2.conf
centos-5-i386-webserver.conf  fedora-core-5.conf
rhel-4.conf                   suse-9.3.conf
centos.conf                   fedora-core-6.conf
scripts/                      suse.conf
centoswebserver-5-x86.conf    fedora-core-7.conf
slackware-10.0.conf           ubuntu-5.1.conf
debian-3.0.conf               fedora-core.conf
slackware-10.1.conf           ubuntu.conf
debian-3.1.conf               gentoo.conf
slackware-9.0.conf            debian-4.0.conf
mandrake.conf                 slackware-9.1.conf
debian.conf                   opensuse.conf
slackware.conf

OpenVZ узнает о том, что, например, к контейнеру нужно применить набор правил gentoo.conf, если template cache называется gentoo-XXXXXX

Для openvz ранее использовались утилиты vzyum и vzrpm для создания и обновления private cache шаблонов из пакетов vztmpl, но их развитие остановилось, и сейчас поддерживаются только очень старые Fedora, CentOS4, и CentOS5 (через vztmpl шаблон от коммюнити)

Существует полуофициальный проект vzpkg2 для возрождения данного функционала для современных контейнеров, добавлена поддержка Debian-based систем (Debian, Ubuntu).

Статус проекта и его будущее не до конца ясно. Вот ссылка на страницу в официальной вики openvz: http://wiki.openvz.org/Install_vzpkg2_and_pkg-cacher

Официально проектом OpenVZ сейчас предоставляются только template cache свежих систем, и "поддерживаются" vztmpl пакеты для давно умерших, по большей части, дистрибутивов, из которых имеет актуальность разве что CentOS4

Так как контейнеры крутятся на хоть и "старом" RHEL-ядре, теоретически возможны какие-либо проблемы с очень свежим софтом и системными утилитами в свежих дистрибутивах, но, благодаря регулярному бэкпортированию фич последних ядер в RHEL-ядра, такая ситуация возникает редко.

Менее месяца назад(от момента написания статьи) возникла угроза того, что под OpenVZ не будет работать следующий LTS Ubuntu, и Debian 6 (сломана поддержка udev) В прошлый раз такая проблема возникла с Fedora10, шаблон которой появился только почти одновременно с Fedora11.

Можно так же создавать application шаблоны с преднастроенными системами, они должны называться, например, debian-5.0-x86-webserver.tar.gz, fedora-12-x86-plesk.tar.gz, и т д, что бы скрипты openvz правильно конфигурировали контейнер, созданный из темплейта операционной системы. Таким шаблоном может быть просто настроенный и затаренный vps-сервер

Другая информация


Так называемая "приватная" область контейнера находится в директории /vz/private/. Это корневая файловая система контейнера. Когда контейнер находится в состоянии running и mounted, она монтируется в директорию /vz/root/. В случае, если нужно срочно перекинуть файл с ноды в контейнер, его нужно поместить в директорию

/vz/root/VEID/PATH-в-контейнере

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

В PVC в /vz/private/ находятся лишь симлинки на темплейты, установленные на ноде, и файлы темплейтов, которые были изменены в контейнере, а так же созданные в нем самом файлы. После перехода контейнера в состояние running или mounted эти файлы вместе с симлинками монтируются в /vz/root/. Данная технология называется VZFS. и является одним из главных преимуществ Virtuozzo перед OpenVZ, так как позволяет резко сократить потребление ОЗУ и места на диске.

Базовые команды

  • vzctl enter veid - "войти" в контейнер с номером veid
  • vzctl restart veid - перезапустить контейнер veid
  • vzlist - получить список запущенных контейнеров
  • vzlist -a получить список всех контейнеров (во всех состояниях, не только запущенных)
  • vzlist veid то же самое для одного контейнера
  • vzctl stop veid --fast экстренно, с максимальной скоростью, остановит контейнер veid. Можно использовать, если контейнер является источником каких-то проблем. Чревато сбоем в подсчете квоты контейнера.
  • vztl stop veid - то же самое, что и предыдущая команда.
  • vzps aux -E veid - аналог ps aux, но только для процессов контейнера veid
  • vzpid pid - узнать, какому контейнеру принадлежит процесс с PID pid

Ссылки

http://wiki.openvz.org/Main_Page - Wiki OpenVZ, официальная документация
http://www.parallels.com/ru/products/pvc45/ - Обзор Parallels Virtuozzo Containers на сайте Parallels
http://ru.wikipedia.org/wiki/OpenVZ Статья в русской wikipedia. Я согласна не со всеми выводами и тезисами (как ругательными, так и хвалебными)

14 комментариев:

pavel.odintsov комментирует...

Супер статья, спасибо! Про /etc/vz/dists не знал :)

Кстати, а на тему повышения плотности размещения за счет аналогов cow/vzfs, что есть в виртуоззе не думали? Ведь очень дельная фишка-то.

sHaggY_caT комментирует...

vzfs, увы, только в Virtuozzo, в OpenVZ ничего такого нет.

Зато есть LXC, но он еще сырой...

pavel.odintsov комментирует...

Но всегда можно извратится и сделать аналог на коленке с aufs/aufs2 / uniofs / uniofs2. Только вот пока оно сегфолтица зараза :(

sHaggY_caT комментирует...

Интересно...

Еще интереснее, имхо, "оживить" vzpkg2... Таки адекватный темплейт-менеджмент очень сильный плюс PVC

pavel.odintsov комментирует...

Вобщем, у меня также есть интерес в данном начинании, можно скооперироваться :) Контактами поделитесь?

sHaggY_caT комментирует...

Вот: inbox [at] shaggy-cat [dot[ ru

Rojer комментирует...

Мощно написано. Очень содержательно, четко и профессионально. Зачет!

PS: Пока что у Вас наиболее полный для понимания описательный текст на тему OpenVZ для новичков на Русском языке, из того что я нашел мимолетом.

С уважением,

Rojer комментирует...

Чувствуется глубина понимания и доскональность проработки темы)))

sHaggY_caT комментирует...

[b]2Rojer [/b]

Спасибо, еще хорошо написано по-русски в wikipedia

>Чувствуется глубина понимания и >доскональность проработки темы)))

Просто работала с PVC на очень большой инсталляции (>100 физических нод), и сейчас используем OVZ у нескольких клиентов.
Обычно пишут о том, что знают, любят, и ненавидят (иногда) одновременно.

Надо бы еще о PVC как-нибудь написать, тем более что у нас один заказчик, (тьфу-тьфу, что бы не сглазить) на инсталляцию PVC около 15 серверов объявился...

latrommi комментирует...

Очень круто! Спасибо!
Заочно зауважал ;)

sHaggY_caT комментирует...

Вы мне льстите :)

Studiosum комментирует...

Вы случайно не знаете внутреннего устройства PVC for W2k3 OS-template? Либо не сталкивались ли с чем-либо позволяющим уменьшить время старта контейнера?

sHaggY_caT комментирует...

Нет, что именно туда натолкали, не знаю(мне ближе Linux-Virtuozzo), но рецепт, я думаю, самый универсальный, это скорость дисковой подсистемы: просто поставьте, если есть возможность, более мощный контроллер, больше шпиндилей, выкиньте SATA-диски, если такие используются, ну и raid10 рулит, или вообще какая-нибудь СХД с raid60, да и количество сервисов, не смотря на то, что память шарится у сервисов из темплейтов, при старте контейнера, имеет смысл уменьшать.

Tylkas комментирует...

гОдно, спасибо