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

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

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

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

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

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

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

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

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

Резервируем сервер web-приложений Apache PHP «1C-Битрикс: Управление сайтом» - кластерная редакция Балансировщик nginx (upstream module) nginx (upstream module) Сервер приложений 1 Apache Primary «1C-Битрикс: Управление сайтом» - кластерная редакция Сервер приложений 2 Сервер MySQL Master Сервер MySQL Slave MySQL (Innodb/XtraDB) DNS серверы Secondary PHP 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;

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

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

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

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

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

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

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

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

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

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

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

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

Elastic Load Balancing Web 1 Elastic Load Balancing Dynamic Web N … CloudWatch + AutoScaling Web 1 Web 2 Web N … CloudWatch + AutoScaling Вывод: резервировать надо все S3 management, monitoring, backup Static CDN js, css DynamicStatic CDN js, css images (clients) local cache control cache: memcached mysqld master-master replication mysqld control cache: memcached Web 2 local cache

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

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

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

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

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

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

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

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

Если нет админа… Аутсорс Внешние системы: Яндекс.Метрика И т.д.

Аналитика

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

Лог медленных запросов php-fpm! [29-Jan :25:58] [pool www1] pid 9434 script_filename = /var/www/html//index.php [0x d0] fgets() /var/www/html/bitrix/modules/main/tools.php:4722 [0x ] Query() /var/www/html/bitrix/modules/main/tools.php:4644 [0x d50] HTTPQuery() /var/www/html/bitrix/modules/main/tools.php:4593 [0x af8] Download() /var/www/html/bitrix/modules/clouds/classes/general/storage_service_s3.php:337 [0x ] DownloadToFile() /var/www/html/bitrix/modules/clouds/classes/general/storage_bucket.php:79 [0x ] DownloadToFile() /var/www/html/bitrix/modules/clouds/classes/general/storage.php:202 [0x00007ffffeb47e00] OnBeforeResizeImage() unknown:0 [0x a48] call_user_func_array() /var/www/html/bitrix/modules/main/classes/general/module.php:702 [0x b8] ExecuteModuleEventEx() /var/www/html/bitrix/modules/main/classes/general/file.php:1354 [0x e8] ResizeImageGet() …

Xdebug Сделайте сайт – прозрачным изнутри Учимся снимать и понимать трейс страниц: ini_set('xdebug.collect_params', 3); xdebug_start_trace(); … xdebug_stop_trace(); TRACE START [ :37:13] > {main}()../trace.php: > str_split('Xdebug')../trace.php: > ret_ord('X')../trace.php: > ord('X')../trace.php: > ret_ord('d')../trace.php:10 …

Локировка сессии В 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 {print max_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 "Locking process "locked_id[max_sess_link_name]" killed" }}'

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

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

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

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

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

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

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

Спасибо за внимание! Вопросы? Александр Александр Подходите к нам во время конференции – будем рады «живому» общению, проконсультируем по темам высоких нагрузок и отказоустойчивости Задавайте вопросы в твиттере с хэштегом #bitrixconf