LXC — Linux Containers часть №9. Ограничение ресурсов

Оглавление

Этот вопрос — один из самых актуальных. Если речь идет о производственной среде, то контроль вычислительных ресурсов и их ограничение в каждом из экземпляров является очень важным. Во-многом, это залог стабильность и производительность всей инфраструктуры. Посмотрим что для этого может предоставить нам LXC.

Первое, что бросается в глаза при выполнении команд free -m и df в консоли любого экземпляра ОС так это то, что можно увидеть, а главное использовать все ресурсы хоста. По умолчанию, нет не каких ограничений.

Про память

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

lxc.cgroup.memory.limit_in_bytes = 512M. После перезагрузки контейнера, ему будет доступно, максимум 512 Мб памяти. Но, даже установив этот лимит, команда free -m выполненная в контейнере будет все так же выводить информацию о памяти хоста. Откровенно, это очень плохо и не удобно, но такова текущая ситуация. Увидеть реально используемую контейнером память, можно только на хосте, посмотрев в

/sys/fs/cgroup/memory/lxc/<имяКонтейнера>/memory.usage_in_bytes.

Как реализовано ограничение памяти? Да очень просто. Ядро начнет попросту «отстреливать» прожорливые процессы, а вам придется выяснять почему тот или иной сервис перестал работать.

Про CPU

Тут тоже все не для людей. Существует два параметра описывающих лимит процессора. Во-первых, это примитивное выделение конкретного ядра\ядер, параметром lxc.cgroup.cpuset.cpus

Предположим, что в сервере 4 ядра (0-3).

# так, можно ограничить контейнер одним, первым по счету ядром
lxc.cgroup.cpuset.cpus = 0
# так будет выделены первое и второе
lxc.cgroup.cpuset.cpus = 0,1
# а так можно задать три ядра
lxc.cgroup.cpuset.cpus = 0-2

Второй параметр определяет приоритет lxc.cgroup.cpu.shares. Например, есть два контейнера которым выделено одно и тоже ядро. Конкретнее:

# это для VM1
lxc.cgroup.cpu.shares = 512
# это для VM2 (1024 используется по умолчанию)
lxc.cgroup.cpu.shares = 1024

Это означает, что планировщик ядра, даст второму контейнеру в два раза больше процессорного времени чем первому. Пожалуй это все. Распределение на уровне понятных Mhz, в LXC пока нет.

Ограничение дискового пространства

Это пока не возможно. Единственный вариант, это использование томов LVM или суб-томов Btrfs.

Дисковый i\o

Тут тоже все лимитируется долями с помощью параметра lxc.cgroup.blkio.weight. Например:

# для VM1
lxc.cgroup.blkio.weight = 500
# для VM2 (это максимальное значение)
lxc.cgroup.blkio.weight = 1000

Это означает, что VM2 получит доступ к диску без ограничений, а VM1 соответственно, половину максимального i\o.

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