Как жить в облаке почти без админов: мониторинг и эксплуатация сотен виртуальных машин силами трех человек

Как жить в облаке почти без админов:
мониторинг и эксплуатация сотен
виртуальных машин силами трех человек
Александр Демидов,
«1С-Битрикс»

Запуск нового продукта: как, где, какие условия?
Почему «облако»? И почему именно AWS?
Как соблюдать 242-ФЗ, раз у Амазона ДЦ в России нет?
Что из сервисов Амазона в итоге делали сами?
Как всё мониторить?
Как организовать коммуникации между разработчиками, тестировщиками,
админами?

как все начиналось…

«Битрикс24»
Новый SaaS сервис – как коммерческие, так и «бесплатные» пользователи
Минимизация расходов на эксплуатацию и снижение финансовых рисков на
старте проекта
Масштабирование при росте нагрузки и обратное масштабирование
Надежность – обеспечение SLA
Работа с разными рынками: США, Европа, Россия
Есть несколько задач на старте и в процессе работы

Выбор платформы для разворачивания инфраструктуры
Минусы размещения на собственном оборудовании:
«Когда мы только начинали работу над стартапом (FriendFeed), нам нужно было решить,
покупать собственные серверы или же выбрать одного из «облачных» хостинг-провайдеров –
таких как Amazon (AWS). Мы выбрали первое – решили приобрести собственные серверы.
Оглядываясь назад, я думаю, что это было большой ошибкой»
Брет Тейлор
технический директор Facebook
Необходимы вложения в инфраструктуру на старте проекта
Сложность масштабирования
Сложность администрирования (в случае размещения в территориально удаленных
датацентрах)
Создание всех сопутствующих сервисов с нуля

Amazon Web Services
• Некоторый опыт работы с
Amazon
• Несколько территориально
распределенных ДЦ
• Большой выбор готовых
сервисов

Можно много и быстро пробовать!

Web – автоматическое масштабирование
CloudWatch + Auto Scaling
Web 1
Очень высокая посещаемость
Elastic Load Balancing
Web 2 Web N
…
Используем связку Elastic Load Balancing + CloudWatch + Auto Scaling

Web – автоматическое масштабирование
Автоматически стартуют новые машины, если средняя нагрузка CPU превышает заданный верхний порог
Автоматически останавливаются и выводятся из эксплуатации, если средняя нагрузка опускается ниже
заданного нижнего порога

Экономим – spot instances
CloudWatch + Auto Scaling (spot)
Web 1
Очень высокая посещаемость
Web 2 Web N
…
CloudWatch + Auto Scaling (on demand)
Web 1 Web N
…

Используем master-master репликацию в MySQL
Особенности настройки MySQL:
auto_increment_increment
auto_increment_offset
Базы в разных датацентрах синхронны, при этом независимы друг от друга:
потеря связности между датацентрами может составлять часы, данные
синхронизируются после восстановления.
Пользователь и все сотрудники этой компании работают в одном датацентре.

Резервирование на уровне датацентра
Elastic
Load Balancing
MySQL
master
Web 1
Elastic
Load Balancing
Web 2 Web N
… S3
management,
monitoring,
MySQL backup
Датацентр 1 в
регионе US East
(Virginia)
Мониторинг и
масштабирование –
CloudWatch +
AutoScaling
master-master
репликация
MySQL
master
Web 1 Web 2 Web N
…
(Virginia)
CloudWatch +
AutoScaling

Сценарий: авария на одной или нескольких веб-нодах
MySQL
master
Elastic
Load Balancing
Web N
…Web 1 Web 2
MySQL
master
Web 1 Web 2 Web N
…
master-master
S3
management,
monitoring,
MySQL backup
(Virginia)
CloudWatch +
AutoScaling
(Virginia)
CloudWatch +
AutoScaling

Сценарий: авария на одной или нескольких веб-нодах
Load Balancing определяет вышедшие из строя машины
Исходя из заданных параметров группы балансировки, автоматически
восстанавливается нужное количество машин

Сценарий: плановые работы с базой или авария всего ДЦ
MySQL
master
Elastic
Load Balancing
Web N
…Web 1 Web 2
MySQL
master
Web 1 Web 2 Web N
…
master-master
S3
management,
monitoring,
MySQL backup
(Virginia)
CloudWatch +
AutoScaling
(Virginia)
CloudWatch +
AutoScaling

