forum.lissyara.su

Сейчас у jail-ов нет дисковых квот.
Кто то решает эту проблему созданием отдельных дисков md, zfs, но это вынужденное решение и у него есть минусы.
Например невозможность менять размер дисков на лету.
Нужно обсудить возможные варианты реализации дисковых квот в UFS.

Есть предложение взять за основу пользовательские квоты.
UID и GID есть в inode, и соответсвенно всегда доступны.
Однако никакой информации о jail-ах в файловой системе нет и это правильно.
Jail вообще временная сущность .
Вся дисковая активность jail ограничена его корневой директорией.

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

Таким образом получаются временные квоты, которые можно менять в во время работы jail-а.

Хочется услышать за и против.
Может быть есть другие предложения?

пустая в общем-то клетка...
система не в простое - работает... =====
я к чему - накладно очень...
насколько я знаю, в атрибутах файлов UFS есть зарезервированные биты вроде...
может пора их заюзать подо что-то?

lissyara писал(а): я к чему - накладно очень...
насколько я знаю, в атрибутах файлов UFS есть зарезервированные биты вроде...
может пора их заюзать подо что-то?

Да, накладно.
Да и вообще, похоже на костыль.
Как минимум есть следующие проблемы.
1. Посчет при старте jail-а.
2. Если процесс в родительской системе записывает данные в каталого jail-а, мы не узнаем об этом. Следовательно несоответсвие реального места занимаемого каталогом и использованием диска jail-ом, и тому подобное.
У этих проблем, общий корень. Само понятие jail-а существует только во время его работы, когда последний процесс в jail - завершается, сама тюрьма перестает существовать.
По поводу расширенных параметров ufs.
Да нужно посмотреть. Но для начала нужно ответить на вопрос, как уникально идентифицировать jail в системе?

надо куда-то писать какой-то jid - тока как его прилепить к джайлу и какими гвоздями прибить - непонятно вообще.
оно же именно что тока при работе существует...

как по мне слишком далеко вы в будущее смотрите...

для начала хотябы cpulimits сделать (так чтобы в рабочем стабильном варианте)...да и memlimits очень бы не помешали, хотя с памятью сложней...
в виртуозо я долго вьезжал в memory overcommitment accounting...

cpulimits не хватает острее всего. Одна клетка начинает ресурсы хавать и балалайка...

файловые системы в файле?

(может изменить размер ее на ходу можно будет? или на краойня клонировать)

примонтирвоать при старте системы потом загрузить клекти

paix писал(а):как по мне слишком далеко вы в будущее смотрите...

для начала хотябы cpulimits сделать (так чтобы в рабочем стабильном варианте)...да и memlimits очень бы не помешали, хотя с памятью сложней...
в виртуозо я долго вьезжал в memory overcommitment accounting...

cpulimits не хватает острее всего. Одна клетка начинает ресурсы хавать и балалайка...

Вы можете объяснить как в vz считается память? Было бы очень интересно сравнить подходы.

ProFTP писал(а):файловые системы в файле?
(может изменить размер ее на ходу можно будет? или на краойня клонировать)
примонтирвоать при старте системы потом загрузить клекти

ZFS круто, там можно делать все

kostjn писал(а): Вы можете объяснить как в vz считается память? Было бы очень интересно сравнить подходы.

я не являюсь разработчиком openvz, но интересовался этой темой в целях администрирования.

Весьма много инфы можно найти сдесь:
http://wiki.openvz.org

В частности вам будет интересно посмотреть это:
http://wiki.openvz.org/UBC_systemwide_configuration

Также, по поиску в гугле:
OpenVZ Management of System Resources type:pdf
virtuozzo over commitment accounting

Вот в этом гуиде достаточно фундаментально изложена тема ресурсов и менеджмента опенвз.
http://www.altaway.com/resources/vz/VzLinuxUBCMgmt.pdf


Основная загвоздка в том, что называется термином memory overcommitment, т.е. на пальцах когда приложение запрашивает у системы памяти больше, чем есть в наличии ОЗУ.
Система выделяет эти блоки памяти (с учетом свапа), но они часто не используются. (В линуксе посмотреть вывод free -m) Это хорошо работает на Hardware Node, но как быть с виртуалками в условиях легкой (os-level) виртуализации? В виртуозо решение простое, понятие swap немного расплывчато, реально виртуалки будут использовать свап только в том случае, когда в Hardware Node закончится оперативная память полностью. В иных случаях не будут никогда. И вообщемто это правильно. Т.к. дисковый I\O - та вещь которая максимально убивает сервер. Просто следует учитывать, что память в контейнерах виртуозо - это память без оверкоммитмента. Гигабайт - это гигабайт, и если ява при старте попытается аллоцировать больше, то система ей не даст этого сделать. А в реальной системе с гигом озу, ява запросто запустится (благодаря оверкоммитменту)

