2. Построение кластеров,
нагрузочное тестирование и
capacity planning
Куликовский Дмитрий
dkulikovsky@yandex-team.ru

3. С чего всё начинается
Возможные варианты:
1) Стартап – сервис, который только начинает свою
жизнь
2) BigData only – сервис по обработке данных,
mapReduce, machine learning и прочий OLAP
3) Проект с историей и большим количеством legacy
Нижний колонтитул

4. Важность проектирования
• Где разместить проект
• Какой уровень резервирования необходим
• Что должно войти в SLA
• Как проект будет масштабироваться
4

5. Использовать облако или нет?
5

6. Масштабирование
• Масштабирование может быть
как вертикальным, так и
горизонтальным.
• Шардирование – основа для
горизонтального
масштабирования.
• Правильная архитектура в
целом – основа для
вертикального масштабирования
6

7. Deploy
Перед тем как начать разрабатывать новый сервис или
просто собирать кластер для майнинга данных, нужно
ответить на крайне важные вопросы про то как обновлять
или откатывать софт в продакшине.
• Как выкладывать новый софт?
• Как в продакшн выходит новый релиз пакета или ядра?
• Релизный цикл, continous integration
• Тесты, препродакшн стенд
• Как выкладывать хотфиксы или откатываться назад?
7

8. Всегда есть что то еще
Всё предусмотреть невозможно, поэтому
нужно пользоваться простыми правилами:
• Сначала проектировать, потом делать
• Unix way – каждый кусок делать должен делать свою
работу и делать её хорошо
• SLA
• и самое главное..
8

9. 9

10. Новый сервис: свои сложности
• Серверов и мощностей всегда мало, их приходится
экономить
• Сервера живут у какого то хостера или в облаке и их
обслуживание затрудненно
• Приходится учитывать вероятность того что сервер или
диск будут менять долго – день, два, неделю
• Если все сервера в одном дц, он может полностью выйти из
строя, даже сгореть

11. Новый сервис: свои сложности
• Нет большого выбора в решениях по
резервированию
• Зачастую нет хорошего выбора железа
• В облаках есть свои проблемы – например нельзя,
докупив новые мощности, решить проблему
медленного IO
• Множество других проблем из-за того что
эксплуатация инфраструктуры отдана внешним людям

12. Выбор софта
Правильный выбор софта, который будет
использоваться – один из самых важных моментов в
жизни сервиса. Использовать ли Mysql или купить
лицензию Oracle. Приобрести лицензию на gpfs или
использовать cephfs (которое еще даже не production
ready)..
12

13. Выбор софта
λ Oracle или mysql
λ Gpfs или Ceph
λ VmWare или OpenStack
λ И т.д.
13

14. Новый сервис: очевидные телодвижения
• Нужно сразу выделить мощности под разработку и
тестирование
• Отследить очевидные точки отказа и подумать как их
зарезервировать
• Мониторинг – что и как мониторить
• Графики – опять же, что и как показывать на
графиках
14

15. Простой пример
15

16. Новый сервис: очевидные телодвижения
• Бекапы важных данных
• Учесть административные риски:
• Новости хостера
• Даты контрактов
• Ситуация в стране
• и т.д.
• Удалённые бекапы
16

17. Кластер для big data
• Какой софт использовать
• Резервирование на уровне приложения или
средствами ОС
• Как проводить обновление, обслуживание кластеров
• real time или работа с большими заданиями
17

18. Проект с историей
18
How did this Happen?

19. Проект с историей
• Редко когда есть актуальная и толковая
документация, в том числе и по архитектуре проекта
• У всех в проекте замылен глаз
• Сложно вносить существенные изменения
• Продакшн оброс legacy кодом, который некому
поддерживать
19

20. Мониторинг
В первую очередь надо определится – что за
сервис мы предоставляем, по какому показателю
клиенты решат что всё работает хорошо.
• Если сервис обрабатывает и показывает картинки, что
является его показателем работоспособности?
• А если сервис занимается составлением большого отчета?
• Как видят «правильную» работу сервиса разработчики,
админы, директор?
20

21. Что такое SLA
• Традиционный пункт в SLA – доступность сервиса:
99% или 99.9999%
• Время реакции системы – тайминги или время
обработки задания
• Скорость реакции на проблемы
• Время восстановления после сбоя
21

22. Мониторинг, основы
Всегда нужно мониторить сам сервер
• Доступность сервера
• Загруженность ресурсов: сеть, диски, процессор,
память
• Ошибки в сети
• Здоровье дисков, рейдов
22

23. Мониторинг сервисов
На каждый важный процесс должен быть
мониторинг.
• Если это http сервер, то должна быть проверка, делающая
http запрос.
• Если делается бекап, то нужно проверять сделался ли он
или сразу проверять что он разворачивается на тестовом
стенде (комплексная проверка).
• Мониторинг должен давать ясный ответ на вопрос о том
что сломалось.
23

24. Мониторинг – основа здоровья
24

25. Функциональный мониторинг
• Мониторинг показателей SLA.
• Асинхронный мониторинг – скрипт отправляет
задание в очередь и ждёт результат на другом конце, т.о.
Проверяет всю цепочку обработки задания.
• Активный мониторинг, который может переводить
нагрузку на заглушку, т.н. тыкву (например мониторинг
ipvs)
25

