Александр Сербул Руководитель направления контроля качества интеграции и внедрений

1. Создание отказоустойчивых сайтов Александр Демидов Руководитель направления арендных решений Александр Сербул Руководитель направления контроля качества интеграции и внедрений

2. А нужна ли отказоустойчивость? Разные классы сайтов и веб-сервисов: Домашние странички, личные блоги и т.п. «Продающие» сайты (интернет-магазины) Имиджевые сайты (в том числе и корпоративные) «Businesscriticalapplication» - веб-сервисы, использующиеся в работе (CRM, учет, таск-менеджмент, почта и т.п.)

3. Почему сайт должен быть всегда доступен? Клиенты и их лояльность (сайт недоступен – потеряны заказы). Индексация сайта поисковыми роботами Финансовые потери во время рекламных компаний Стоимость контекстной рекламы

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

5. Симптомы. Что видит Клиент. URL сайта – не открывается, браузер висит Открывается пустая белая страница Отображается техническое сообщение об ошибке nginx, apache Браузер отображает свое сообщение об ошибке При отправке заполненной формы (заказа) сайт сообщает об ошибке и данные теряются Начинают «глючить» и тормозить динамические элементы сайта

6. Симптомы. Что видит Клиент. При загрузке большого файла сайт сообщает об ошибке в конце долгой процедуры Веб-страница отображается не вся, искаженная, не догружается Изображения и другие ресурсы загружаются медленно/не все Система работает нестабильно, с ошибками и задержками. Работать с сайтом – тяжело и неудобно.

7. Отказы инфраструктуры • Интернет-каналы • DNS • Веб-серверы • Кэш • Базы данных • Диски • Датацентр

8. Отказоустойчивая архитектура приложения Готовимся, начиная с ТЗ: Составляем перечень возможных отказов с приоритетами Прогнозируем объем и характер нагрузки «Учим» сайт адекватно реагировать на отказы и аварии Используем веб-кластерные технологии платформы: >1 серверов web-приложений >1баз данных >1 memcached- серверов

9. Архитектура веб-кластера в одном ДЦ DNS серверы Primary Secondary Балансировщик nginx (upstream module) Сервер приложений 1 Сервер приложений 2 «1C-Битрикс: Управление сайтом» - кластерная редакция «1C-Битрикс: Управление сайтом» - кластерная редакция Apache PHP Apache PHP Сервер MySQLSlave Сервер MySQL Master MySQL (Innodb/XtraDB) MySQL (Innodb/XtraDB)

10. Резервируем сервер web-приложений upstream backend { server app1.example.com max_fails=3 fail_timeout=30s; server app2.example.com max_fails=3 fail_timeout=30s; } … proxy_next_upstream error timeout http_500 http_502 http_503 http_504; DNS серверы Primary Secondary Балансировщик nginx (upstream module) Сервер приложений 1 Сервер приложений 2 «1C-Битрикс: Управление сайтом» - кластерная редакция «1C-Битрикс: Управление сайтом» - кластерная редакция Apache PHP Apache PHP Сервер MySQLSlave Сервер MySQL Master MySQL (Innodb/XtraDB) MySQL (Innodb/XtraDB)

11. Резервируем базу данных

12. Отказал/отстал MySQL Slave DNS серверы Primary Secondary Балансировщик nginx (upstream module) Сервер приложений 1 Сервер приложений 2 «1C-Битрикс: Управление сайтом» - кластерная редакция «1C-Битрикс: Управление сайтом» - кластерная редакция Apache PHP Apache PHP Сервер MySQLSlave Сервер MySQL Master MySQL (Innodb/XtraDB) MySQL (Innodb/XtraDB)

13. Резервируем кэш

14. Резервируем файлы и каналы

15. Отказоустойчивая архитектура приложения Через настройки платформы мы сделали эти сервисы - надежными: База данных Кэш Файлы и ресурсы Приложение может полагаться на их высокую доступность.

16. «Узкие» места

17. Высокие требования к сети, связность серверов друг с другом Веб-сервер «1С-Битрикс: Веб-кластер» SQL-балансировщик1С-Битрикс База данных MySQLSLAVE 1 База данных MySQLSLAVE … База данных MySQLSLAVE N База данных MySQLMASTER

