bitrix-failower-final PPTX, 4 МБ

Создание отказоустойчивых сайтов
Александр Демидов
Руководитель направления арендных решений
Александр Сербул
Руководитель направления контроля качества интеграции и внедрений
А нужна ли
отказоустойчивость?
Разные классы сайтов и вебсервисов:
Домашние странички, личные блоги
и т.п.
«Продающие» сайты (интернетмагазины)
Имиджевые сайты (в том числе и
корпоративные)
«Business critical application» - вебсервисы, использующиеся в работе
(CRM, учет, таск-менеджмент, почта
и т.п.)
Почему сайт должен быть
всегда доступен?
Клиенты и их лояльность
(сайт недоступен –
потеряны заказы).
Индексация сайта
поисковыми роботами
Финансовые потери во
время рекламных
компаний
Стоимость контекстной
рекламы
Не бывает
«почти круглосуточно»
Технические работы должны
проходить незаметно для
клиентов:
Сервисные работы
Замена оборудования
Обновления системного
ПО
Обновления приложений
Симптомы. Что видит Клиент.
URL сайта – не открывается, браузер висит
Открывается пустая белая страница
Отображается техническое сообщение об ошибке nginx,
apache
Браузер отображает свое сообщение об ошибке
При отправке заполненной формы (заказа) сайт сообщает
об ошибке и данные теряются
Начинают «глючить» и тормозить динамические элементы
сайта
Симптомы. Что видит Клиент.
При загрузке большого файла сайт сообщает об ошибке в
конце долгой процедуры
Веб-страница отображается не вся, искаженная, не
догружается
Изображения и другие ресурсы загружаются медленно/не
все
Система работает нестабильно, с ошибками и задержками.
Работать с сайтом – тяжело и неудобно.
Отказы инфраструктуры
Интернет-каналы
DNS
Веб-серверы
Кэш
Базы данных
Диски
Датацентр
Отказоустойчивая архитектура приложения
Готовимся, начиная с ТЗ:
Составляем перечень возможных отказов с приоритетами
Прогнозируем объем и характер нагрузки
«Учим» сайт адекватно реагировать на отказы и аварии
Используем веб-кластерные технологии платформы:
>1 серверов web-приложений
>1 баз данных
>1 memcached - серверов
Архитектура веб-кластера в одном ДЦ
DNS серверы
Primary
Secondary
Балансировщик
nginx
(upstream module)
Сервер приложений 1
«1C-Битрикс: Управление сайтом» кластерная редакция
Apache
PHP
Сервер MySQL Master
MySQL (Innodb/XtraDB)
Сервер приложений 2
«1C-Битрикс: Управление сайтом» кластерная редакция
Apache
PHP
Сервер MySQL Slave
MySQL (Innodb/XtraDB)
Резервируем сервер web-приложений
upstream backend {
DNS серверы
Primary
server app1.example.com max_fails=3
Secondary
fail_timeout=30s;
server app2.example.com max_fails=3
fail_timeout=30s;
Балансировщик
}
…
nginx
(upstream module)
proxy_next_upstream error timeout http_500 http_502
http_503 http_504;
Сервер приложений 1
«1C-Битрикс: Управление сайтом» кластерная редакция
Apache
PHP
Сервер MySQL Master
MySQL (Innodb/XtraDB)
Сервер приложений 2
«1C-Битрикс: Управление сайтом» кластерная редакция
Apache
PHP
Сервер MySQL Slave
MySQL (Innodb/XtraDB)
Резервируем базу данных
Отказал/отстал MySQL Slave
DNS серверы
Primary
Secondary
Балансировщик
nginx
(upstream module)
Сервер приложений 1
«1C-Битрикс: Управление сайтом» кластерная редакция
Apache
PHP
Сервер MySQL Master
MySQL (Innodb/XtraDB)
Сервер приложений 2
«1C-Битрикс: Управление сайтом» кластерная редакция
Apache
PHP
Сервер MySQL Slave
MySQL (Innodb/XtraDB)
Резервируем кэш
Резервируем файлы и каналы
Отказоустойчивая архитектура приложения
Через настройки платформы мы сделали эти сервисы надежными:
База данных
Кэш
Файлы и ресурсы
Приложение может полагаться на их высокую доступность.
«Узкие» места
Высокие требования к сети, связность
серверов друг с другом
Веб-сервер
«1С-Битрикс: Веб-кластер»
SQL-балансировщик
1С-Битрикс
База данных MySQL
MASTER
База данных MySQL
SLAVE 1
База данных MySQL
SLAVE …
База данных MySQL
SLAVE N
Ручные операции для восстановления
master’а MySQL
Балансировщик (клиентские запросы
по HTTP)
Веб-сервер 1
memcached 1
MySQL
master
Веб-сервер 2
MySQL
slave
memcached 1
Аварии на уровне целого датацентра или
интернет-канала
Балансировщик (клиентские запросы
по HTTP)
Веб-сервер 1
memcached 1
MySQL
master
Веб-сервер 2
MySQL
slave
memcached 1
Отказоустойчивая архитектура приложения
Учимся выдерживать отказ MASTER-БД:
Локальный мастер-мастер с переключением IP-адреса
(скрипт или Pacemaker)
Локальный мастер + DRBD c переключением
Гео веб-кластер (active-passive) в другом ДЦ
Верстаем 2 красивые страницы-заглушки:
При ошибке соединения apache с БД (dbquery_error.php)
При недоступности apache/php-fpm за nginx
Отказал MySQL Master
DNS серверы
Primary
Secondary
Балансировщик
nginx
(upstream module)
Сервер приложений 1
«1C-Битрикс: Управление сайтом» кластерная редакция
Apache
PHP
Сервер MySQL Master
MySQL (Innodb/XtraDB)
Сервер приложений 2
«1C-Битрикс: Управление сайтом» кластерная редакция
Apache
PHP
Сервер MySQL Slave
MySQL (Innodb/XtraDB)
Используем master-master
репликацию в MySQL
Особенности настройки MySQL:
auto_increment_increment
auto_increment_offset
Базы в разных датацентрах синхронны, при этом независимы друг от
друга: потеря связности между датацентрами может составлять часы,
данные синхронизируются после восстановления.
Необходимо группировать пользователей для работы в одном
датацентре за счет управления балансировщиком.
Если сессии храним в базе, то не реплицируем их между серверами изза большого траффика и возможных «локов»:
SET sql_log_bin = 0 … или …
replicate-wild-ignore-table = %.b_sec_session%
Вывод: резервировать надо все
Static
Static
CDN
js, css
Elastic Load Balancing
Web 1
Web 2
local
cache
local
cache
CloudWatch
+
AutoScaling
…
mysqld
control cache: memcached
js, css
Elastic Load Balancing
Web 2
local
cache
local
cache
local
cache
S3
mysqld
master-master replication
mysqld
master-master replication
control cache: memcached
mysqld
mysqld
mysqld
control cache: memcached
CloudWatch
+
AutoScaling
…
local
cache
mysqld
mysqld
mysqld
mysqld
mysqld
control cache: memcached
management,
monitoring,
backup
Web N
mysqld
mysqld
mysqld
control cache: memcached
CDN
Web 1
master-master replication
mysqld
Dynamic
Web N
mysqld
mysqld
images (clients)
images (clients)
Dynamic
mysqld
control cache: memcached
Принципы разработки
Не используем в коде внешние ресурсы - синхронно:
Обращение к внешним сайтам:
file_get_contents('http://www.example.com/')
К облачным сервисам: 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…
Если нет админа…
Аутсорс
Внешние системы:
http://host-tracker.com/
Яндекс.Метрика
И т.д.
Аналитика
Удерживаем приложение в «зеленой» зоне
Постоянно анализируем логи nginx, apache: awk, grep
Ведем дополнительные логи - CPU user/system%, memory
usage, логи приложения и компонентов
Фиксируем в логах nginx время отработки upstream $upstream_response_time
Исследуем причины медленной работы PHP – php-fpm
slowlog
Лог медленных запросов 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()
…
Xdebug
Сделайте сайт – прозрачным изнутри
Учимся снимать и понимать трейс страниц:
ini_set('xdebug.collect_params', 3);
xdebug_start_trace();
…
xdebug_stop_trace();
TRACE START [2013-01-29 14: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
0.0009
117584
…
-> ord('X') ../trace.php:5
-> 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
Быстрое восстановление после аварии
Резервируем данные клиентов и настройки сайта, учимся их
быстро восстанавливать.
Нужно бэкапить файлы и базу данных
Это нужно делать постоянно, а не перед аварией 
Нужно бэкапить конфиги и настройки серверов и софта
Полезно проводить учения по восстановлению системы
Нужно уметь восстанавливаться быстро и уверенно
Восстановление можно частично автоматизировать
Бэкапим файлы
Веб-сервер
Сервер бэкапов
tar.gz
«1C-Битрикс: Управление сайтом»
rdiff-backup
Nginx
Apache
PHP
Файлы, изображения, документы, контент,
меню, права доступа
Журналируемая ФС
Диски (raid1)
rsync, csync2
Регулярный
бэкап
bacula
Снепшоты LVM
Образы виртуальной машины
Журналируемая ФС
Диски (raid1, 5)
Amazon Web Services
Снепшоты дисков, рейдов
Снепшоты целых машин
Бэкапим БД
Сервер бэкапов
MySQL Slave
Регулярный
логический бэкап
mysqldump
Репликация
Percona Xtrabackup
Снепшоты LVM
Сервер БД
Образы виртуальной машины
Журналируемая ФС
MySQL
Диски (raid1, 5)
Информация проекта в таблицах базы данных
Журналируемая ФС
Диски (raid10, кэш записи, батарейка)
Amazon Web Services
Регулярный
бэкап: снепшоты
Снепшоты дисков, рейдов с БД
Снепшоты целых машин
Резюме
Отказоустойчивое приложение:
Использует веб-кластерные технологии
Минимально зависит от внешних сервисов (кроме БД, apc
и memcached)
Умеет быстро восстанавливаться после сбоя
Удерживается в зеленой зоне – внешними инструментами,
регулярным аудитом и мониторингом.
Отказоустойчивый сайт - всегда в форме!
Спасибо за внимание!
Вопросы?
Александр Сербул
Александр Демидов
serbul@1c-bitrix.ru
demidov@1c-bitrix.ru
@AlexSerbul
@demidov
Подходите к нам во время конференции – будем рады
«живому» общению, проконсультируем по темам
высоких нагрузок и отказоустойчивости
Задавайте вопросы в твиттере с хэштегом #bitrixconf