Bitrix clouds without_admins

374 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
374
On SlideShare
0
From Embeds
0
Number of Embeds
69
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Bitrix clouds without_admins

  1. 1. Как жить в облаке без админов? Александр Демидов руководитель направления арендных решений «1С-Битрикс»
  2. 2. - Новый сервер? Нестандартной конфигурации? 5-го января? … Нет, не слышали.
  3. 3. Облако! Быстро! Надежно! Дешево! Неправда…
  4. 4. Надежность «облака» Само по себе «облако» не надежнее традиционного хостинга и собственного оборудования. «Облако» дает возможность организовать надежную инфраструктуру.
  5. 5. Сама инфраструктура не построится…
  6. 6. Админы пока еще не нужны… Нужен аналитик…
  7. 7. Админы пока еще не нужны… …и архитектор.
  8. 8. Правильное облако Несколько территориально распределенных ДЦ (с возможностью их выбора) Гибкое управление дисками Облачные базы данных, кэш, NoSQL, балансировщики, DNS, мониторинг, сервисы очередей, файловые хранилища, CDN и т.д. API и готовые SDK для управления всеми сервисами
  9. 9. Готовность приложения к масштабированию
  10. 10. Резервируй это! Static HTTPS *.com/*.de Static HTTPS *.ru js, css Elastic Load Balancing Web 1 local cache (APC) CloudWatch + AutoScaling Web 2 local cache (APC) … mysqld control cache: memcached js, css Elastic Load Balancing local cache (APC) local cache (APC) CloudWatch + AutoScaling Web 2 local cache (APC) S3 master-master replication mysqld mysqld master-master replication control cache: memcached mysqld mysqld mysqld control cache: memcached … local cache (APC) mysqld mysqld mysqld mysqld mysqld control cache: memcached management, monitoring, backup Web N mysqld mysqld mysqld control cache: memcached CDN (CDNvideo) Web 1 master-master replication mysqld Dynamic HTTPS *.ru Web N mysqld mysqld images (clients) CDN (Amazon CloudFront) images (clients) Dynamic HTTPS *.com/*.de mysqld control cache: memcached
  11. 11. Web – автоматическое масштабирование Используем связку Elastic Load Balancing + CloudWatch + Auto Scaling Очень высокая посещаемость Elastic Load Balancing Web 1 Web 2 … CloudWatch + Auto Scaling Web N
  12. 12. Web – автоматическое масштабирование Используем связку Elastic Load Balancing + CloudWatch + Auto Scaling Автоматически стартуют новые машины, если средняя нагрузка CPU превышает X% Автоматически останавливаются и выводятся из эксплуатации, если средняя нагрузка менее Y%
  13. 13. MySQL? Percona Server! Один из выводов в процессе эксплуатации: используем один из fork’ов MySQL – Percona Server (обратно совместим с MySQL) Быстрое восстановление кэша при рестарте базы Оптимизирован для Multitenancy приложений с тысячами таблиц Оптимизирован для сбора статистики по отдельным пользователям Подробная статистика по медленным запросам XtraDB и XtraBackup BLOB, TEXT в таблицах MEMORY (HEAP)
  14. 14. Используем master-master репликацию в MySQL Особенности настройки MySQL: auto_increment_increment auto_increment_offset Базы в разных датацентрах синхронны, при этом независимы друг от друга: потеря связности между датацентрами может составлять часы, данные синхронизируются после восстановления. Группы пользователей работают в одном датацентре за счет управления балансировщиком. Какие-то данные можно не реплицировать: SET sql_log_bin = 0 … или … replicate-wild-ignore-table = %.b_sec_session%
  15. 15. Сценарий 1: авария на одной или нескольких веб-нодах Elastic Load Balancing Web 1 Web 2 Датацентр 1 в регионе US East (Virginia) … Web N MySQL master S3 master-master репликация Web 1 MySQL master Web 2 … Web N Датацентр 2 в регионе US East (Virginia) Мониторинг и масштабирование – CloudWatch + AutoScaling Мониторинг и масштабирование – CloudWatch + AutoScaling management, monitoring, MySQL backup
  16. 16. Сценарий 1: авария на одной или нескольких веб-нодах Load Balancing определяет вышедшие из строя машины Исходя из заданных параметров группы балансировки, автоматически восстанавливается нужное количество машин
  17. 17. Сценарий 1: авария на одной или нескольких веб-нодах Elastic Load Balancing Web 1 Web 2 Датацентр 1 в регионе US East (Virginia) … Web N MySQL master S3 master-master репликация Web 1 MySQL master Web 2 … Web N Датацентр 2 в регионе US East (Virginia) Мониторинг и масштабирование – CloudWatch + AutoScaling Мониторинг и масштабирование – CloudWatch + AutoScaling management, monitoring, MySQL backup
  18. 18. Сценарий 2: потеря связности между датацентрами Elastic Load Balancing Web 1 Web 2 Датацентр 1 в регионе US East (Virginia) … Elastic Load Balancing Web N MySQL master S3 master-master репликация Elastic Load Balancing Web 1 MySQL master Web 2 … Web N Датацентр 2 в регионе US East (Virginia) Мониторинг и масштабирование – CloudWatch + AutoScaling Мониторинг и масштабирование – CloudWatch + AutoScaling management, monitoring, MySQL backup
  19. 19. Сценарий 2: потеря связности между датацентрами Каждый датацентр продолжает обслуживать свой сегмент клиентов Данные синхронизируются после восстановления связности
  20. 20. Сценарий 3: плановые работы с базой или авария всего ДЦ Elastic Load Balancing Web 1 Web 2 Датацентр 1 в регионе US East (Virginia) … Web N MySQL master S3 master-master репликация Web 1 MySQL master Web 2 … Web N Датацентр 2 в регионе US East (Virginia) Мониторинг и масштабирование – CloudWatch + AutoScaling Мониторинг и масштабирование – CloudWatch + AutoScaling management, m onitoring, MySQL backup
  21. 21. Не бывает «почти круглосуточно» Технические работы должны проходить незаметно для клиентов: Сервисные работы Замена оборудования Обновления системного ПО Обновления приложений
  22. 22. Сценарий 3: авария или плановые работы с базой Весь траффик переключается в один работающий датацентр CloudWatch определяет возросшую нагрузку на машины и добавляет их в соответствие с правилами для AutoScaling Приостанавливается мастер-мастер репликация Проводятся все необходимые работы с базой, на которую не идет нагрузка База включается в работу, восстанавливается репликация Траффик распределяется на оба датацентра Гасятся лишние машины, если средняя нагрузка стала ниже порогового значения
  23. 23. Real Time мониторинг – как узнавать о проблемах? Можно – так…
  24. 24. Real Time мониторинг – как узнавать о проблемах? Или – так…
  25. 25. Организация системы мониторинга Лучше – стандартные решения (Nagios, Zabbix и т.п.), а не самописные. Дежурная смена и/или мгновенные уведомления. Мониторить – всё. Но – аккуратно. Тысячи уведомлений будут бесполезны. Мониторить систему мониторинга. В идеальном мире – распределенная система мониторинга. Автоматизация типовых реакций.
  26. 26. Помимо стандартных - пишите свои тесты Пример для MySQL
  27. 27. Автоматизация типовых реакций Рост / падение LA – автоматическое масштабирование вверх / вниз Автоматический рестарт «сбойных» сервисов Автоматическое «удаление» проблемных машин Автоматическое восстановление репликации Автоматическое переключение траффика в случае аварии на уровне целого ДЦ
  28. 28. event handler # LA on the server define service{ use host_name service_description check_command event_handler } local-service ec2-54-227-28-75.compute-1.amazonaws.com Current Load check_nrpe_1arg!check_load! restart_phpfpms define command{ command_name restart_phpfpms command_line /usr/lib64/nagios/plugins/check_nrpe -H $HOSTADDRESS$ -c restart_phpfpm }
  29. 29. Мониторинг нетипичных характеристик Наличие бэкапов Срок делегирования доменов Срок действия SSL сертификатов Баланс у провайдера смс-уведомлений
  30. 30. Мониторинг веб-приложения Лог работы скрипта (>) – обновился за N часов Лог ошибок работы скрипта (2>) – должен быть пуст
  31. 31. Уведомления – как у нас Cкрипт, опрашивающий страницу «Problems» Шлем «дайджест» проблем, а не по одному сообщению на каждое событие Несколько уровней критичности событий Разные списки адресатов на разные события Повтор (через 15 минут, через 2 часа), чтобы не «потерять» уведомление ОК – если все стало хорошо
  32. 32. Аналитика
  33. 33. «Живая» система – много небольших запросов 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)
  34. 34. Аналитика - MySQL Одиночные медленные запросы отлавливаются просто. Сложнее мониторить общее состояние системы с большим количеством относительно быстрых запросов.
  35. 35. Поиск узких мест Pinba, XDebug, XHProf
  36. 36. Приложение всегда работает в условиях ограниченных ресурсов Постоянный feedback разработчикам – в автоматическом и полуавтоматическом режиме
  37. 37. Резюме Систему в облаке можно поддерживать, обходясь минимумом человеческих ресурсов • Выбирайте правильное облако – с максимально широким набором сервисов, API и т.п. • Ваше приложение должно быть готово к горизонтальному масштабированию • • • • Резервируйте все Обязательно используйте системы мониторинга Автоматизируйте все типовые действия Держите приложение в условиях ограниченных ресурсов и всегда давайте обратную связь разработчикам.
  38. 38. До 2012 года… Два основных продукта: Единственное, что требовало того или иного обслуживания – наш собственный сайт.
  39. 39. В настоящее время… файлы бэкап сканер безопасности CRM CDN видеозвонки push ??
  40. 40. Облачные сервисы Битрикс24 – SaaS «Корпоративный портал» Более 7000 наиболее активных порталов Ускорение сайта – интеграция с CDN Около 9000 сайтов Облачный бэкап Более 7500 сайтов Анонс новых сервисов осенью 2013
  41. 41. Примерно 2 стойки 42U – если без виртуализации Два человека – у которых админство не является основной деятельностью
  42. 42. Спасибо за внимание! Вопросы? Александр Демидов demidov@1c-bitrix.ru +7-926-521-3700 @demidov http://www.1c-bitrix.ru

×