Как жить в облаке без админов? Александр Демидов руководитель направления арендных решений «1С-Битрикс» - презентация

1 Как жить в облаке без админов? Александр Демидов руководитель направления арендных решений «1С-Битрикс»

2 -Новый сервер? Нестандартной конфигурации? 5-го января? … Нет, не слышали.

3 Облако! Быстро! Надежно! Дешево! Неправда…

4

5

6

7 Надежность «облака» Само по себе «облако» не надежнее традиционного хостинга и собственного оборудования. «Облако» дает возможность организовать надежную инфраструктуру.

8 Сама инфраструктура не построится…

9 Админы пока еще не нужны… Нужен аналитик…

10 Админы пока еще не нужны… …и архитектор.

11 Правильное облако Несколько территориально распределенных ДЦ (с возможностью их выбора) Гибкое управление дисками Облачные базы данных, кэш, NoSQL, балансировщики, DNS, мониторинг, сервисы очередей, файловые хранилища, CDN и т.д. API и готовые SDK для управления всеми сервисами

12 Готовность приложения к масштабированию

13 Elastic Load Balancing Web 1 Elastic Load Balancing Dynamic HTTPS *.com/*.de Web N … CloudWatch + AutoScaling Web 1 Web 2 Web N … CloudWatch + AutoScaling Резервируй это! S3 management, monitoring, backup Static HTTPS *.com/*.de CDN (Amazon CloudFront) js, css Dynamic HTTPS *.ru Static HTTPS *.ru CDN (CDNvideo) js, css images (clients) local cache (APC) control cache: memcached mysqld master-master replication mysqld control cache: memcached Web 2 local cache (APC)

14 CloudWatch + Auto Scaling Web 1 Очень высокая посещаемость Elastic Load Balancing Web 2 Web N … Web – автоматическое масштабирование Используем связку Elastic Load Balancing + CloudWatch + Auto Scaling

15 Web – автоматическое масштабирование Используем связку Elastic Load Balancing + CloudWatch + Auto Scaling Автоматически стартуют новые машины, если средняя нагрузка CPU превышает X% Автоматически останавливаются и выводятся из эксплуатации, если средняя нагрузка менее Y%

16 Быстрое восстановление кэша при рестарте базы Оптимизирован для Multitenancy приложений с тысячами таблиц Оптимизирован для сбора статистики по отдельным пользователям Подробная статистика по медленным запросам XtraDB и XtraBackup BLOB, TEXT в таблицах MEMORY (HEAP) MySQL? Percona Server! Один из выводов в процессе эксплуатации: используем один из forkов MySQL – Percona Server (обратно совместим с MySQL)

17 Особенности настройки MySQL: auto_increment_increment auto_increment_offset Базы в разных датацентрах синхронны, при этом независимы друг от друга: потеря связности между датацентрами может составлять часы, данные синхронизируются после восстановления. Группы пользователей работают в одном датацентре за счет управления балансировщиком. Какие-то данные можно не реплицировать: SET sql_log_bin = 0 … или … replicate-wild-ignore-table = %.b_sec_session% Используем master-master репликацию в MySQL

18 MySQL master Elastic Load Balancing Elastic Load Balancing Web N … Web 1 Web 2 MySQL master Web 1 Web 2 Web N … master-master репликация Сценарий 1: авария на одной или нескольких веб-нодах S3 management, monitoring, MySQL backup Датацентр 1 в регионе US East (Virginia) Мониторинг и масштабирование – CloudWatch + AutoScaling Датацентр 2 в регионе US East (Virginia) Мониторинг и масштабирование – CloudWatch + AutoScaling

19 Load Balancing определяет вышедшие из строя машины Исходя из заданных параметров группы балансировки, автоматически восстанавливается нужное количество машин Сценарий 1: авария на одной или нескольких веб-нодах

20 MySQL master Elastic Load Balancing Elastic Load Balancing Web N … Web 1 Web 2 MySQL master Web 1 Web 2 Web N … master-master репликация Сценарий 1: авария на одной или нескольких веб-нодах S3 management, monitoring, MySQL backup Датацентр 1 в регионе US East (Virginia) Мониторинг и масштабирование – CloudWatch + AutoScaling Датацентр 2 в регионе US East (Virginia) Мониторинг и масштабирование – CloudWatch + AutoScaling

21 MySQL master Elastic Load Balancing Elastic Load Balancing Web N … Web 1 Web 2 MySQL master Web 1 Web 2 Web N … master-master репликация Сценарий 2: потеря связности между датацентрами S3 management, monitoring, MySQL backup Датацентр 1 в регионе US East (Virginia) Мониторинг и масштабирование – CloudWatch + AutoScaling Датацентр 2 в регионе US East (Virginia) Мониторинг и масштабирование – CloudWatch + AutoScaling Elastic Load Balancing Elastic Load Balancing Elastic Load Balancing Elastic Load Balancing

22 Каждый датацентр продолжает обслуживать свой сегмент клиентов Данные синхронизируются после восстановления связности Сценарий 2: потеря связности между датацентрами

23 MySQL master Elastic Load Balancing Elastic Load Balancing Web N … Web 1 Web 2 MySQL master Web 1 Web 2 Web N … master-master репликация Сценарий 3: плановые работы с базой или авария всего ДЦ S3 management, monitoring, MySQL backup Датацентр 1 в регионе US East (Virginia) Мониторинг и масштабирование – CloudWatch + AutoScaling Датацентр 2 в регионе US East (Virginia) Мониторинг и масштабирование – CloudWatch + AutoScaling

24 Не бывает «почти круглосуточно» Технические работы должны проходить незаметно для клиентов: Сервисные работы Замена оборудования Обновления системного ПО Обновления приложений

25 Весь траффик переключается в один работающий датацентр CloudWatch определяет возросшую нагрузку на машины и добавляет их в соответствие с правилами для AutoScaling Приостанавливается мастер-мастер репликация Проводятся все необходимые работы с базой, на которую не идет нагрузка База включается в работу, восстанавливается репликация Траффик распределяется на оба датацентра Гасятся лишние машины, если средняя нагрузка стала ниже порогового значения Сценарий 3: авария или плановые работы с базой

26 Real Time мониторинг – как узнавать о проблемах? Можно – так…

27 Real Time мониторинг – как узнавать о проблемах? Или – так…

28 Организация системы мониторинга Лучше – стандартные решения (Nagios, Zabbix и т.п.), а не самописные. Дежурная смена и/или мгновенные уведомления. Мониторить – всё. Но – аккуратно. Тысячи уведомлений будут бесполезны. Мониторить систему мониторинга. В идеальном мире – распределенная система мониторинга. Автоматизация типовых реакций.

29 Помимо стандартных - пишите свои тесты Пример для MySQL

30 Автоматизация типовых реакций Рост / падение LA – автоматическое масштабирование вверх / вниз Автоматический рестарт «сбойных» сервисов Автоматическое «удаление» проблемных машин Автоматическое восстановление репликации Автоматическое переключение траффика в случае аварии на уровне целого ДЦ

31 event handler # LA on the server define service{ use local-service host_name ec compute-1.amazonaws.com service_description Current Load check_command check_nrpe_1arg!check_load! event_handler restart_phpfpms } define command{ command_name restart_phpfpms command_line /usr/lib64/nagios/plugins/check_nrpe -H $HOSTADDRESS$ -c restart_phpfpm }

32 Мониторинг нетипичных характеристик Наличие бэкапов Срок делегирования доменов Срок действия SSL сертификатов Баланс у провайдера смс-уведомлений

33 Мониторинг веб-приложения Лог работы скрипта (>) – обновился за N часов Лог ошибок работы скрипта (2>) – должен быть пуст

34 Уведомления – как у нас Cкрипт, опрашивающий страницу «Problems» Шлем «дайджест» проблем, а не по одному сообщению на каждое событие Несколько уровней критичности событий Разные списки адресатов на разные события Повтор (через 15 минут, через 2 часа), чтобы не «потерять» уведомление ОК – если все стало хорошо

35 Аналитика

36 «Живая» система – много небольших запросов mysql> SELECT * FROM INFORMATION_SCHEMA.QUERY_RESPONSE_TIME; | time | count | total | | | 0 | | | | 2011 | | | | | | | | 4624 | | | | 2994 | | | | 200 | | | | 33 | | | | 1 | | | | 0 | | | | 0 | | | | 0 | | | | 0 | | | | 0 | | | TOO LONG | 0 | TOO LONG | rows in set (0.00 sec)

37 Аналитика - MySQL Одиночные медленные запросы отлавливаются просто. Сложнее мониторить общее состояние системы с большим количеством относительно быстрых запросов.

38 Поиск узких мест Pinba, XDebug, XHProf

39 Приложение всегда работает в условиях ограниченных ресурсов Постоянный feedback разработчикам – в автоматическом и полуавтоматическом режиме

40 Резюме Систему в облаке можно поддерживать, обходясь минимумом человеческих ресурсов Выбирайте правильное облако – с максимально широким набором сервисов, API и т.п. Ваше приложение должно быть готово к горизонтальному масштабированию Резервируйте все Обязательно используйте системы мониторинга Автоматизируйте все типовые действия Держите приложение в условиях ограниченных ресурсов и всегда давайте обратную связь разработчикам.

41 До 2012 года… Два основных продукта: Единственное, что требовало того или иного обслуживания – наш собственный сайт.

42 В настоящее время… CRM CDN бэкап файлы сканер безопасности ?? видеозвонки push

43 Облачные сервисы Битрикс24 – SaaS «Корпоративный портал» Более 7000 наиболее активных порталов Ускорение сайта – интеграция с CDN Около 9000 сайтов Облачный бэкап Более 7500 сайтов Анонс новых сервисов осенью 2013

44 Примерно 2 стойки 42U – если без виртуализации Два человека – у которых админство не является основной деятельностью

45 Спасибо за внимание! Вопросы? Александр Демидов