Сценарий: авария или плановые работы с базой
Весь траффик переключается в один работающий датацентр
CloudWatch определяет возросшую нагрузку на машины и добавляет их в
соответствие с правилами для AutoScaling
Приостанавливается мастер-мастер репликация
Проводятся все необходимые работы с базой, на которую не идет нагрузка
База включается в работу, восстанавливается репликация
Траффик распределяется на оба датацентра
Гасятся лишние машины, если средняя нагрузка стала ниже порогового значения

Архитектура Битрикс24
Web 1
Dynamic
HTTPS
*.com/*.de
Web N
…
CloudWatch
+
AutoScaling
Web 1 Web 2 Web N
…
CloudWatch
+
AutoScaling
S3
management,
monitoring,
backup
Static
HTTPS
*.com/*.de
CDN (Amazon CloudFront)
js, css
Dynamic
HTTPS
*.ru
Static
HTTPS
*.ru
CDN (CDNvideo)
js, css
images(clients)
images(clients)
local
cache
(APC)
local
cache
(APC)
local
cache
(APC)
local
cache
(APC)
local
cache
(APC)
control cache: memcached
mysqld
mysqld
mysqld
mysqld
mysqld
mysqld
master-master replication
mysqld
mysqld
mysqld
mysqld
mysqld
mysqld
mysqld
mysqld
mysqld
mysqld
mysqld
mysqld
Web 2
local
cache
(APC)

Все веб-ноды идентичны и не
зависимы друг от друга, в случае
аварии автоматически стартуют
новые.
Два датацентра синхронизированы
друг с другом и равноценно
обслуживают клиентов. В случае
аварии на уровне датацентра или
плановых работ с базой, траффик
прозрачно для клиентов
переключается на рабочий
датацентр.
Один из приоритетов –
постоянная доступность сервиса,
его отказоустойчивость.

Первые предпосылки к переезду: технические
Возросшие требования к скорости работы порталов:
развитие Битрикс24.Диска, скорость отклика,
мобильное приложение, real-time чаты, уведомления
и т.д. Сетевая связность стала иметь большое
значение.
Два новых ДЦ – в Ирландии
Продублировали инфраструктуру (базы, пулинг, auto-
scaling и security группы, серверы бэкапов и т.д.)
Свой API для работы с Route53
Без даунтайма для клиентов!

242-ФЗ вступил в силу на территории России
1 сентября 2015 г.

Варианты:
1. Забить.
2. А давайте попробуем всех обмануть 
Сделаем туннель/прокси: возьмем
российский IP, сделаем прокси к западным
серверам и там оставим персональные
данные.
3. Деперсонализировать.
Разместим часть данных в России, а не перс.
данные могут остаться и не в РФ.
4. Полностью переехать.

Архитектура Битрикс24
Количество серверов:
• 25-40 - в США
• 35-75 - в Европе
(в зависимости от автомасштабирования)
RTT (Round Trip Time) - время между
отправкой запроса и получением ответа от
сервера:
• США - 130 миллисекунд
• Европа - 70 миллисекунд
• Россия - 5-10 миллисекунд

Территориальные балансировщики
Минимальный RTT
SSL – A+ (ssllabs.com)
Поддержка SPDY / HTTP/2
для клиентов
SSL keep alive на бэкенды
Раздельный кэш для общей
статики, пользовательской
статики, композитных
хитов
Работа с территориально
распределенными
бэкендами

1. Первый принципиальный вопрос – это
выбор между размещением на
физическом оборудовании (неважно, это
будут наши собственные серверы или
арендованные) или же на уже развернутой
у провайдера виртуальной инфраструктуре
(по сути – IaaS).
2. Во-вторых, нам было важно, чтобы
провайдер имел как минимум 2 ДЦ для
резервирования на уровне датацентра,
чтобы мы могли строить такую же
структуру, как и раньше.
3. Выбор гипервизора. Коммерческий или
некоммерческий?
Как мы выбирали провайдера

• Виртуальные машины с произвольной конфигурацией дисков.
• Динамическая тарификация.
• Наличие API: стоп/старт машин, подключить/отключить диски,
назначить внешний IP и т.д.
• Снэпшоты дисков и целые образы виртуальных машин.
• Балансировщики Level 7 , DNS, Firewall, горизонтальное
масштабирование, сервисы очередей и т.д.
Выбирая провайдера, мы понимали, что в России мы не найдем
полного соответствия нашим требованиям. В любом случае,
придется самим дорабатывать-дописывать, и вот тут важно, чтобы
дорабатывать пришлось не на 70%, а на 20-30%.
Наши требования к «облаку»

Вопросы и сложности. 1 сентября
Резкий рост нагрузки
Сложности с быстрым
масштабированием
Производительность дисковой
системы
Тюнинг сетевого стека

Системными утилитами мониторим LA
Используем API VMware
Автоматически стартуют новые машины, если средняя нагрузка CPU превышает заданный верхний
порог
Автоматически останавливаются и выводятся из балансировщика, если средняя нагрузка
опускается ниже заданного нижнего порога
Вопросы и сложности. Делаем свой scaling

0
5000
10000
15000
20000
25000
30000
35000
40000
45000
0:00 1:00 2:00 3:00 4:00 5:00 6:00 7:00 8:00 9:00 10:00 11:00 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 20:00
Количество хитов

0
0.5
1
1.5
2
2.5
0:00 1:00 2:00 3:00 4:00 5:00 6:00 7:00 8:00 9:00 10:00 11:00 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 20:00
Load Average

0
10
20
30
40
50
60
0:00 1:00 2:00 3:00 4:00 5:00 6:00 7:00 8:00 9:00 10:00 11:00 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 20:00
Количество серверов

0
50
100
150
200
250
300
350
400
0:00 1:00 2:00 3:00 4:00 5:00 6:00 7:00 8:00 9:00 10:00 11:00 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 20:00
Время генерации страниц (мс)

Как выпускать
обновления?

Обновления ПО на web-нодах
Web 1
Web 2
Web N
Сервер
обновлений
Новый
образ AMI
Elastic
Load
Balancing
Каждый портал работает с собственной
базой.
Все обновления ставятся на выделенный
instance, куда не приходит нагрузка.
Из этого инстанса делается новый образ
AMI.
Последовательно каждая машина
помечается «плохой», при этом новые
веб-ноды стартуют уже из нового образа.
В веб-приложении существует механизм
проверки соответствия версии ПО и базы.
Если клиентский запрос приходит на ноду
с новым ПО, а база еще старая, по
первому хиту происходит обновление.

Обновления ПО на web-нодах
В России все очень похоже, но чуть иначе
Новые инстансы не стартуем из образа, а просто делаем stop/start (так просто
быстрее)
API VMware vCloud
ansible
Поочередно выводим машины из балансировки нагрузки, а потом возвращаем
«Эталонный» сервер единый
Синхронизация между регионами – ansible, bash
В итоге – единый скрипт

Иногда слоники не взлетают…

Битрикс24: процедуры раскатки
Stage / production: множество НЕ выпущенные на клиентов аварий
Значительно проще экспериментировать
Ускорение цикла выпуска обновлений
Безопасность
Процедура быстрой раскатки с резервного эталона
Хотфиксы

Если ваш сайт выглядит как живой...
убедитесь, что он еще и здоровый.

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

Как при этом не взорвать мозг?
Доступность «Битрикс24» и
облачных сервисов
«1С-Битрикс» - 99.9+%
8200+ проверок в трех
регионах в системе
мониторинга

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

Мониторинг «железа»
Рейды
S.M.A.R.T. – диск, возможно, скоро «умрет»
Утилиты вендора – внутренние аппаратные тесты

Мониторинг сети
Загрузка канала
Потери пакетов
Связность узлов

Мониторинг сети
SpeedTest

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

Тесты критичного софта
Для критичного софта: считаем число процессов, объем RSS,
%CPU, process system/user time

Тесты БД
Пример для MySQL

Мониторинг нетипичных и «неадминских» характеристик
Наличие бэкапов
Срок делегирования доменов
Баланс у провайдера смс-уведомлений
Отсутствие в блэк-листах
Срок действия SSL сертификатов
Бизнес-метрики и характеристики

SSL сертификаты
Проэкспайрившийся SSL сертификат можно заметить не сразу,
если по HTTPS работает не весь сайт, а отдельные разделы
При этом закрыты наиболее критичные разделы (корзина,
авторизация и т.п.)
Теряем позиции в поиске

Мониторинг веб-приложения, скрипта в кроне и т.п.
Лог работы скрипта - STDOUT (>) – обновился за N часов
Лог ошибок работы скрипта - STDERR (2>) – должен быть пуст

«Бизнес»-метрики
Например, количество
заказов в единицу
времени

Например, регистрации в «Битрикс24»

Уведомления
Cкрипт, опрашивающий страницу «Problems»
Шлем «дайджест» проблем, а не по одному
сообщению на каждое событие
Шлем СМС, не e-mail (не только e-mail)
Лучше – на разных операторов
Несколько уровней критичности событий
Разные списки адресатов на разные события
Повтор (через 15 минут, через 2 часа), чтобы не
«потерять» уведомление
Возможность проверки прямо из СМС
ОК – если все стало хорошо

Зачем наступать на одни
и те же грабли, если
вокруг полно новых?

Автоматизация типовых реакций
Рост / падение LA – автоматическое масштабирование вверх / вниз
Автоматический рестарт «сбойных» сервисов
Автоматическое «удаление» проблемных машин
Автоматическое восстановление репликации
Автоматическое переключение трафика в случае аварии на уровне целого ДЦ

event handler
# Segfaults on the server
define service{
use local-service
host_name ec2-54-227-28-75.compute-1.amazonaws.com
service_description Segmentaion Fault Errors
check_command check_nrpe_1arg!check_segfault!
event_handler restart_phpfpms
}
define command{
command_name restart_phpfpms
command_line /usr/lib64/nagios/plugins/check_nrpe -H $HOSTADDRESS$ -c restart_phpfpm
}

«На всякий случай…»
Внешние системы:
http://host-tracker.com/
Яндекс.Метрика
И т.д.
* * * * * user /opt/manage/bin/http_sms.sh

Аналитика
Видим, что было
Предвидим, что будет
Улавливаем тренды
Планируем мощности железа
Сравниваем настройки софта
• Веб-система перестает быть черным ящиком, видно ее развитие с
течением времени

Аналитика - MySQL
Следите за числом запросов и коннектов в БД, количеством
медленных запросов, прочими характеристиками

Динамика загрузки страниц
Navigation Timing API

Как жить в облаке почти без админов: мониторинг и эксплуатация сотен виртуальных машин силами трех человек

Поиск узких мест и действия
Нужно быстро понять – где и как починить
Смотрим срабатывание тестов – часто единственный источник информации
Смотрим уведомления от системы мониторинга
Смотрим логи. Держим заготовленные скипты-парсеры логов на поиск ошибок.
Смотрим графики
Если получается, запускаем инструменты поиска узких мест

error.log
Агрегирующие скрипты (PHP, Perl, bash):
PHP Signals: 62
[…]
PHP Fatals: 94
[…]
PHP Warnings: 5
[…]

access.log
Apache
LogFormat "%t "%r" %>s %b child:%P time-> %D" timing
Nginx
log_format timing … '->$upstream_response_time';
PHP-FPM
access.format = … %{mili}d …

Поиск «узких» мест
Apache /server-status
Включенные логи медленных запросов php-fpm, nginx, apache,
MySQL
Не только «…Ops», но и «Dev…»:
Pinba
Xhprof
И т.д.

Инструменты поиска узких мест
Если никаких других инструментов нет, или надо срочно локализовать
проблему на «бою»
Можно просто перезапустить Apache / nginx / PHP-FPM, но вы не
найдете суть проблемы, и она повторится
Старые добрые утилиты unix: netstat, lsof, strace, gdb
И попроще: grep, awk, sort, uniq и т.д.
Для MySQL (и вот мы уже становимся DBA): понимание EXPLAIN,
SHOW PROCESSLIST, SHOW ENGINE InnoDB STATUS и т.д.
Тренируйтесь!

Наша команда… раньше

Наша команда… сейчас
Обучение новых сотрудников
Документирование всех процессов
Регламенты работ
Планерки
Круглосуточное дежурство

Наше хозяйство
Около 300 виртуалок + прочие сервисы (SQS, DynamoDB, Kinesis, S3 и т.д.)
14 точек присутствия (ДЦ)
До 135 000 хитов в минуту в пике (100М хитов к динамике в сутки)

Самый главный рецепт!
Работа в команде
Любить продукт
Любить клиентов

Спасибо за внимание!
Вопросы?
Александр Демидов
demidov@1c-bitrix.ru
demidov
Demidov.Alexander

Как жить в облаке почти без админов: мониторинг и эксплуатация сотен виртуальных машин силами трех человек

More Related Content

What's hot (19)

Similar to Как жить в облаке почти без админов: мониторинг и эксплуатация сотен виртуальных машин силами трех человек (20)

More from Uptime community (7)

Как жить в облаке почти без админов: мониторинг и эксплуатация сотен виртуальных машин силами трех человек