View
1.132
Download
7
Category
Preview:
DESCRIPTION
Citation preview
Сергей Рыжиков генеральный директор компании «1С-‐Битрикс»
Архитектура и запуск облачного сервиса в Amazon AWS. Как обеспечить реальные 24?
Цель на 2012 год
Задача для компании в 2012 году – запустить в коммерческую эксплуатацию «Битрикс24» • Аренда Корпоративного портала как инструмента социального
интранета • Развитие социального Project-‐ и Task-‐менеджмента • Развитие Social CRM -‐ готового, простого в использовании
решения • Собрать и накопить опыт по эксплуатации облачных веб-‐
сервисов, поделиться им с партнерами
Битрикс24
Битрикс24
• Новый SaaS сервис – как коммерческие, так и «бесплатные» пользователи
• Минимизация расходов на эксплуатацию и снижение финансовых рисков на старте проекта
• Масштабирование при росте нагрузки и обратное масштабирование • Надежность – обеспечение SLA • Работа с разными рынками: США, Европа, Россия • Быстрая отдача статического контента
Есть несколько задач на старте и в процессе работы
Запускаем новый SaaS-‐сервис «Битрикс24»
• Отказоустойчивость – умение размещаться сразу в нескольких разных территориально распределенных датацентрах (в разных странах)
• MulJTenancy архитектура • Полное разделение логики (кода продукта) и данных • Пользовательские данные – это большой объем статических файлов
и база данных • Универсальный API платформы для многолетней разработки • Динамическое масштабирование по нагрузке
Из «бизнес-‐требований» появились технические
• Выбор технической платформы для инфраструктуры • Выбор платформы разработки
Две итоговые задачи:
Независимые факторы надежности
Человечество уже сделало определенный путь для обеспечения независимых факторов надежности. Для «Битрикс24» нужен аналогичный подход – продолжать работу без потери данных в случае выхода из строя одного ДЦ и быть способными восстанавливать базы данных за несколько минут.
Веб-‐приложение
Кэширование на диск
База данных
Традиционное устройство веб-‐продуктов
Обычный продукт не поддерживает гео веб-‐кластер, облачные файлы, распределенное кэширование, mulwtenancy…
Балансировщик (клиентские запросы по HTTP)
Веб-‐сервер 1
memcached 1
Веб-‐сервер 2
memcached 2 MySQL master
MySQL slave
1 этап : Веб-‐кластер
Облачная платформа: веб-‐кластер • Вертикальный шардинг (вынесение модулей на отдельные серверы
MySQL)
• Репликация MySQL и балансирование нагрузки между серверами
• Распределенный кеш данных (memcached)
• Непрерывность сессий между веб-‐серверами (хранение сессий в базе данных)
• Кластеризация веб-‐сервера:
– Синхронизация файлов (это – проблема для облачного сервиса) – Балансирование нагрузки между серверами
«Веб-‐кластер», ДЦ в России
БД
Веб-‐нода
«Веб-‐кластер», ДЦ в Германии
«Веб-‐кластер», ДЦ в США
Кэш
БД
Веб-‐нода
Кэш
БД
Веб-‐нода
Кэш
БД
Веб-‐нода
Кэш
БД
Веб-‐нода
Кэш
БД
Веб-‐нода
Кэш
БД
Веб-‐нода
Кэш
БД
Веб-‐нода
Кэш
БД
Веб-‐нода
Кэш
Асинхронная master-‐master репликация для обеспечения работы географически распределенных веб-‐кластеров. Потеря связи между ДЦ может составлять часы.
2 этап – гео веб-‐кластер
Облачное хранилище файлов
Облачное хранилище файлов (Amazon S3, Azure, Google Storage, OpenStack
Swi�) + CDN
Посетители
Веб-‐приложение
Веб-сервер
ДЦ в России
Веб-сервера Веб-серверы
slave
БД (master)
Веб-приложение
Веб-сервер
ДЦ в США
Веб-сервера Веб-серверы
slave
БД (master)
Платформа для разработки облачных веб-‐сервисов
• В версии 10. 0 реализована поддержка веб-‐кластера.
• В версии 11.0 – географический веб-‐кластер master-‐master.
• В версии 11.0 – поддержка облачных хранилищ, тайм-‐зон, автомасштабирования.
• В 2011 году разработана облачная архитектура эксплуатации в Амазоне.
• Накоплен опыт работы в Амазоне , опыт эксплуатации и особенности работы в облачной инфраструктуре.
• В конце 2011 г была запущена первая опытная версия сервиса «Битрикс24».
• Отказоустойчивость – умение размещаться сразу в нескольких разных территориально распределенных датацентрах (в разных странах)
• Большой объем базы данных – шардинг – возможность разделить базу данных по территории и группам клиентов
• MulJTenancy архитектура
• Полное разделение логики (кода продукта) и данных
• Пользовательские данные – это большой объем статических файлов и база данных
• Универсальный API платформы для многолетней разработки
• Динамическое масштабирование по нагрузке
Из «бизнес-‐требований» появились технические
Минусы размещения на собственном оборудовании:
«Когда мы только начинали работу над стартапом (FriendFeed), нам нужно было решить, покупать собственные серверы или же выбрать одного из «облачных» хостинг-‐провайдеров – таких как Amazon (AWS). Мы выбрали первое – решили приобрести собственные серверы. Оглядываясь назад, я думаю, что это было большой ошибкой» Брет Тейлор технический директор Facebook
Выбор платформы для разворачивания инфраструктуры
• Необходимы вложения в инфраструктуру на старте проекта • Сложность масштабирования • Сложность администрирования (в случае размещения в
территориально удаленных датацентрах) • Создание всех сопутствующих сервисов с нуля
Используем все возможности масштабирования в Amazon, исходя из экономики проекта.
MySQL master
Web 1
ElasZc Load Balancing
Web 2
Web N …MySQL master
Web 1
Web 2
Web N …
master-‐master репликация
Архитектура «Битрикс24»
S3
management, monitoring,
MySQL backup
Датацентр 1 в регионе US East (Virginia) Мониторинг и масштабирование – CloudWatch + AutoScaling
Датацентр 2 в регионе US East (Virginia) Мониторинг и масштабирование – CloudWatch + AutoScaling
CloudWatch + Auto Scaling
Web 1
Очень высокая посещаемость
ElasZc Load Balancing
Web 2
Web N …
Web – автоматическое масштабирование
Используем связку Elaswc Load Balancing + CloudWatch + Auto Scaling
Web – автоматическое масштабирование
Используем связку Elaswc Load Balancing + CloudWatch + Auto Scaling " Автоматически стартуют новые машины, если средняя нагрузка CPU превышает
60% " Автоматически останавливаются и выводятся из эксплуатации, если средняя
нагрузка менее 30% " Ставили верхний порог на 80%, однако начинается общая деградация системы
– пользователям работать некомфортно (долго загружаются страницы)
Специфика веб-‐нод Есть несколько задач, которые необходимо решить: • На веб-‐нодах нет пользовательского
контента, все ноды должны быть абсолютно идентичны.
• Read only. Никакие пользовательские данные не пишутся и не сохраняются на веб-‐нодах, так как в любой момент времени любая машина может быть выключена или стартует новая из «чистого» образа.
• При этом необходимо обеспечить изоляцию пользователей друг от друга.
• Нет Apache. Есть PHP-‐FPM + nginx • У каждого клиента свой домен • Был разработан модуль для PHP:
• проверяет корректность домена, завершает хит с ошибкой, если имя некорректно
• устанавливает соединение с нужной базой в зависимости от домена
• обеспечивает безопасность и изоляцию пользователей друг от друга
• служит для шардинга данных разных пользователей по разным базам
Специфика веб-‐нод
Bitrix24 -‐ cвой модуль для PHP
• Обеспечивает переопределние функции соединения с базой данных.
• В отдельной таблице хранит строки соединения с разными мастерами и «слейвами», обслуживающими БД.
• Позволяет выполнять горизонтальное масштабирование БД (шардинг) по любому количеству серверов вплоть до «один клиент на одном сервере».
• Обеспечивает запуск (fork) процессов для PHP и быструю отдачу страницы пользователю.
" Статические данные пользователей храним в S3.
" Загрузка осуществляется «прозрачно» для пользователей – они работают с привычными интерфейсами.
" Правильно формируются url’ы к картинкам, документам и т.п.
" Для каждого созданного Корпоративного портала создается персональный аккаунт – данные каждого КП полностью изолированы друг от друга.
Статический контент пользователей сервиса
Полная изоляция данных
• Данные одной компании полностью изолированы от данных другой.
• Для каждого клиента данные хранятся раздельно: o свой логин пароль к БД o своя БД со структурой таблиц o свое облачное хранилище S3 с отдельным логином/паролем
o отдельное пространство для кеширования данных • Все веб-‐ноды могут обслуживать любых клиентов, набор данных определяется по домену и не может быть изменен.
ElasZc Load Balancing
Готов только первый «двигатель самолета»
MySQL master
Web 1
ElasZc 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 …Датацентр 2 в регионе US East (Virginia) Мониторинг и масштабирование – CloudWatch + AutoScaling
• Особенности настройки MySQL: • auto_increment_increment • auto_increment_offset
• Базы в разных датацентрах синхронны, при этом независимы друг от друга: потеря связности между датацентрами может составлять часы, данные синхронизируются после восстановления.
• В любое время можно добавить новые датацентры.
• Пользователь и все сотрудники этой компании работают в одном датацентре за счет управления балансировщиком.
• Сессии храним в базе, но не реплицируем между серверами из-‐за большого траффика:
• SET sql_log_bin = 0 … или … • replicate-‐wild-‐ignore-‐table = %.b_sec_session%
Используем master-‐master репликацию в MySQL
MySQL master
ElasZc Load Balancing
Web N …
Web 1
Web 2
MySQL master
Web 1
Web 2
Web N …
master-‐master репликация
Сценарий 1: авария на одной или нескольких веб-‐нодах
S3
management, monitoring,
MySQL backup
Датацентр 1 в регионе US East (Virginia) Мониторинг и масштабирование – CloudWatch + AutoScaling
Датацентр 2 в регионе US East (Virginia) Мониторинг и масштабирование – CloudWatch + AutoScaling
" Load Balancing определяет вышедшие из строя машины. " Исходя из заданных параметров группы балансировки,
автоматически восстанавливается нужное количество машин.
Сценарий 1: авария на одной или нескольких веб-‐нодах
MySQL master
ElasZc Load Balancing
Web N …
Web 1
Web 2
MySQL master
Web 1
Web 2
Web N …
master-‐master репликация
S3
management, monitoring,
MySQL backup
Датацентр 1 в регионе US East (Virginia) Мониторинг и масштабирование – CloudWatch + AutoScaling
Датацентр 2 в регионе US East (Virginia) Мониторинг и масштабирование – CloudWatch + AutoScaling
Сценарий 1: авария на одной или нескольких веб-‐нодах
MySQL master
ElasZc Load Balancing
Web N …
Web 1
Web 2
MySQL master
Web 1
Web 2
Web N …
master-‐master репликация
Сценарий 2: потеря связности между датацентрами
S3
management, monitoring,
MySQL backup
Датацентр 1 в регионе US East (Virginia) Мониторинг и масштабирование – CloudWatch + AutoScaling
Датацентр 2 в регионе US East (Virginia) Мониторинг и масштабирование – CloudWatch + AutoScaling
ElasZc Load Balancing
ElasZc Load Balancing
" Каждый датацентр продолжает обслуживать свой сегмент клиентов.
" Данные синхронизируются после восстановления связности.
Сценарий 2: потеря связности между датацентрами
MySQL master
ElasZc Load Balancing
Web N …
Web 1
Web 2
MySQL master
Web 1
Web 2
Web N …
master-‐master репликация
Сценарий 3: плановые работы с базой или авария всего ДЦ
S3
management, monitoring,
MySQL backup
Датацентр 1 в регионе US East (Virginia) Мониторинг и масштабирование – CloudWatch + AutoScaling
Датацентр 2 в регионе US East (Virginia) Мониторинг и масштабирование – CloudWatch + AutoScaling
" Весь трафик переключается в один работающий датацентр. " CloudWatch определяет возросшую нагрузку на машины и
добавляет их в соответствие с правилами для AutoScaling.
" Приостанавливается мастер-‐мастер репликация. " Проводятся все необходимые работы с базой, на которую
не идет нагрузка.
" База включается в работу, восстанавливается репликация. " Траффик распределяется на оба датацентра. " Гасятся лишние машины, если средняя нагрузка стала ниже
порогового значения.
Сценарий 3: плановые работы с базой или авария всего ДЦ
• Оптимизирован для работы в «облаке» (с относительно медленными дисками) • Быстрое восстановление кэша при рестарте базы • Оптимизирован для Mulwtenancy приложений с тысячами таблиц • Оптимизирован для сбора статистики по отдельным пользователям • Подробная статистика по медленным запросам • XtraDB и XtraBackup
MySQL? Percona Server!
Один из выводов в процессе эксплуатации: используем один из fork’ов MySQL – Percona Server (обратно совместим с MySQL)
Виртуальная машина (EC2) -‐ Extra Large Instance – 15 Gb RAM
Этапы масштабирования: 1) Вертикальное масштабирование
(дисковая система RAID-‐10 на EBS) 2) Веб-‐кластер master-‐slave. Запуск
необходимого числа слейвов в конфигурации веб-‐кластера master-‐slave
3) Горизонтальное масштабирование, разделение мастера на несколько серверов
Все этапы выполняются без остановки сервиса.
Конфигурация машин с базами MySQL
Бэкап базы данных
Еще один вывод: для разных сценариев восстановления данных необходимо использовать разные бэкапы.
" Для восстановления целого сервера БД в случае аварии используем образ машин со всеми дисками (AMI) – делаем целостный бэкап RAID’а, используя файловую систему, поддерживающую freeze и механизм snapshot’ов в Амазоне.
" Логические (mysqldump) и бинарные инкрементальные (Xtrabackup) бэкапы используются для восстановления отдельных баз или таблиц, поврежденных в случае некорректных операций в системе или ошибок пользователей.
" Второй тип бэкапов делается на выделенном slave, на который не распределяется общая нагрузка. Тем самым ресурсоемкие операции создания бэкапов не влияют на работу пользователей.
Web 1
Web 2
Web N
Сервер обновлений
Новый образ AMI
ElasZc Load
Balancing
Как ставить обновления на нодах, не допустив рассинхронизации данных (веб и база)
Обновления ПО на веб-‐нодах
Контроллер
Используется для логического управления проектами, выполнения любых команд, SQL-‐запросов и PHP-‐кода на любой из копии проекта. Обеспечивает биллинг, включение тарифных планов, ограничения по пользователям, дисковому пространству и т.д.
ElasZc Load Balancing
MySQL master
Web 1
HTTP/HTTPS *.ru
ElasZc Load Balancing
HTTP/HTTPS *.com
Web 2
Web N …CloudWatch + AutoScaling
MySQL slave
CloudWatch
MySQL master
Web 1
Web 2
Web N …CloudWatch + AutoScaling
MySQL slave
CloudWatch
master-‐master репликация
Итоговая архитектура Битрикс24
S3
HTTP/HTTPS *.com *.ru
management, monitoring,
MySQL backup
cache cache
" Все веб-‐ноды идентичны и не зависимы друг от друга, в случае аварии автоматически стартуют новые.
" Два датацентра синхронизированы друг с другом и равноценно обслуживают клиентов. В случае аварии на уровне датацентра или плановых работ с базой, трафик прозрачно для клиентов переключается на рабочий датацентр.
Надежность Один из приоритетов – постоянная доступность сервиса, его отказоустойчивость.
Идет тестирование
• Не раздавайте «инвайты», используйте только сами! • Для тестирования ограничение по пользователям не
установлено. • Тем, кто перейдет на использование компанией, сервис
предоставим бесплатно (50 Гб).
Ваш персональный «инвайт» на Битрикс24
XXX-‐XXX-‐XX
Следите за нами!
www.1c-‐bitrix.ru
facebook.com/1CBitrix
twi¦er.com/1C_Bitrix
Спасибо за внимание! Вопросы?
Recommended