Минимально гарантированное SLA по системным ресурсам на системах без виртуализации
В очередной раз ковыряя очередной сервак, задался простым вопросом:
Как сделать сабж ?
Я знаю про /etc/security/limits.conf и прочий ПАМ, renice, etc, но это ограничение ресурсов "сверху" ( т.е их нельзя превысить)
В качестве примера сабжа - при любой загрузке сервака ( да хоть на la 400 как пример) - n% I/O , рамы,проца, файловых дескрипторов и прочих ресурсов гарантируется для , например, sshd и юзера root.Т.е если коннектится root ( как пример, я не хожу рутом), ему гарантируется системные ресурсы и пусть
"весь мир подождет" =)
Собственно, как сделать без применения виртуализации ? Ибо все равно будет хардварная нода, на которую тоже надо ходить и все опять упрется в сабж .
П.С только просьба не вспоминать про сеть как ресурс - там как раз все понятно с приориетизацией траффика.
- Для комментирования войдите или зарегистрируйтесь
1) Ног, ты действительно
1) Ног, ты действительно считаешь, что каждый мимо проходящий знает что такое "SLA"? Я смог догадаться по контексту, но большинство и читать контекст небось не стало, не поняв заголовка и первого абзаца.
2) То, что ты опять троллишь на тему "а вот в винде так можно" - это было очевидно где-то со второго слова заголовка =)
По сути: да можно, да - без виртуализации, на хостерах всяких юниксовых так делали и до появления/распространения виртуализаций. Насчет рута - фиг его знает, честно говоря.
Но, на самом деле, тут все просто, и я не понимаю, почему ты задаешь этот вопрос:
в ядре, в первой вкладке "General settings" есть опция - "Group Scheduling" или как-то так, в которой можно выбрать, по какому принципу группировать процессы - по пользователю, или по какому другому принципу, или по контроль группам.
При группировке по пользователю ты получишь ситуацию, когда рутовые приложения имеют больший вес, нежели вся прочая шушера - как раз то, что ты и хочешь. Проблема, правда, в том, что это только на CPU, да и многие демоны системные бегают под рутом, хотя они и не создают большой LA.
При группировке по контроль группам ты получишь возможность запихивать их в контроль группы и рулить там, в т.ч. задавать эксклюзивные или гарантированные (не помню точно) ресурсы. Пока только для памяти и проца. Заметь - это не виртуализация, это контроль группы, в них можно запихивать процессы и без контейнеров, в т.ч. по pam'у.
Ну и еще проблема в том, что на la 200 у тебя, скорее всего, будет тупить что-то одно и тупить в ядре - i/o ли (своп как подразделение i/o), cpu ли - неважно, т.е. есть у тебя ресурсы для рута по ssh, нету у тебя ресурсов для рута по ssh - пока оно вообще поймет, что ты рут и коннектишься на ssh может пройти немало времени (хотя тут можно вспомнить QoS, но он может лишь усугубить положение на больших la)
Ех, осталось добавить, что у
Ех, осталось добавить, что у мну там 18 ядро :(
про винды сейчас сотру нафик.
П.С Про SLA - а как мне назвать тему ? "Памагите, есть вапрос" ? :)
Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)
slepnoga написал(а): Ех,
ну, хорошо хоть не 2.4.* ...
evadim написал(а): slepnoga
Я всегда могу придумать обоснование для любой фигни :)Что было в данном случае - ты в курсе
Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)
Хорошо,с cgroup && cpuset
Хорошо,с cgroup && cpuset разобрались. Использование ядер с их поддержкой невозможно по причинам выходящим за рамки данной темы и потому здесь не обсуждаемых.
Другие способы есть ? Ведь как то подобные задачи решали раньше - и 5 лет назад , и 10 ?
Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)