one-cloud ОС уровня датацентра в Одноклассниках/one-cloud new datacenter management system in OK.ru

Одноклассники состоят из более чем восьми тысяч железных серверов, расположенных в нескольких датацентрах. Каждая из этих машин была специализированной под конкретную задачу, как для обеспечения изоляции отказов, так и для обеспечения автоматизированного управления инфраструктурой.
В определенный момент мы поняли, что внедрение новой системы управления позволит нам более эффективно загрузить технику, облегчить управление доступами, автоматизировать (пере)распределение вычислительных ресурсов, ускорить запуск новых сервисов, ускорить реакции на масштабные аварии.

В данном докладе расскажу об основных принципах и процессах, лежащих в основе нашего облака; обеспечения отказоустойчивости как самого облака, так и выполяемых ею задач; нашем подходе к изоляции задач и повышения плотности использования техники.
Я также попытаюсь дать ответ на главный вопрос жизни, вселенной и всего сущего: можно ли сделать так, чтобы Docker не падал.

Social network OK.RU consists of more than 8 000 servers located in several data centers. Each one of these machines was allocated for a specific task, both for failure isolation and for providing automated infrastructure management.
At a certain moment it became clear that a new datacenter management system could improve efficiency in utilizing the hardware, make access management easier, automate resouce managemet, better time to market for new services, faster repair of incidents and even full outages.

This talk is about basic principles and processes of the cloud; fault tolerance of the one-cloud as well as tasks run by it; our strategies of failure isolation and more dense hardware utilization.

Also I'll try to answer the ultimate question of life, the universe and everything: whether it is possible to make Docker work stable.

Transcript

1. one-cloud ОС уровня датацентра в ОК Олег Анастасьев @m0nstermind oa@ok.ru
2. 2 4 ЦОД 500 Стоек 8000 Серверов Железо в Одноклассниках
3. 3 инженеры сетевики админы разработчики
 (функциональные команды )
4. 4 Работает так web frontend API music app server one-graph user-cache black-list (микро) сервисы
5. • 1 сервер = 1 задача • Это просто: • В массовом управлении • В диагностике и мониторинге • 1 сервис = Х серверов • Просто распределяется ресурс • Специализированные конфигурации • Это эффективно 5 Железо в Одноклассниках
6. 6 Самое дорогое - это сервера Самое дорогое - место в ДЦ Утилизация стоек - 11 % Нужно повышать утилизацию
7. • 1 сервер = Х задач
 • Все сложно: • Конфигурация • Диагностика • Чьи ресурсы ? • Нет изоляции 
 7 Повышаем %% по простому
8. • Изоляция • Образы Файловой Системы • Многослойность • Таги • Регистр • АПИ и унификация • автоматизируемость 8 Часть проблем : Docker
9. • Размещение контейнеров на сервера • Упаковка по ресурсам: ЦП, память, трафик • Может быть сложным: стойки • На 8,000 вручную - не вариант • Выделение ресурсов на проект • Больше самостоятельности • Сохраняя контроль 9 Другая часть проблем Нужен управляющий слой
10. 10 Три квадратика docker daemon one-cloud miniond one-cloud masters Linux Kernel
11. Распределение ресурсов
12. • Ресурс это • ЦПУ • Память • Трафик • Диски ( место, тип, iops )
 • Ресурсы конечны • Нужно квотировать 12 Распределение ресурсов cpu = 1500 mem = 1.5 T lan_in = 32 gbit
 lan_out = 32 gbit hdd = 20x15T Q Но на что поставить квоту ?
13. 13 Работает так web frontend API music app server one-graph user-cache black-list (микро) сервисы
14. 14 front web frontend API music one-graph user-cache black-list app server cache db app server photo-cache group-cache music web
15. 15 . cache front web music api … group1 group2 … user-cache Иерархия Q group1.web.front api.music.front user-cache.cache
16. • Имя • Квота на ресурсы • Права пользователей • Отправка сервиса для devops • Административные права для opsdev • Отправляем сервисы • Выполняются в пределах квоты 16 Иерархическая очередь group1.web.front cpu = 1500 mem = 1.5 T Q ( ) Submit, Admin
17. • Сервис имеет: • Полное имя • Манифест 
 ( ресурсы, конфигурация, репликация, отказы )
 • И экземпляры 17 Сервисы ok-web.group1.web.front 1.ok-web.group1.web.front … 2.ok-web.group1.web.front 42.ok-web.group1.web.front ok-app.group1.web.front
18. Классы изоляции задач
19. 19 Классы задач в ОК • С малой задержкой : prod • важна скорость ответа ( latency ) • Расчетные : batch • важна пропускная способность ( throughput ) • Map Reduce, ML, DWH, etc.
 • Фоновые : idle • тесты, пересчеты, конвертации
20. • С малой задержкой • важна скорость ответа
 ( latency ) • размещение резервированием 20 Классы задач в ОК : prod t cores 1 2 3 4 0 max avg alloc: cpu = 4 (max) task 1 task 2 task 3 task 4
21. 21 Классы задач в ОК : batch t avg cores 1 2 3 4 0 min • Расчетные • важна пропускная способность
 ( throughput ) • Map Reduce, ML, DWH, etc. alloc: cpu = [1, * )
22. 22 Классы задач в ОК : prod + batch t cores 1 2 3 4 0 • С малой задержкой • важна скорость ответа • размещение резервированием • Расчетные • важна средняя скорость • MapRed, ML, etc.

