Дмитрий Куликовский - Построение кластеров,...

Построение кластеров, нагрузочное тестирование и capacity planning

Куликовский Дмитрий

dkulikovsky@yandex-team.ru

С чего всё начинается

Возможные варианты:

1) Стартап – сервис, который только начинает свою жизнь

2) BigData only – сервис по обработке данных, mapReduce, machine learning и прочий OLAP

3) Проект с историей и большим количеством legacy

Нижний колонтитул

Важность проектирования

•  Где разместить проект

•  Какой уровень резервирования необходим

•  Что должно войти в SLA

•  Как проект будет масштабироваться

4

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

5

Масштабирование

• Масштабирование может быть как вертикальным, так и горизонтальным.

• Шардирование – основа для горизонтального масштабирования.

• Правильная архитектура в целом – основа для вертикального масштабирования

6

Deploy

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

• Как выкладывать новый софт?

• Как в продакшн выходит новый релиз пакета или ядра?

• Релизный цикл, continous integration

• Тесты, препродакшн стенд

• Как выкладывать хотфиксы или откатываться назад?

7

Всегда есть что то еще

Всё предусмотреть невозможно, поэтому нужно пользоваться простыми правилами:

•  Сначала проектировать, потом делать

•  Unix way – каждый кусок делать должен делать свою работу и делать её хорошо

•  SLA

•  и самое главное..

8

9

Новый сервис: свои сложности

• Серверов и мощностей всегда мало, их приходится экономить

• Сервера живут у какого то хостера или в облаке и их обслуживание затрудненно

• Приходится учитывать вероятность того что сервер или диск будут менять долго – день, два, неделю

• Если все сервера в одном дц, он может полностью выйти из строя, даже сгореть

Новый сервис: свои сложности

• Нет большого выбора в решениях по резервированию

• Зачастую нет хорошего выбора железа

• В облаках есть свои проблемы – например нельзя, докупив новые мощности, решить проблему медленного IO

• Множество других проблем из-за того что эксплуатация инфраструктуры отдана внешним людям

Выбор софта

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

12

Выбор софта

λ Oracle или mysql λ Gpfs или Ceph λ VmWare или OpenStack λ  И т.д.

13

Новый сервис: очевидные телодвижения

•  Нужно сразу выделить мощности под разработку и тестирование

•  Отследить очевидные точки отказа и подумать как их зарезервировать

•  Мониторинг – что и как мониторить

•  Графики – опять же, что и как показывать на графиках

14

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

15

Новый сервис: очевидные телодвижения

•  Бекапы важных данных

•  Учесть административные риски:

• Новости хостера

• Даты контрактов

• Ситуация в стране

• и т.д.

•  Удалённые бекапы

16

Кластер для big data

•  Какой софт использовать

•  Резервирование на уровне приложения или средствами ОС

•  Как проводить обновление, обслуживание кластеров

•  real time или работа с большими заданиями

17

Проект с историей

18

How did this Happen?

Проект с историей

•  Редко когда есть актуальная и толковая документация, в том числе и по архитектуре проекта

•  У всех в проекте замылен глаз

•  Сложно вносить существенные изменения

•  Продакшн оброс legacy кодом, который некому поддерживать

19

Мониторинг

В первую очередь надо определится – что за сервис мы предоставляем, по какому показателю клиенты решат что всё работает хорошо.

• Если сервис обрабатывает и показывает картинки, что является его показателем работоспособности?

• А если сервис занимается составлением большого отчета?

• Как видят «правильную» работу сервиса разработчики, админы, директор?

20

Что такое SLA

•  Традиционный пункт в SLA – доступность сервиса: 99% или 99.9999%

•  Время реакции системы – тайминги или время обработки задания

•  Скорость реакции на проблемы

•  Время восстановления после сбоя

21

Мониторинг, основы

Всегда нужно мониторить сам сервер

•  Доступность сервера

•  Загруженность ресурсов: сеть, диски, процессор, память

•  Ошибки в сети

•  Здоровье дисков, рейдов

22

Мониторинг сервисов

На каждый важный процесс должен быть мониторинг.

• Если это http сервер, то должна быть проверка, делающая http запрос.

•  Если делается бекап, то нужно проверять сделался ли он или сразу проверять что он разворачивается на тестовом стенде (комплексная проверка).

•  Мониторинг должен давать ясный ответ на вопрос о том что сломалось.

23

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

24

Функциональный мониторинг

•  Мониторинг показателей SLA.

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

•  Активный мониторинг, который может переводить нагрузку на заглушку, т.н. тыкву (например мониторинг ipvs)

