Как жить в облаке без админов?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 ec2-54-227-28-75.compute-1.amazonaws.com service_descriptionCurrent Load check_command check_nrpe_1arg!check_load! event_handlerrestart_phpfpms } define command{ command_namerestart_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.000001 | 0 | 0.000000 | | 0.000010 | 2011 | 0.007438 | | 0.000100 | 12706 | 0.513395 | | 0.001000 | 4624 | 1.636106 | | 0.010000 | 2994 | 12.395174 | | 0.100000 | 200 | 6.225339 | | 1.000000 | 33 | 5.480764 | | 10.000000 | 1 | 2.374067 | | 100.000000 | 0 | 0.000000 | | 1000.000000 | 0 | 0.000000 | | 10000.000000 | 0 | 0.000000 | | 100000.000000 | 0 | 0.000000 | | 1000000.000000 | 0 | 0.000000 | | TOO LONG | 0 | TOO LONG | +----------------+-------+----------------+ 14 rows in set (0.00 sec)

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

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

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

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

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

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

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

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

45. Спасибо за внимание! Вопросы? Александр Демидов demidov@1c-bitrix.ru +7-926-521-3700 @demidov http://www.1c-bitrix.ru