7. Надежность «облака»
Само по себе «облако» не
надежнее традиционного
хостинга и собственного
оборудования. «Облако»
дает возможность
организовать надежную
инфраструктуру.
11. Правильное облако
Несколько территориально
распределенных ДЦ (с
возможностью их выбора)
Гибкое управление дисками
Облачные базы данных, кэш,
NoSQL, балансировщики, DNS,
мониторинг, сервисы
очередей, файловые
хранилища, CDN и т.д.
API и готовые SDK для
управления всеми сервисами
13. Резервируй это!
Static
HTTPS
*.com/*.de
Static
HTTPS
*.ru
js, css
Elastic Load Balancing
Web 1
local
cache
(APC)
CloudWatch
+
AutoScaling
Web 2
local
cache
(APC)
…
mysqld
control cache: memcached
js, css
Elastic Load Balancing
local
cache
(APC)
local
cache
(APC)
CloudWatch
+
AutoScaling
Web 2
local
cache
(APC)
S3
master-master replication
mysqld
mysqld
master-master replication
control cache: memcached
mysqld
mysqld
mysqld
control cache: memcached
…
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
14. Web – автоматическое
масштабирование
Используем связку Elastic Load Balancing + CloudWatch +
Auto Scaling
Очень высокая посещаемость
Elastic Load Balancing
Web 1
Web 2
…
CloudWatch + Auto Scaling
Web N
15. Web – автоматическое
масштабирование
Используем связку Elastic Load Balancing + CloudWatch +
Auto Scaling
Автоматически стартуют новые машины, если средняя нагрузка
CPU превышает X%
Автоматически останавливаются и выводятся из эксплуатации,
если средняя нагрузка менее Y%
16. MySQL? Percona Server!
Один из выводов в процессе эксплуатации: используем
один из fork’ов MySQL – Percona Server (обратно совместим
с MySQL)
Быстрое восстановление кэша при рестарте базы
Оптимизирован для Multitenancy приложений с тысячами таблиц
Оптимизирован для сбора статистики по отдельным пользователям
Подробная статистика по медленным запросам
XtraDB и XtraBackup
BLOB, TEXT в таблицах MEMORY (HEAP)
17. Используем master-master
репликацию в MySQL
Особенности настройки MySQL:
auto_increment_increment
auto_increment_offset
Базы в разных датацентрах синхронны, при этом независимы
друг от друга: потеря связности между датацентрами может
составлять часы, данные синхронизируются после
восстановления.
Группы пользователей работают в одном датацентре за счет
управления балансировщиком.
Какие-то данные можно не реплицировать:
SET sql_log_bin = 0 … или …
replicate-wild-ignore-table = %.b_sec_session%
18. Сценарий 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
19. Сценарий 1: авария на одной или
нескольких веб-нодах
Load Balancing определяет вышедшие из строя машины
Исходя из заданных параметров группы балансировки,
автоматически восстанавливается нужное количество
машин
20. Сценарий 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
21. Сценарий 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
22. Сценарий 2: потеря связности
между датацентрами
Каждый датацентр продолжает обслуживать свой сегмент
клиентов
Данные синхронизируются после восстановления связности
23. Сценарий 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, m
onitoring,
MySQL backup
24. Не бывает
«почти круглосуточно»
Технические работы должны
проходить незаметно для
клиентов:
Сервисные работы
Замена оборудования
Обновления системного
ПО
Обновления приложений
25. Сценарий 3: авария или
плановые работы с базой
Весь траффик переключается в один работающий датацентр
CloudWatch определяет возросшую нагрузку на машины и
добавляет их в соответствие с правилами для AutoScaling
Приостанавливается мастер-мастер репликация
Проводятся все необходимые работы с базой, на которую не
идет нагрузка
База включается в работу, восстанавливается репликация
Траффик распределяется на оба датацентра
Гасятся лишние машины, если средняя нагрузка стала ниже
порогового значения
28. Организация системы
мониторинга
Лучше – стандартные решения (Nagios, Zabbix и т.п.), а не
самописные.
Дежурная смена и/или мгновенные уведомления.
Мониторить – всё.
Но – аккуратно. Тысячи уведомлений будут бесполезны.
Мониторить систему мониторинга. В идеальном мире –
распределенная система мониторинга.
Автоматизация типовых реакций.
30. Автоматизация типовых
реакций
Рост / падение LA – автоматическое масштабирование
вверх / вниз
Автоматический рестарт «сбойных» сервисов
Автоматическое «удаление» проблемных машин
Автоматическое восстановление репликации
Автоматическое переключение траффика в случае аварии
на уровне целого ДЦ
31. 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
}
34. Уведомления – как у нас
Cкрипт, опрашивающий страницу
«Problems»
Шлем «дайджест» проблем, а не по одному
сообщению на каждое событие
Несколько уровней критичности событий
Разные списки адресатов на разные
события
Повтор (через 15 минут, через 2 часа), чтобы
не «потерять» уведомление
ОК – если все стало хорошо
37. Аналитика - MySQL
Одиночные медленные запросы отлавливаются просто.
Сложнее мониторить общее состояние системы с
большим количеством относительно быстрых запросов.
39. Приложение всегда работает
в условиях ограниченных ресурсов
Постоянный feedback разработчикам – в
автоматическом и полуавтоматическом режиме
40. Резюме
Систему в облаке можно поддерживать, обходясь
минимумом человеческих ресурсов
•
Выбирайте правильное облако – с максимально широким
набором сервисов, API и т.п.
•
Ваше приложение должно быть готово к горизонтальному
масштабированию
•
•
•
•
Резервируйте все
Обязательно используйте системы мониторинга
Автоматизируйте все типовые действия
Держите приложение в условиях ограниченных ресурсов и
всегда давайте обратную связь разработчикам.
41. До 2012 года…
Два основных продукта:
Единственное, что
требовало того или
иного обслуживания –
наш собственный сайт.
43. Облачные сервисы
Битрикс24 – SaaS «Корпоративный портал»
Более 7000 наиболее активных порталов
Ускорение сайта – интеграция с CDN
Около 9000 сайтов
Облачный бэкап
Более 7500 сайтов
Анонс новых сервисов осенью 2013
44. Примерно 2 стойки
42U – если без
виртуализации
Два человека – у
которых админство
не является
основной
деятельностью
