Экономика отказоустойчивости и резервирование инфраструктуры Александр Демидов «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