26. Графики
• Собирайте все возможные метрики как можно чаще
• Из основных метрик собирайте dashboard’ы и
медитируйте над ними
• Графики лучший способ увидеть поведение системы
в динамике
26

27. Минимальная отказоустойчивость
Классическая схема с hot standby
27

28. Как задачи предстоит решать
• Синхронизация, что выбрать?
• Репликация
• Rsync
• Drdb, gpfs, ceph etc.
• Механизмы переключения, автоматика v.s. ручное
• Как проверять синхронность, как её восстанавливать
28

29. Пример
29

30. Что проверять?
• Проверка синхронизации данных
• Синхронизация конфигурации
• «Учения» по переключению на standby
30

31. Живая копия
31

32. Пример
32

33. Всё тоже самое, но только быстрей
• Синхронизация стала сложнее, должна работать в
обе стороны.
• Latency сети выходит на передний план
• Split brain – третья «как бы нога»
• Распределённые сервисы – кеш, очереди,
блокировки
• Транспорт (p2p, multicast, rsync, etc.)
33

34. Больше дц
34

35. Инфраструктура
• Без удобного способа запускать новые сервера
больше жить нельзя
• Своя инфрастурктура сети, свой днс и firewall
• Системы управления конфигурациями: salt, puppet,
chef, etc.
• Наливка и обновление серверов
35

36. Инфраструктура
• Время еще раз подумать про облачные решения
• Не каждый дц одинаково полезен
• Новые дц больше и железо в них более свежее
• Апгрейд серверов или гетерогенная среда и умная
балансировка нагрузки
36

37. Кластерные решения
• Дерево репликации
• Синхронная копия без подтверждения записи или с
частичным подтверждением
• Полностью синхронная копия
• Базы с поддержкой региональности
37

38. Мониторинг не сервера, а сервиса
Для кластерных решений с несколькими дц
мониторинг выглядит по-другому, на первый план
выходит мониторинг сервиса и агрегаты проверок.
• Агрегированный мониторинг, понятия кворум и гистерезис.
• В SLA включается понятие о степени деградации
• Для графиков тоже теперь есть смысл смотреть только на
агрегированные значения
• Косвенный мониторинг – сломалось на одном хосте, а
загорелось на другом
38

39. Планетарная отказоустойчивость
Задача не решается чисто техническим путём,
использовать датацентры на разных континентах
можно будет только если заложить это в архитектуру
сервиса.
• Локальность пользователя
• Шардирование, редиректы, частичная
синхронизация
• CDN
• Распределённый мониторинг
39

40. Новые задачи
• Традиционные решения для транспорта данных не
работают (например реплика), нужно тюнить сеть и
выбирать новые решения.
• Синхронизация всего – пакетов, конфигов, доступов,
ёмкостей кластеров.
• Больше формализации и бюрократии
40

41. Deploy в масштабах планеты
• Выкладка новой версии – задача на целый день
• Кровавая война за скорость выкладки
• Как обновить ядро на 50 000 серверах по всему
миру?
• Автоматизировать выкладку или нанять команду
админов?
41

42. Как за всем уследить
42

43. Как за всем уследить
• Dashboard’ы с метриками из SLA
• Тщательные разборы инцидентов по мониторигам
параметров SLA
• Системы управления кластерами и задачи
синхронизации версий пакетов, скриптов, конфигов
• Максимальное покрытие тестами и нагрузочным
тестированием
43

44. Capacity planning
• Нагрузочное тестирование
• Анализ продуктовых планов
• Анализ естественного роста
Всегда нужно учитывать рост скорости работы новых
серверов, разные компоненты растут по разному.
44

45. Пример 1
Capacity planning в простом сервисе, когда достаточно
учитывать только естественный рост.
• Найти самый загруженный ресурс
• Оценить тренд
• Прикинуть, с линейкой, когда ресурс закончится
45

46. Пример 1
46

47. Пример 2
Большой кластер с разными по размеру дц
Разные по мощности сервера
Высокие требования по доступности и качеству
Кластера должны выдерживать пиковые нагрузки при
подключении новых клиентов
47

48. Пример 2
48

49. Анализ планов
Планы по продукту «Сервис
2.0»
• Запустить новый фронтэнд
• Ускорить генерацию отчетов
до 1с
• Повысить
отказоустойчивость
• Новые среды для
тестирования
49
Планы в железе
• По 4 новых сервера в 3х дц
• +50% серверов под новое
решение = 600*50% = 300
новых серверов
• Добавить дополнительную
копию данных = + 300
серверов
• + 30 новых серверов под
виртуалки и тестовый стенд

50. Что почитать
• Web Operations: Keeping the Data On Time
https://clck.ru/9MbcW
• The Art of Capacity Planning: Scaling Web Resources
https://clck.ru/9MbdF
• Guerrilla Capacity Planning https://clck.ru/9MbdZ
50

51. Что почитать
• Искусство программирования для Unix
https://clck.ru/9Mbdy
• Linux Kernel Development (3rd Edition) https://
clck.ru/9Mbe8
• Data Analysis with Open Source Tools
https://clck.ru/9MbeU
• UNIX. Руководство системного администратора. Для
профессионалов https://clck.ru/9MbfZ
51