18. Ручные операции для восстановления master’а MySQL Балансировщик (клиентские запросы по HTTP) Веб-сервер 1 Веб-сервер 2 memcached 1 MySQL master MySQL slave memcached 1

20. Аварии на уровне целого датацентра или интернет-канала Балансировщик (клиентские запросы по HTTP) Веб-сервер 1 Веб-сервер 2 memcached 1 MySQL master MySQL slave memcached 1

21. Отказоустойчивая архитектура приложения Учимся выдерживать отказ MASTER-БД: Локальный мастер-мастер с переключением IP-адреса (скрипт или Pacemaker) Локальный мастер + DRBD c переключением Гео веб-кластер (active-passive) в другом ДЦ Верстаем 2 красивые страницы-заглушки: При ошибке соединения apache с БД (dbquery_error.php) При недоступности apache/php-fpm за nginx

22. Отказал MySQL Master DNS серверы Primary Secondary Балансировщик nginx (upstream module) Сервер приложений 1 Сервер приложений 2 «1C-Битрикс: Управление сайтом» - кластерная редакция «1C-Битрикс: Управление сайтом» - кластерная редакция Apache PHP Apache PHP Сервер MySQLSlave Сервер MySQL Master MySQL (Innodb/XtraDB) MySQL (Innodb/XtraDB)

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

24. Вывод: резервировать надо все Dynamic Static Dynamic Static CDN CDN 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 local cache local cache local cache local cache local cache 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

25. Принципы разработки Не используем в коде внешние ресурсы - синхронно: Обращение к внешним сайтам: file_get_contents('http://www.example.com/') К облачным сервисам: s3, google storage - fsockopen Локировка файлов Настраиваем небольшой таймаут или забираем ресурсы и кэшируем отдельным процессом (cron). Не ворочаем в памяти огромными массивами, Dom XML… При обработке картинок – предварительно прикидываем объем памяти и не выходим из него.

26. А нужно ли всегда знать о «состоянии здоровья» сайта? Вроде работает… Тормозит – «пнем» админа, чтобы что-то там перезапустил, это всегда помогает Если что, можно быстренько что-то дописать на «бою»

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

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

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

30. Мониторинг «железа» Рейды S.M.A.R.T. – диск возможно скоро «умрет» Утилиты вендора – внутренние аппаратные тесты Периодическое тестирование железа в оффлайне Имеем «запчасти» (блоки питания, вентиляторы …) или знаем где их быстро найти

31. Мониторинг операционной системы Место на дисках Очередь выполнения Размер и использование swap И т.д.

32. Подробная диагностика Полезные утилиты: atop, ps, pstree, apachetop, innotop, netstat, iostat, vmstat…

33. Если нет админа… • Аутсорс • Внешние системы: • http://host-tracker.com/ • Яндекс.Метрика • И т.д.

34. Аналитика

35. Удерживаем приложение в «зеленой» зоне Постоянно анализируем логиnginx, apache: awk, grep Ведем дополнительные логи - CPU user/system%, memory usage, логи приложения и компонентов Фиксируем в логах nginxвремя отработки upstream - $upstream_response_time Исследуем причины медленной работы PHP – php-fpm slowlog

36. Лог медленных запросов php-fpm! [29-Jan-2013 13:25:58] [pool www1] pid 9434 script_filename = /var/www/html//index.php [0x00000000016796d0] fgets() /var/www/html/bitrix/modules/main/tools.php:4722 [0x0000000001679060] Query() /var/www/html/bitrix/modules/main/tools.php:4644 [0x0000000001678d50] HTTPQuery() /var/www/html/bitrix/modules/main/tools.php:4593 [0x0000000001678af8] Download() /var/www/html/bitrix/modules/clouds/classes/general/storage_service_s3.php:337 [0x0000000001678980] DownloadToFile() /var/www/html/bitrix/modules/clouds/classes/general/storage_bucket.php:79 [0x0000000001677750] DownloadToFile() /var/www/html/bitrix/modules/clouds/classes/general/storage.php:202 [0x00007ffffeb47e00] OnBeforeResizeImage() unknown:0 [0x0000000001676a48] call_user_func_array() /var/www/html/bitrix/modules/main/classes/general/module.php:702 [0x00000000016746b8] ExecuteModuleEventEx() /var/www/html/bitrix/modules/main/classes/general/file.php:1354 [0x00000000016741e8] ResizeImageGet() …