В VDS_manager, насколько я понимаю, концепция немного другая. По крайней мере в том контейнере что у меня был, я видел в топе колонку swap ( свап персональный для контейнера). И колонка с памятью была тоже одна. Т.е. вся память и wired и cached,buffers, etc считалась как Active.
Но мне такой подход крайне не нравится. Получается что если контейнеру выделить мало озу (скажем, метров 200) и запустить на нем много приложений то они начнут юзать свап, даже без оглядки на то что в системе еще полно свободной памяти. В результате маленький контейнер сможет положить дисковым I\O большую систему.
Это может быть хорошо для end-users, они не будут получать "can not allocate memory" если их приложение попытается аллоцировать больше 200м, но это плохо для системы, т.к. она уйдет в свопинг, нафик нафик короче такой расклад.

PS. наверно стоит сфокусироваться еще больше, если вы сможете хотябы протолкнуть cpu limits per jail до продакшин уровня, то мягко говоря "Родина вас не забудет", и тысячи людей будут благодарны. В вышеприведенных линках на виртуозо описаны также концепции распределения вычислительных ресурсов. Мне кажется они могут вам помочь. Парралельс очень давно и мощно занимается данной темой, и мне кажется что у них OS-based виртуализация реализована достаточно хорошо.

Изначальная постановка ИМХО не совсем правильная, оттого и получаются неразрешимые вопросы. Что есть джейл на уровне ФС? Директория, выше которой нельзя подняться. Так вот для того что бы никто в джейле не смог записать больше положенного надо ограничить эту директорию в объеме. А уж в джейле кто ее будет пользовать или вне его - не важно. Это и для простого чрута будет полезно и вообще более общее рещение, что есть хорошо. Соответственно надо патчить не джейл, а стандартную подсистему квот. Что то типа в стандартном файле квот есть записи, содержащие не имя пользователя, а имя директории. И все. А джейл ли там или хомовик или логи чьи то - не важно. По моему так.

Nefer писал(а):Изначальная постановка ИМХО не совсем правильная, оттого и получаются неразрешимые вопросы. Что есть джейл на уровне ФС? Директория, выше которой нельзя подняться. Так вот для того что бы никто в джейле не смог записать больше положенного надо ограничить эту директорию в объеме. А уж в джейле кто ее будет пользовать или вне его - не важно. Это и для простого чрута будет полезно и вообще более общее рещение, что есть хорошо. Соответственно надо патчить не джейл, а стандартную подсистему квот. Что то типа в стандартном файле квот есть записи, содержащие не имя пользователя, а имя директории. И все. А джейл ли там или хомовик или логи чьи то - не важно. По моему так.

а каким образом тогда предложите организовать дисковые квоты внутри джайла?

А чем стандартный механизм не устраивает? Ну договоритесь сами с собой, что в первом джейлы ИДшники будут 1001-2000, во втором - 2001-3000 и т.д.

Nefer писал(а):А чем стандартный механизм не устраивает? Ну договоритесь сами с собой, что в первом джейлы ИДшники будут 1001-2000, во втором - 2001-3000 и т.д.

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

Я может чего не понимаю, но на какой софт вам надо ставить квоты??? Единственный вариант который придумывается - базы данных, но это решается квотой на раздел-директорию. А пихачить в один джейл юзеров (которым да, нужны квоты) и базы данных... Нахрен вам тогда вообще джейлы? Если все равно все в одну кучу валите.
Минус у данного решения только один - при переезде-переносе инфа о квотах как то могет затеряться. Но это можно решить путем добавления jail_jailname_quota в rc.conf и добавлением проверки-корректировки квоты в /etc/rc.d/jail
Насчет костыля - ну может не самое красивое решение, но давать возможность создавать .quota в любой дире - не комильфо. Оверхед большой на каждую операцию записи, которая и так не отличается повышенной скоростью. А что бы сделать красиво - это уже надо делать совсем другую ФС...