Управляемые набеги саранчи, или нагрузочное тестирование с Locust
Дмитрий Куликовский - Построение кластеров,...
Transcript of Дмитрий Куликовский - Построение кластеров,...
Построение кластеров, нагрузочное тестирование и capacity planning
Куликовский Дмитрий
С чего всё начинается
Возможные варианты:
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