37. Xdebug Сделайте сайт – прозрачным изнутри Учимся снимать и понимать трейс страниц: ini_set('xdebug.collect_params', 3); xdebug_start_trace(); … xdebug_stop_trace(); TRACE START [2013-01-2914:37:13] 0.0003 114112 -> {main}() ../trace.php:0 0.0004 114272 -> str_split('Xdebug') ../trace.php:8 0.0007 117424 -> ret_ord('X') ../trace.php:10 0.0007 117584 -> ord('X') ../trace.php:5 0.0009 117584 -> ret_ord('d') ../trace.php:10 …

38. Локировка сессии В PHP объект сессии лочится страницей на все время ее выполнения В rich ajaxсайтах могут начаться локировки – || запросы под одной сессией, становятся в очередь Учим страницы выполняться быстрее, cronдля заданий При авариях поможет скрипт: lsof |  awk ' /sess/ { load_sessions[$9]++; if (load_sessions[$9]>max_sess_link_count){ max_sess_link_count = load_sessions[$9];  max_sess_link_name = $9; }; if ($4 ~ /.*uW$/ ){locked_id[$9]=$2}; } END {printmax_sess_link_count, max_sess_link_name,locked_id[max_sess_link_name]; if (locked_id[max_sess_link_name] && max_sess_link_count>10) { r=system("kill "locked_id[max_sess_link_name]); if (!r) print "Lockingprocess "locked_id[max_sess_link_name]" killed" }}'

39. Смотрим в БД Собираем и анализируем ошибки SQL: define("LOG_FILENAME", "/var/log/db_error.log"); Наблюдаем за запросами в БД – лог медленных запросов MySQL, innotop. Используем стандартные возможности Битрикс: «Настройки/Производительность/Сервер БД»

40. Мониторим границы приложения в реальном времени Pinba, xhprof

41. Быстрое восстановление после аварии Резервируем данные клиентов и настройки сайта, учимся их быстро восстанавливать. Нужно бэкапить файлы и базу данных Это нужно делать постоянно, а не перед аварией  Нужно бэкапитьконфиги и настройки серверов и софта Полезно проводить учения по восстановлению системы Нужно уметь восстанавливаться быстро и уверенно Восстановление можно частично автоматизировать

42. Бэкапим файлы Веб-сервер Сервер бэкапов «1C-Битрикс: Управление сайтом» tar.gz rdiff-backup Регулярный бэкап Nginx Apache PHP rsync, csync2 bacula Файлы, изображения, документы, контент, меню, права доступа СнепшотыLVM Регулярный бэкап Образы виртуальной машины Журналируемая ФС Журналируемая ФС Диски (raid1, 5) Диски (raid1) Amazon Web Services Снепшоты дисков, рейдов Снепшоты целых машин

43. Бэкапим БД Регулярный логический бэкап Сервер бэкапов MySQL Slave mysqldump Репликация Регулярный бэкап:снепшоты PerconaXtrabackup СнепшотыLVM Сервер БД Образы виртуальной машины MySQL Журналируемая ФС Диски (raid1, 5) Информация проекта в таблицах базы данных Журналируемая ФС Диски (raid10, кэш записи, батарейка) Регулярный бэкап:снепшоты Amazon Web Services Снепшоты дисков, рейдов с БД Снепшоты целых машин

44. Резюме Отказоустойчивое приложение: Использует веб-кластерные технологии Минимально зависит от внешних сервисов (кроме БД, apc и memcached) Умеет быстро восстанавливаться после сбоя Удерживается в зеленой зоне– внешними инструментами, регулярным аудитом и мониторингом.

45. Отказоустойчивый сайт - всегда в форме!

46. Спасибо за внимание! Вопросы? Александр Сербул serbul@1c-bitrix.ru @AlexSerbul Александр Демидов demidov@1c-bitrix.ru @demidov Подходите к нам во время конференции – будем рады «живому» общению, проконсультируем по темам высоких нагрузок и отказоустойчивости Задавайте вопросы в твиттере с хэштегом#bitrixconf