Экономика отказоустойчивости и резервирование - 1С

Экономика отказоустойчивости и
резервирование инфраструктуры
Александр Демидов
«1С-Битрикс»
О чем будем говорить
Кому нужна отказоустойчивость
Несколько кейсов с расчетами «в деньгах»
Очевидные (и не очень) потери от простоев
Точки отказа в инфраструктуре
Защищает ли SLA провайдера
Выбор инфраструтуры
Решаем сами задачи резервирования
Два заблуждения
1. Мы «маленькие», нам думать про
отказоустойчивость ни к чему, и так забот хватает.
2. Мы «большие», у нас 100500 серверов, у нас с
отказоустойчивостью точно все хорошо.
Страшилки?
О резервировании и
отказоустойчивости, как
правило, начинают
задумываться, только
столкнувшись на практике с
реальными потерями и начав их
считать
«Одноклассники»
4-6 апреля 2013
2.1 млрд. просмотров в сутки до сбоя
1.6 млрд. – в среднем в неделю сбоя
1.9 млрд. – после сбоя
http://corp.mail.ru/adv/price_odnoklassniki.htm
"Испорченный файл был выложен через
централизованную систему управления серверами.
В итоге это повлекло за собой необходимость
перезапуска большой части наших серверов и
переустановку операционной системы", — заявила
пресс-секретарь "Одноклассников" Мария Лапук
18 февраля 2013
Оборот за 2012 год - $379 млн.
До суток простоя – более $1 млн.
Посчитаем стоимость «новой
ИТ-системы»
Оборот за 2012 год - $132 млн. (Digital Guru)
7 суток простоя – около $2.5 млн.
А что с поиском?
Потери и риски
Прямые потери заказов
«Выпадание» из поиска
Финансовые потери во время
рекламных компаний – вы платите
за «холостые» клики
Стоимость контекстной рекламы
Даже если сайт доступен, но
работает медленно, его позиции в
результатах поиска будут ниже
(учет поведенческих факторов)
Репутационные риски
Отказы инфраструктуры
Интернет-каналы
DNS
Серверы
Диски
Датацентры
Спасет ли SLA провайдера?
Ни один SLA не покроет вашу упущенную выгоду
(прибыль), только расходы на хостинг
Наиболее часто встречается гарантия 99.9%
доступности в SLA
Это – около 9 часов простоя в год
Небольшие слоты (до 5 минут) никто не считает
Ребут сервера, скорее всего, не попадает под SLA.
А если это база данных, она может стартовать
несколько часов после аварийного завершения.
«Хитрости» SLA
$25 / месяц
Elastic Load Balancing
Web 1
CloudWatch
+
AutoScaling
Web 2
Web N
…
mysqld
control cache: memcached
master-master replication
mysqld
mysqld
control cache: memcached
mysqld
master-master replication
mysqld
master-master replication
control cache: memcached
mysqld
Web N
…
mysqld
mysqld
mysqld
CloudWatch
+
AutoScaling
Web 2
S3
mysqld
mysqld
Web 1
mysqld
mysqld
mysqld
mysqld
control cache: memcached
mysqld
control cache: memcached
mysqld
mysqld
control cache: memcached
$5000 / месяц
Эксплуатация: выбор инфраструктуры
Риски:
Взять слишком много и переплатить (не можем заранее
спрогнозировать потребление ресурсов)
Взять слишком мало и «просесть» по производительности
Безопасность (если в штате нет толкового системного
администратора)
Надежность (как резервировать доступность на уровне
датацентра?)
Сетевая доступность
Виртуальный (shared) хостинг
Это – всегда «общежитие».
Самый простой вариант
Хороший хостинг снимает
практически всю головную
боль (бэкапы,
резервирование и т.п.)
Мало настроек
Мало ресурсов
Мало «путей отступления»
Архитектура веб-кластера в одном ДЦ
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)
Резервируем кэш
Резервируем файлы и каналы
«Узкие» места
Не зарезервирована «точка входа»
Балансировщик (клиентские запросы
по HTTP)
Веб-сервер 1
memcached 1
MySQL
master
Веб-сервер 2
MySQL
slave
memcached 1
Высокие требования к сети, связность
серверов друг с другом
Веб-сервер
«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) в другом ДЦ
Отказал 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%
Резервирование на уровне ДЦ
Чтобы избежать «холостой» работы половины ресурсов,
каждый ДЦ обслуживает свою группу клиентов
Load Balancing
Web 1
CloudWatch
+
AutoScaling
Web 2
Load Balancing
Web N
Web 1
CloudWatch
+
AutoScaling
Web 2
…
…
mysqld
mysqld
mysqld
control cache: memcached
master-master replication
mysqld
master-master replication
mysqld
master-master replication
control cache: memcached
mysqld
mysqld
control cache: memcached
mysqld
mysqld
mysqld
mysqld
Web N
mysqld
control cache: memcached
mysqld
mysqld
mysqld
mysqld
mysqld
control cache: memcached
mysqld
control cache: memcached
Резюме
Ваш сайт должен быть максимально доступен – в
разумных пределах
•
Резервируйте критичные узлы – исходя из необходимости и
экономики
•
Доступность проекта зависит не только от инфраструктуры, но и
от кода, внешних сервисов и т.п.
•
Важно не только запустить проект, но и грамотно его
эксплуатировать – иметь систему мониторинга
•
Имейте резервные копии и умейте быстро из них
восстанавливаться
Спасибо за внимание!
Вопросы?
Александр Демидов
demidov@1c-bitrix.ru
+7-926-521-3700
@demidov
http://www.1c-bitrix.ru