2. Повестка дня (aka Agenda)
Зачем и какие ресурсы контролировать?
•
Немного про контейнеры
•
Существующие механизмы, их недостатки
•
Beancounters и CGroups
•
Примеры атак и объяснения
•
Вопросы, предложения, комментарии
•
3. Повестка дня (aka Agenda)
Зачем и какие ресурсы контролировать?
•
Немного про контейнеры
•
Существующие механизмы, их недостатки
•
Beancounters и CGroups
•
Примеры атак и объяснения
•
Вопросы, предложения, комментарии
•
4. Ресурсы: зачем контролировать?
Ресурсы не бесконечны
•
Сервер один, задач и пользователей много
•
Нужна статистика по использованию
•
Нужна защита от DoS атак (лимиты)
•
Нужно обеспечить качество сервиса
•
(гарантии)
5. Ресурсы: что контролировать?
Процессорное время
•
Оперативная память и подкачка (swap)
•
Дисковое пространство
•
Дисковый ввод-вывод (I/O bandwidth)
•
Сеть
•
Всякое разное
•
6. Процессор
Процессорное время раздаётся процессам
маленькими временными отрезками
• Приоритеты (веса)
• Ограничения сверху (лимиты)
• Привязка к конкретным процессорам
(для многопроцессорных систем)
7. Память
• Память уровня пользователя
– Виртуальная (VM) и физическая (RSS)
• Память ядра
– Различные объекты и механизмы выделения
– Особый случай: сетевые буфера
• Пространство подкачки (swap)
8. Диск
• Место
• Пропускная способность ввода-вывода
– Чтение и запись
– Отображения памяти (mmap)
– Подкачка (swapin/swapout)
• Основная проблема: ввод-вывод отвязан
9. Сеть
• Тут всё уже решено, говорить не о чем
• TC: traffic control
– Шейпинг, шедалинг, политики, ...
• iptables
10. Повестка дня (aka Agenda)
Зачем и какие ресурсы контролировать?
•
Немного про контейнеры
•
Существующие механизмы, их недостатки
•
Beancounters и CGroups
•
Примеры атак и объяснения
•
Вопросы, предложения, комментарии
•
11. Контейнеры — это ...
• такая легковесная виртуализация
• много контейнеров поверх единого ядра
• совсем как VM, только
– «родная» производительность
– высокая плотность размещения
– динамическое управление ресурсами
13. HP labs: OpenVZ vs Xen
• Накладные расходы Xen больше
• Накладными расходами OpenVZ
зачастую можно пренебречь
• Под Xen работало 4 копии интернет-
магазина и сервер уже был перегружен,
под OpenVZ заработало 6 без перегрузки
15. Контейнеры
и управление ресурсами
• Обеспечить мирное сосуществование
множества контейнеров
• С точки зрения управления ресурсами,
контейнеры — это просто группы
процессов!
16. Повестка дня (aka Agenda)
Зачем и какие ресурсы контролировать?
•
Немного про контейнеры
•
Существующие механизмы, их недостатки
•
Beancounters и CGroups
•
Примеры атак и объяснения
•
Вопросы, предложения, комментарии
•
17. Процессор
• Каждый процесс имеет nice value,
можно менять «по дороге» (nice/renice)
• Есть приоритет реального времени и
отдельная очередь процессов для него
• Жёсткий лимит на процессорное время
(ulimit -c)
18. Место на диске
• Стандартные UNIX квоты очень хороши
– квоты на точку монтирования
– для пользователей и для групп
– мягкие и жёсткие лимиты, грейс-период
– можно узнать текущие значения
– можно менять лимиты «по дороге»
– приложения ожидают отказов (или должны)
19. Всё остальное: ulimit
• Реализован системными вызовами
setrlimit и getrlimit
• Контролирует 16 разных параметров:
core file size, data segment size, scheduling priority, file size, pending signals,
max locked memory, max memory size, number of open files, pipe size,
POSIX message queues, real-time priority, stack size, cpu time, max user processes,
virtual memory, file locks
• Имеются «мягкие» и «жёсткие» лимиты
20. У ulimit много проблем
Далеко не все ресурсы учитываются
•
Нельзя посмотреть текущее использование
•
Лимиты выставляются в текущем контексте
•
Все лимиты выставляются на процесс
•
– кроме NPROC, который на пользователя
• Лимиты на память в основном игнорируются
21. Повестка дня (aka Agenda)
Зачем и какие ресурсы контролировать?
•
Немного про контейнеры
•
Существующие механизмы, их недостатки
•
Beancounters и CGroups
•
Примеры атак и объяснения
•
Вопросы, предложения, комментарии
•
22. OpenVZ beancounters
Контролирует группы процессов
•
20 различных параметров
•
Все можно менять во время выполнения
•
Для каждого параметра можно видеть:
•
– Текущее значение, пиковое значение
– Счётчик отказов в выделении ресурса
23.
24.
25.
26.
27.
28.
29.
30.
31.
32. ulimit
$ ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 38400
max locked memory (kbytes, -l) 32
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 10240
cpu time (seconds, -t) unlimited
max user processes (-u) 1024
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