23. 23 Как это сделать в docker run prod, cpu = 4 batch, cpu = [1, * ) —cpuset = 1-4 —cpuquota = 400 000 —cpuperiod = 100 000 ?
24. 24 Как это сделать в docker run prod, cpu = 4 batch, cpu = [1, * ) —cpuquota = 400 000 —cpuperiod = 100 000 —cpushares = 1 024 batch, cpu = [2, * ) —cpushares = 2 048
25. • SCHED_OTHER • обычный в Linux • SCHED_BATCH • ресурсоемкий; штраф за активацию • SCHED_IDLE • фоновый < nice -19 25 Linux CPU scheduler policies *man sched_setscheduler github.com/odnoklassniki/one-nio
26. 26 Как это сделать в docker run prod, cpu = 4 batch, cpu = [1, * ) —cpuquota = 400 000 —cpuperiod = 100 000 —cpushares = 1 024 [ —cap-add = SYS_NICE ] + SCHED_OTHER + SCHED_BATCH + SCHED_IDLE idle, cpu = [2, * ) —cpushares = 2 048 [ —cap-add = SYS_NICE ]
27. 27 Трафик t mbps 500 0 prod: lan = 500mbps batch: lan = [100, *) • prod приоритетнее batch • batch > idle ( по avg )
 • на исходящий трафик • и на входящий
 Как это сделать в docker run ? Никак не сделать в docker run…
28. 28 Linux QoS • Traffic Control ( tc ) • Hierarchical Fair Service Curve ( hfsc ) • 2 класса: prod; batch/idle • modprobe ifb • для QoS входящего трафика • регулируемая полоса для batch/idle • это пришлось дописать http://lartc.org
29. 29 ok-web.group1.web.front.prod catalog-manager.music.batch transformer.music.idle prod batch idle … front web music music
 transformer music
 catalog … …
30. • Трафик • внутренняя очередь сетевой карты • только TCP • ~ + 10 % к задержке • CPU интенсивный batch • ~ нет влияния на prod
 • Память • вымывается кеш CPU • ~ + 10% к задержке 30 Полная изоляция невозможна
31. Отказоустойчивость
32. • Изоляция • квота на ресурсы • нет влияния на других
 • Политики рестарта • ALWAYS, ON_FAILURE • NONE 32 Отказ контейнера
33. • Переносим! • Нужен Service Discovery • ( даже для ip-per-container ) • Удобно • Много решений • +Баланировщик • Нужен ли Service Discovery ? • Балансировок уже много • Критическая система + Точка Отказа • Много переделывать. Очень много. Местами невозможно. 33 Отказ миньона
34. • IP статичны • закрепляются при создании сервиса • max( replicas ) • следуют за контейнером по сети • дублирующиеся IP - это ОК
 • DNS • живые и мертвые IP ( клиенты отфильтруют )
 • Критичные сервисы - без DNS 34 Жизнь ( почти ) без Service Discovery 1.1.1.1 1.1.1.2 … ok-web.group1.web.front.prod = 1.1.1.1 1.ok-web.group1.web.front.prod
35. Аварии
36. • Отказ множества машин • Массовые миграции контейнеров • Нехватка ресурсов • Отказ управляющего слоя
 • Взлет количества алертов • Тормоза/Шум в мониторинге 36 Авария - это
37. 37 prod batch idle cache front web music music
 transformer music
 catalog … … 1 2 • Приоритет размещения • Выше приоритет - быстрее мигрирует • Применяется иерархически 0 10 Массовые миграции 0 1
38. 38 prod batch idle cache front web music music
 transformer music
 catalog … … • Приоритет вытеснения задачи • Вытесняет ( останавливает ) задачу с миньона • Часть задач остается неразмещенными Нехватка ресурсов 2 10 10 0 0
39. Тотальное разрушение
40. • Стихия
 
 • Человеческий фактор
 • Баги 40 Авария ДЦ целиком : причины https://habrahabr.ru/company/dataline/blog/333578/ Это НЕ редкость ! #окживи
41. • 1 one-cloud = max( 1 ДЦ ) • Потеря облака = потеря 1 ДЦ • Готовность приложений к потере ДЦ • Политика резервирования • Отказоустойчивые БД • Тестирование отказа/Учения
 • 4 ДЦ = 4 one-cloud • Изолированы друг от друга 41 Изолировать !
42. • При потенциально опасных командах • Массовый останов • При “странных” командах • Уменьшение реплик, смена имени образа сервиса 42 Проверка адеквантности оператора
43. Итоги
44. 44 Три квадратика docker daemon one-cloud miniond one-cloud masters Linux Kernel
45. 45 Три костылика dockerd one-cloud miniond one-cloud masters Linux Kernel cgroup
 net
 stats …
46. • Минимум команд • pull, create, start, stop, rmi, inspect, events • Свой регистри • --block-registry docker.io • —add-registry one-cloud.registry.odkl • Centos Docker build 46 docker, docker, docker, docker https://habrahabr.ru/post/332450/ https://www.infoq.com/presentations/spotify-event-delivery-system
47. • Иерархия сервисов, видимость • prod + batch = плотная утилизация • docker —cpu* + sched_setscheduler/chrt • cpuset • Изоляция, отказы, изолента • Аварии, а также • приоритеты и их польза в иерархии • ops неадекват страшнее стихии 47 45 плотно упакованных слайдов
49. • Мониторинг в облаке • Обеспечение надежности софта • Вам на Joker Conf 2017 • Баги смерти и аварии с умыслом • Стандартный контейнер в ОК • Сбор метрик, каких и как 49 Что не влезло Хотите поговорить об этом ? Пройдемте к барьеру на зону !