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

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

Создание отказоустойчивых сайтов

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

Разные классы сайтов и веб-сервисов:

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

А нужна ли отказоустойчивость?

Почему сайт должен быть всегда доступен?

Клиенты и их лояльность (сайт недоступен – потеряны заказы).

Индексация сайта поисковыми роботами

Финансовые потери во время рекламных компаний

Стоимость контекстной рекламы

Не бывает«почти круглосуточно»

Технические работы должны проходить незаметно для клиентов:

Сервисные работы

Замена оборудования

Обновления системного ПО

Обновления приложений

Симптомы. Что видит Клиент.

URL сайта – не открывается, браузер висит

Открывается пустая белая страница

Отображается техническое сообщение об ошибке nginx,

apache

Браузер отображает свое сообщение об ошибке

При отправке заполненной формы (заказа) сайт сообщает

об ошибке и данные теряются

Начинают «глючить» и тормозить динамические элементы

сайта

Симптомы. Что видит Клиент.

При загрузке большого файла сайт сообщает об ошибке в

конце долгой процедуры

Веб-страница отображается не вся, искаженная, не

догружается

Изображения и другие ресурсы загружаются медленно/не

все

Система работает нестабильно, с ошибками и задержками.

Работать с сайтом – тяжело и неудобно.

Интернет-каналы

DNS

Веб-серверы

Кэш

Базы данных

Диски

Датацентр

Отказы инфраструктуры

Отказоустойчивая архитектура приложения

Готовимся, начиная с ТЗ:

Составляем перечень возможных отказов с приоритетами

Прогнозируем объем и характер нагрузки

«Учим» сайт адекватно реагировать на отказы и аварии

Используем веб-кластерные технологии платформы:

>1 серверов web-приложений

>1 баз данных

>1 memcached - серверов

Архитектура веб-кластера в одном ДЦ

Apache PHP

«1C-Битрикс: Управление сайтом» - кластерная редакция

Балансировщик

nginx(upstream module)

Сервер приложений 1

Apache

Primary



Сервер MySQL Master Сервер MySQL Slave

MySQL (Innodb/XtraDB) MySQL (Innodb/XtraDB)

DNS серверы

Secondary

PHP

Резервируем сервер web-приложений

Apache PHP





Apache

Primary





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





Apache

Primary





DNS серверы

Secondary

PHP

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

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


Через настройки платформы мы сделали эти сервисы -

надежными:

База данных

Кэш

Файлы и ресурсы

Приложение может полагаться на их высокую доступность.

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

Веб-сервер

База данных MySQLMASTER

«1С-Битрикс: Веб-кластер»

База данных MySQLSLAVE 1

База данных MySQLSLAVE N

База данных MySQLSLAVE …

SQL-балансировщик1С-Битрикс

Высокие требования к сети, связность серверов друг с другом

Балансировщик (клиентские запросы по HTTP)

Веб-сервер 1

memcached 1


memcached 1MySQLmaster

MySQLslave

Ручные операции для восстановления master’а MySQL

Балансировщик (клиентские запросы по HTTP)


memcached 1


memcached 1MySQLmaster

MySQLslave

Аварии на уровне целого датацентра или интернет-канала


Учимся выдерживать отказ MASTER-БД:

Локальный мастер-мастер с переключением IP-адреса

(скрипт или Pacemaker)

Локальный мастер + DRBD c переключением

Гео веб-кластер (active-passive) в другом ДЦ

Верстаем 2 красивые страницы-заглушки:

При ошибке соединения apache с БД (dbquery_error.php)

При недоступности apache/php-fpm за nginx

Отказал MySQL Master

Apache PHP





Apache

Primary





DNS серверы

Secondary

PHP

Особенности настройки MySQL:auto_increment_incrementauto_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

imag

es (c

lient

s)

imag

es (c

lient

s)

local cache

local cache

local cache

local cache

local cache

control cache: memcached

mysqld

mysqld

mysqld

mysqld

mysqld

mysqld

master-master replication

master-master replication

master-master replicationmysqld

mysqld

mysqld

mysqld

mysqld

mysqld

mysqld

mysqld

mysqld

mysqld

mysqld

mysqld






Web 2

local cache

Принципы разработки

Не используем в коде внешние ресурсы - синхронно:

Обращение к внешним сайтам:

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 -> ord('X') ../trace.php:5

0.0009 117584 -> 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)

Умеет быстро восстанавливаться после сбоя

Удерживается в зеленой зоне – внешними инструментами,

регулярным аудитом и мониторингом.

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

Спасибо за внимание! Вопросы?

Александр Демидов

[email protected]

@demidov

Александр Сербул

[email protected]

@AlexSerbul

Подходите к нам во время конференции – будем рады «живому» общению, проконсультируем по темам высоких нагрузок и отказоустойчивости

Задавайте вопросы в твиттере с хэштегом #bitrixconf

mailto:[email protected]

mailto:[email protected]

Documents

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