Linux изоляция, где использовать?

Question

[Danil Gaisin]

Добрый день.
Сложилась такая ситуация. При разработке панели-управления игровыми серверами, нужно ограничить ресурсы каждому новому игровому серверу(ram, cpu, disk).
Для решение проблемы смотрел в сторону Lxc, но не очень понятен принцип работы.
Мне для каждого игрового сервера нужно создать новый контейнер?
Или же имеется другие аналоги? для решение моей задачи?
Буду благодарен за вашу помощь!

Comments

[sim3x]

Для ограничения ресурсов нужно юзать просто https://en.wikipedia.org/wiki/Cgroups
Но именно ресурсы вас должны волновать меньше всего
Вас должна волновать изоляция с точки зрения безопасности
И вот тут по дефолту все плохо и требует настройки

Answer 1

[uvelichitel]

Механизмы изоляции в порядке возрастания уровня абстракции и соответственно удобства пользования
namespaces - в сущности команда chroot
control groups - русский https://habr.com/ru/company/selectel/blog/303190/ eng https://wiki.archlinux.org/index.php/cgroups docs https://www.kernel.org/doc/Documentation/cgroup-v2.txt
lxc - набор инструментов для удобного описания политик namespace и cgroups
lxd - надстройка над lxc дающая удобный и понятный интерфейс с одной консольной командой lxc с множеством ключей, например
lxc config set container1 limits.memory 512M
docker - надстройка над lxc предназначенная для удобной контейнеризации одного приложения, а не полноценной OS в отличии от lxd
На FreeBSD такое реализовано механизмами jail, bhyve которые вроде и лучше но в них редко кто умеет в силу малой распространенности FreeBSD.

Answer 2

[Sanes]

LXC сильно ограничен, но может подойти. Пробуйте развернуть сервер в контейнере и лучше в LXD (там есть rest-api).
Если будут проблемы, следующим шагом я бы пробовал на OpenVZ/Virtuozzo.
И уже потом виртуализацию на уровне железа (KVM/Vmware/etc.).

Comments

[Danil Gaisin]

Спасибо за рекомендации, буду копать в эту сторону, а как дальнейшем будет возможно обращаться этому созданному контейнеру? раньше я просто создавал пользователя в систему Linux, и подключался к нему, что бы отправлять различные команды.

[Sanes]

Danil Gaisin, я тут делал заметки для себя, напиши в чат, где-то были классы для Laravel

Answer 3

[Mysterion]

Достаточно chroot'a. Именно его и используют для таких задач, если просто нужно изолировать процессы.

Comments

[Борис Сёмов]

Сhroot не имеет возможности ограничения cpu/ram/disk, которое хочет автор вопроса... Ну и для таких задач, конечно используют контейнеры, а не chroot.

[Mysterion]

Борис Сёмов, забавно как Вы говорите, что chroot недостаточно для целей автора, а сами советуете LXC, видимо, не понимая, что LXC - это обертка над chroot и cgroup.
chroot и chroup дают возможность полностью изолировать процесс и ограничивать ресурсы.
От себя могу Danil Gaisin порекомендовать не ограничивать % утилизации ядер для процессов игровых серверов, несмотря на то, что делаете панель, а не хостинг. Процессор можно ограничивать по количеству ядер тем же taskset, а одно ядро ограничивать в % нет никакого смысла.

[Борис Сёмов]

Mysterion,
Не над chroot, а на cgroups и namespaces.
Но так-то вы правы, в принципе, можно с помощью cgroups управлять любым процессом, в частности, в chroot. Так например реализовано systemd ограничение ресурсов.

Но автору, ведь, нужно и изоляции же, и управления ресурсами. А то бы и Systemd можно было бы ограничиться. И LXC тут некая минимальная абстракция, которая позволит это реализовать.

а одно ядро ограничивать в % нет никакого смысла.

Почему? Это вопрос даже не технический, а модели продажи ресурсов. Если надо продать больше кусочков сервера, чем у него ядер это придётся делать.

[Mysterion]

Борис Сёмов,

Почему? Это вопрос даже не технический, а модели продажи ресурсов. Если надо продать больше кусочков сервера, чем у него ядер это придётся делать.

Потому что в контексте игровых серверов это нанесет вред тому, кто на этом хотел заработать.

[Борис Сёмов]

Mysterion, Какое-то странное утверждение, если его не пояснить...

[Mysterion]

Борис Сёмов,
Никто не будет платить за сервер, которому урезано ядро. Урежешь cputime - игровой сервер просто будет зависать. Или не ограничивать вообще или просто оверселлить. На железку с 12-24 ядрами можно вполне вешать серверов x1.5.

[Борис Сёмов]

С чего бы ему вдруг зависать? Это утверждение просто не верно.
У серверов какой-то определённой игры, теоретически, может быть какая-нибудь проблема с сетевым кодом и лагом при превышении нагрузки по cpu, например, я такое видел даже. Но это совершенно не какая-то проблема игровых серверов в целом. Всё с ними будет нормально.

[Mysterion]

Борис Сёмов, у нас на хостинге больше 3 тысяч игровых серверов крутится.
Хоть ТС и не спрашивал стоит так делать или нет. Я уже вижу такую панель как продукт для хостингов, которые не смогли. Такой "бизнес" не выживает. Такая модель для аудитории этой услуги не подходит, они не будут платить за увеличение допустимой нагрузки на процессор до условных 100%.
Уйдут на другой хостинг.

[Борис Сёмов]

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

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

[Mysterion]

Борис Сёмов, поэтому я и сказал, что напишу немного не о том, о чем спрашивал ТС.

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

По факту игровой сервер будет гораздо лучше себя чувствовать без ограничений на cputime и с оверселлингом на многопроцессорных конфигурациях.
А когда речь идет о продаже гарантированных ядер, встает вопрос - а при чем тут ограничение %?
Я изначально посоветовал не лимитировать одно ядро. В контексте разделения гарантированных ресурсов и изоляции ядер все иначе.

Answer 4

[Борис Сёмов]

Выбор инструмента верный, но если вам не очень понятен принцип работы LXC, то вам надо либо читать документацию, либо отказаться от задачи, но уж точно не писать такой вопрос на тостере. =) Парой фраз в ответе на вопрос вам никто не сможет помочь разобраться в довольно сложной теме.

А так, да - создавать для каждого инстанса отдельный контейнер, конечно.

На самом деле, и обёрток для управления контейнерами немало, но вам для решения вашей задачи LXC в общем-то вполне достаточно, подниматься на уровни выше и использовать более сложные обёртки над теми же механизмами смысла не много.

Вообще, вам надо почитать собственно о том, чем вы будете управлять, а именно о namespaces и cgroups прежде всего. Возможно, это поставит для вас всё на свои места...

Answer 5

[pfg21]

попробуй поиграться с ограничениями юнита в systemd.
ограничение по использованию процессора, памяти и дисков в нем есть встроенные.
в памятках есть пара старых статеек 0pointer.de/blog/projects/resources.html vladimir-stupin.blogspot.com/2013/03/systemd-3.html
ну и ман https://www.freedesktop.org/software/systemd/man/s...

Comments

[Борис Сёмов]

Как-то опасно запускать отдельные инстансы игровых серверов без какого-то слоя изоляции-то...