25

Графики

•  Собирайте все возможные метрики как можно чаще

•  Из основных метрик собирайте dashboard’ы и медитируйте над ними

•  Графики лучший способ увидеть поведение системы в динамике

26

Минимальная отказоустойчивость

Классическая схема с hot standby

27

Как задачи предстоит решать

• Синхронизация, что выбрать?

• Репликация

• Rsync

• Drdb, gpfs, ceph etc.

•  Механизмы переключения, автоматика v.s. ручное

•  Как проверять синхронность, как её восстанавливать

28

Пример

29

Что проверять?

•  Проверка синхронизации данных

•  Синхронизация конфигурации

•  «Учения» по переключению на standby

30

Живая копия

31

Пример

32

Всё тоже самое, но только быстрей

•  Синхронизация стала сложнее, должна работать в обе стороны.

•  Latency сети выходит на передний план

•  Split brain – третья «как бы нога»

•  Распределённые сервисы – кеш, очереди, блокировки

•  Транспорт (p2p, multicast, rsync, etc.)

33

Больше дц

34

Инфраструктура

•  Без удобного способа запускать новые сервера больше жить нельзя

•  Своя инфрастурктура сети, свой днс и firewall

•  Системы управления конфигурациями: salt, puppet, chef, etc.

•  Наливка и обновление серверов

35

Инфраструктура

•  Время еще раз подумать про облачные решения

•  Не каждый дц одинаково полезен

•  Новые дц больше и железо в них более свежее

•  Апгрейд серверов или гетерогенная среда и умная балансировка нагрузки

36

Кластерные решения

•  Дерево репликации

•  Синхронная копия без подтверждения записи или с частичным подтверждением

•  Полностью синхронная копия

•  Базы с поддержкой региональности

37

Мониторинг не сервера, а сервиса

Для кластерных решений с несколькими дц мониторинг выглядит по-другому, на первый план выходит мониторинг сервиса и агрегаты проверок.

• Агрегированный мониторинг, понятия кворум и гистерезис.

• В SLA включается понятие о степени деградации

• Для графиков тоже теперь есть смысл смотреть только на агрегированные значения

• Косвенный мониторинг – сломалось на одном хосте, а загорелось на другом

38

Планетарная отказоустойчивость

Задача не решается чисто техническим путём, использовать датацентры на разных континентах можно будет только если заложить это в архитектуру сервиса.

•  Локальность пользователя

•  Шардирование, редиректы, частичная синхронизация

•  CDN

•  Распределённый мониторинг

39

Новые задачи

•  Традиционные решения для транспорта данных не работают (например реплика), нужно тюнить сеть и выбирать новые решения.

•  Синхронизация всего – пакетов, конфигов, доступов, ёмкостей кластеров.

•  Больше формализации и бюрократии

40

Deploy в масштабах планеты

•  Выкладка новой версии – задача на целый день

•  Кровавая война за скорость выкладки

•  Как обновить ядро на 50 000 серверах по всему миру?

•  Автоматизировать выкладку или нанять команду админов?

41

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

42

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

•  Dashboard’ы с метриками из SLA

•  Тщательные разборы инцидентов по мониторигам параметров SLA

•  Системы управления кластерами и задачи синхронизации версий пакетов, скриптов, конфигов

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

43

Capacity planning

•  Нагрузочное тестирование

•  Анализ продуктовых планов

•  Анализ естественного роста

Всегда нужно учитывать рост скорости работы новых серверов, разные компоненты растут по разному.

44

Пример 1

Capacity planning в простом сервисе, когда достаточно учитывать только естественный рост.

•  Найти самый загруженный ресурс

•  Оценить тренд

•  Прикинуть, с линейкой, когда ресурс закончится

45

Пример 1

46

Пример 2

Большой кластер с разными по размеру дц

Разные по мощности сервера

Высокие требования по доступности и качеству

Кластера должны выдерживать пиковые нагрузки при подключении новых клиентов

47

Пример 2

48

Анализ планов

Планы по продукту «Сервис 2.0»

• Запустить новый фронтэнд

• Ускорить генерацию отчетов до 1с

• Повысить отказоустойчивость

• Новые среды для тестирования

49

Планы в железе

• По 4 новых сервера в 3х дц

• +50% серверов под новое решение = 600*50% = 300 новых серверов

• Добавить дополнительную копию данных = + 300 серверов

• + 30 новых серверов под виртуалки и тестовый стенд

Что почитать

• 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

Что почитать

• Искусство программирования для 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