PPTX, 3 МБ

Как жить в облаке без админов?
Александр Демидов
руководитель направления арендных решений
«1С-Битрикс»
- Новый сервер?
Нестандартной
конфигурации? 5-го
января? … Нет, не
слышали.
Облако!
Быстро!
Надежно!
Дешево!
Неправда…
Надежность «облака»
Само по себе «облако» не
надежнее традиционного
хостинга и собственного
оборудования. «Облако»
дает возможность
организовать надежную
инфраструктуру.
Сама инфраструктура не
построится…
Админы пока еще не нужны…
Нужен
аналитик…
Админы пока еще не нужны…
…и архитектор.
Правильное облако
Несколько территориально
распределенных ДЦ (с
возможностью их выбора)
Гибкое управление дисками
Облачные базы данных, кэш,
NoSQL, балансировщики, DNS,
мониторинг, сервисы
очередей, файловые
хранилища, CDN и т.д.
API и готовые SDK для
управления всеми сервисами
Готовность приложения к
масштабированию
Резервируй это!
Static
HTTPS
*.com/*.de
Static
HTTPS
*.ru
js, css
Elastic Load Balancing
Web 1
Web 2
local
cache
(APC)
local
cache
(APC)
CloudWatch
+
AutoScaling
…
mysqld
control cache: memcached
js, css
Elastic Load Balancing
Web 2
local
cache
(APC)
local
cache
(APC)
local
cache
(APC)
S3
mysqld
master-master replication
mysqld
master-master replication
control cache: memcached
mysqld
mysqld
mysqld
control cache: memcached
CloudWatch
+
AutoScaling
…
local
cache
(APC)
mysqld
mysqld
mysqld
mysqld
mysqld
control cache: memcached
management,
monitoring,
backup
Web N
mysqld
mysqld
mysqld
control cache: memcached
CDN (CDNvideo)
Web 1
master-master replication
mysqld
Dynamic
HTTPS
*.ru
Web N
mysqld
mysqld
images (clients)
CDN (Amazon CloudFront)
images (clients)
Dynamic
HTTPS
*.com/*.de
mysqld
control cache: memcached
Web – автоматическое
масштабирование
Используем связку Elastic Load Balancing + CloudWatch +
Auto Scaling
Очень высокая посещаемость
Elastic Load Balancing
Web 1
Web 2
…
CloudWatch + Auto Scaling
Web N
Web – автоматическое
масштабирование
Используем связку Elastic Load Balancing + CloudWatch +
Auto Scaling
Автоматически стартуют новые машины, если средняя нагрузка
CPU превышает X%
Автоматически останавливаются и выводятся из эксплуатации,
если средняя нагрузка менее Y%
MySQL? Percona Server!
Один из выводов в процессе эксплуатации: используем
один из fork’ов MySQL – Percona Server (обратно совместим
с MySQL)
Быстрое восстановление кэша при рестарте базы
Оптимизирован для Multitenancy приложений с тысячами таблиц
Оптимизирован для сбора статистики по отдельным пользователям
Подробная статистика по медленным запросам
XtraDB и XtraBackup
BLOB, TEXT в таблицах MEMORY (HEAP)
Используем master-master
репликацию в MySQL
Особенности настройки MySQL:
auto_increment_increment
auto_increment_offset
Базы в разных датацентрах синхронны, при этом независимы
друг от друга: потеря связности между датацентрами может
составлять часы, данные синхронизируются после
восстановления.
Группы пользователей работают в одном датацентре за счет
управления балансировщиком.
Какие-то данные можно не реплицировать:
SET sql_log_bin = 0 … или …
replicate-wild-ignore-table = %.b_sec_session%
Сценарий 1: авария на одной или
нескольких веб-нодах
Elastic
Load Balancing
Web 1
Web 2
Датацентр 1 в
регионе US East
(Virginia)
…
Web N
MySQL
master
S3
master-master
репликация
Web 1
MySQL
master
Web 2
…
Web N
Датацентр 2 в
регионе US East
(Virginia)
Мониторинг и
масштабирование –
CloudWatch +
AutoScaling
Мониторинг и
масштабирование –
CloudWatch +
AutoScaling
management,
monitoring,
MySQL backup
Сценарий 1: авария на одной или
нескольких веб-нодах
Load Balancing определяет вышедшие из строя машины
Исходя из заданных параметров группы балансировки,
автоматически восстанавливается нужное количество
машин
Сценарий 1: авария на одной или
нескольких веб-нодах
Elastic
Load Balancing
Web 1
Web 2
Датацентр 1 в
регионе US East
(Virginia)
…
Web N
MySQL
master
S3
master-master
репликация
Web 1
MySQL
master
Web 2
…
Web N
Датацентр 2 в
регионе US East
(Virginia)
Мониторинг и
масштабирование –
CloudWatch +
AutoScaling
Мониторинг и
масштабирование –
CloudWatch +
AutoScaling
management,
monitoring,
MySQL backup
Сценарий 2: потеря связности
между датацентрами
Elastic
Load Balancing
Web 1
Web 2
Датацентр 1 в
регионе US East
(Virginia)
…
Elastic
Load Balancing
Web N
MySQL
master
S3
master-master
репликация
Elastic
Load Balancing
Web 1
MySQL
master
Web 2
…
Web N
Датацентр 2 в
регионе US East
(Virginia)
Мониторинг и
масштабирование –
CloudWatch +
AutoScaling
Мониторинг и
масштабирование –
CloudWatch +
AutoScaling
management,
monitoring,
MySQL backup
Сценарий 2: потеря связности
между датацентрами
Каждый датацентр продолжает обслуживать свой сегмент
клиентов
Данные синхронизируются после восстановления связности
Сценарий 3: плановые работы с
базой или авария всего ДЦ
Elastic
Load Balancing
Web 1
Web 2
Датацентр 1 в
регионе US East
(Virginia)
…
Web N
MySQL
master
S3
master-master
репликация
Web 1
MySQL
master
Web 2
…
Web N
Датацентр 2 в
регионе US East
(Virginia)
Мониторинг и
масштабирование –
CloudWatch +
AutoScaling
Мониторинг и
масштабирование –
CloudWatch +
AutoScaling
management,
monitoring,
MySQL backup
Не бывает
«почти круглосуточно»
Технические работы должны
проходить незаметно для
клиентов:
Сервисные работы
Замена оборудования
Обновления системного
ПО
Обновления приложений
Сценарий 3: авария или
плановые работы с базой
Весь траффик переключается в один работающий датацентр
CloudWatch определяет возросшую нагрузку на машины и
добавляет их в соответствие с правилами для AutoScaling
Приостанавливается мастер-мастер репликация
Проводятся все необходимые работы с базой, на которую не
идет нагрузка
База включается в работу, восстанавливается репликация
Траффик распределяется на оба датацентра
Гасятся лишние машины, если средняя нагрузка стала ниже
порогового значения
Real Time мониторинг – как
узнавать о проблемах?
Можно – так…
Real Time мониторинг – как
узнавать о проблемах?
Или – так…
Организация системы
мониторинга
Лучше – стандартные решения (Nagios, Zabbix и т.п.), а не
самописные.
Дежурная смена и/или мгновенные уведомления.
Мониторить – всё.
Но – аккуратно. Тысячи уведомлений будут бесполезны.
Мониторить систему мониторинга. В идеальном мире –
распределенная система мониторинга.
Автоматизация типовых реакций.
Помимо стандартных - пишите свои тесты
Пример для MySQL
Автоматизация типовых
реакций
Рост / падение LA – автоматическое масштабирование
вверх / вниз
Автоматический рестарт «сбойных» сервисов
Автоматическое «удаление» проблемных машин
Автоматическое восстановление репликации
Автоматическое переключение траффика в случае аварии
на уровне целого ДЦ
event handler
# LA on the server
define service{
use
host_name
service_description
check_command
event_handler
}
local-service
ec2-54-227-28-75.compute-1.amazonaws.com
Current Load
check_nrpe_1arg!check_load!
restart_phpfpms
define command{
command_name
restart_phpfpms
command_line
/usr/lib64/nagios/plugins/check_nrpe -H
$HOSTADDRESS$ -c restart_phpfpm
}
Мониторинг нетипичных
характеристик
Наличие бэкапов
Срок делегирования доменов
Срок действия SSL сертификатов
Баланс у провайдера смс-уведомлений
Мониторинг веб-приложения
Лог работы скрипта (>) – обновился за N часов
Лог ошибок работы скрипта (2>) – должен быть пуст
Уведомления – как у нас
Cкрипт, опрашивающий страницу
«Problems»
Шлем «дайджест» проблем, а не по одному
сообщению на каждое событие
Несколько уровней критичности событий
Разные списки адресатов на разные
события
Повтор (через 15 минут, через 2 часа), чтобы
не «потерять» уведомление
ОК – если все стало хорошо
Аналитика
«Живая» система – много
небольших запросов
mysql> SELECT * FROM INFORMATION_SCHEMA.QUERY_RESPONSE_TIME;
+----------------+-------+----------------+
| time
| count | total
|
+----------------+-------+----------------+
|
0.000001 |
0 |
0.000000 |
|
0.000010 | 2011 |
0.007438 |
|
0.000100 | 12706 |
0.513395 |
|
0.001000 | 4624 |
1.636106 |
|
0.010000 | 2994 |
12.395174 |
|
0.100000 |
200 |
6.225339 |
|
1.000000 |
33 |
5.480764 |
|
10.000000 |
1 |
2.374067 |
|
100.000000 |
0 |
0.000000 |
|
1000.000000 |
0 |
0.000000 |
|
10000.000000 |
0 |
0.000000 |
| 100000.000000 |
0 |
0.000000 |
| 1000000.000000 |
0 |
0.000000 |
| TOO LONG
|
0 | TOO LONG
|
+----------------+-------+----------------+
14 rows in set (0.00 sec)
Аналитика - MySQL
Одиночные медленные запросы отлавливаются просто.
Сложнее мониторить общее состояние системы с
большим количеством относительно быстрых запросов.
Поиск узких мест
Pinba, XDebug, XHProf
Приложение всегда работает
в условиях ограниченных ресурсов
Постоянный feedback разработчикам – в
автоматическом и полуавтоматическом режиме
Резюме
Систему в облаке можно поддерживать, обходясь
минимумом человеческих ресурсов
•
Выбирайте правильное облако – с максимально широким
набором сервисов, API и т.п.
•
Ваше приложение должно быть готово к горизонтальному
масштабированию
•
•
•
•
Резервируйте все
Обязательно используйте системы мониторинга
Автоматизируйте все типовые действия
Держите приложение в условиях ограниченных ресурсов и
всегда давайте обратную связь разработчикам.
До 2012 года…
Два основных продукта:
Единственное, что
требовало того или
иного обслуживания –
наш собственный сайт.
В настоящее время…
файлы
бэкап
сканер
безопасности
CRM
CDN
видеозвонки
push
??
Облачные сервисы
Битрикс24 – SaaS «Корпоративный портал»
Более 7000 наиболее активных порталов
Ускорение сайта – интеграция с CDN
Около 9000 сайтов
Облачный бэкап
Более 7500 сайтов
Анонс новых сервисов осенью 2013
Примерно 2 стойки
42U – если без
виртуализации
Два человека – у
которых админство
не является
основной
деятельностью
Спасибо за внимание!
Вопросы?
Александр Демидов
demidov@1c-bitrix.ru
+7-926-521-3700
@demidov
http://www.1c-bitrix.ru