Как жить в облаке без админов?

Как жить в облаке без админов?

Александр Демидовруководитель направления арендных решений

«1С-Битрикс»

- Новый сервер? Нестандартной конфигурации? 5-го января? … Нет, не слышали.

Облако!

Быстро!

Надежно!

Дешево!

Неправда…

Надежность «облака»

Само по себе «облако» не надежнее традиционного хостинга и собственного оборудования. «Облако» дает возможность организовать надежную инфраструктуру.

Сама инфраструктура не построится…

Админы пока еще не нужны…

Нужен аналитик…

Админы пока еще не нужны…

…и архитектор.

Правильное облако

Несколько территориально распределенных ДЦ (с возможностью их выбора)

Гибкое управление дисками

Облачные базы данных, кэш, NoSQL, балансировщики, DNS, мониторинг, сервисы очередей, файловые хранилища, CDN и т.д.

API и готовые SDK для управления всеми сервисами

Готовность приложения к масштабированию

Elastic Load Balancing

Web 1


DynamicHTTPS

*.com/*.de

Web N

…CloudWatch + AutoScaling

Web 1 Web 2 Web N

…CloudWatch + AutoScaling

Резервируй это!

S3

management, monitoring,

backup

StaticHTTPS

*.com/*.de

CDN (Amazon CloudFront)

js, css

DynamicHTTPS

*.ru

StaticHTTPS

*.ru

CDN (CDNvideo)

js, css

imag

es (c

lient

s)

imag

es (c

lient

s)

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

master-master replication

master-master replicationmysqld

mysqld

mysqld

mysqld

mysqld

mysqld

mysqld

mysqld

mysqld

mysqld

mysqld

mysqld






Web 2

local cache (APC)

CloudWatch + Auto Scaling

Web 1

Очень высокая посещаемость


Web 2 Web N…

Web – автоматическое масштабирование

Используем связку Elastic Load Balancing + CloudWatch + Auto Scaling

Web – автоматическое масштабирование

Используем связку Elastic Load Balancing + CloudWatch + Auto Scaling

Автоматически стартуют новые машины, если средняя нагрузка CPU превышает X%Автоматически останавливаются и выводятся из эксплуатации, если средняя нагрузка менее Y%

Быстрое восстановление кэша при рестарте базы

Оптимизирован для Multitenancy приложений с тысячами таблиц

Оптимизирован для сбора статистики по отдельным пользователям

Подробная статистика по медленным запросам

XtraDB и XtraBackup

BLOB, TEXT в таблицах MEMORY (HEAP)

MySQL? Percona Server!

Один из выводов в процессе эксплуатации: используем один из fork’ов MySQL – Percona Server (обратно совместим с MySQL)

Особенности настройки MySQL:auto_increment_incrementauto_increment_offset

Базы в разных датацентрах синхронны, при этом независимы друг от друга: потеря связности между датацентрами может составлять часы, данные синхронизируются после восстановления.Группы пользователей работают в одном датацентре за счет управления балансировщиком.Какие-то данные можно не реплицировать:

SET sql_log_bin = 0 … или …replicate-wild-ignore-table = %.b_sec_session%

Используем master-master репликацию в MySQL

MySQLmaster

ElasticLoad Balancing

Web N…

Web 1

Web 2

MySQLmaster

Web 1

Web 2

Web N…

master-master репликация

Сценарий 1: авария на одной или нескольких веб-нодах

S3


MySQL backup

Датацентр 1 в регионе US East (Virginia)

Мониторинг и масштабирование – CloudWatch + AutoScaling



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


MySQLmaster


Web N…

Web 1

Web 2

MySQLmaster

Web 1

Web 2

Web N…



S3


MySQL backup





MySQLmaster


Web N…

Web 1

Web 2

MySQLmaster

Web 1

Web 2

Web N…


Сценарий 2: потеря связности между датацентрами

S3


MySQL backup







Каждый датацентр продолжает обслуживать свой сегмент клиентовДанные синхронизируются после восстановления связности

Сценарий 2: потеря связности между датацентрами

MySQLmaster


Web N…

Web 1

Web 2

MySQLmaster

Web 1

Web 2

Web N…


Сценарий 3: плановые работы с базой или авария всего ДЦ

S3


MySQL backup





Не бывает«почти круглосуточно»

Технические работы должны проходить незаметно для клиентов:

Сервисные работы

Замена оборудования

Обновления системного ПО

Обновления приложений

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

Сценарий 3: авария или плановые работы с базой

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

Можно – так…

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

Или – так…

Организация системы мониторинга

Лучше – стандартные решения (Nagios, Zabbix и т.п.), а не самописные.

Дежурная смена и/или мгновенные уведомления.

Мониторить – всё.

Но – аккуратно. Тысячи уведомлений будут бесполезны.

Мониторить систему мониторинга. В идеальном мире – распределенная система мониторинга.

Автоматизация типовых реакций.

Помимо стандартных - пишите свои тесты

Пример для MySQL

Автоматизация типовых реакций

Рост / падение LA – автоматическое масштабирование вверх / вниз

Автоматический рестарт «сбойных» сервисов

Автоматическое «удаление» проблемных машин

Автоматическое восстановление репликации

Автоматическое переключение траффика в случае аварии на уровне целого ДЦ

event handler

# LA on the serverdefine service{ use local-service host_name ec2-54-227-28-75.compute-1.amazonaws.com service_description Current Load check_command check_nrpe_1arg!check_load! event_handler 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 – если без виртуализации

Два человека – у которых админство не является основной деятельностью

Спасибо за внимание! Вопросы?

Александр Демидов

[email protected]

+7-926-521-3700

@demidov

http://www.1c-bitrix.ru

mailto:[email protected]

http://www.1c-bitrix.ru/

Как жить в облаке без админов?

Documents