Your SlideShare is downloading. ×
«Битрикс24»: архитектура и эксплуатация высоконагруженного облачного сервиса
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

«Битрикс24»: архитектура и эксплуатация высоконагруженного облачного сервиса

1,153
views

Published on

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

Александр Демидов
руководитель направления арендных решений «1С-Битрикс»

Published in: Technology

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,153
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
9
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. «Битрикс24»: архитектура и эксплуатациявысоконагруженного облачного сервиса Александр Демидов руководитель направления арендных решений «1С-Битрикс»
  • 2. Цель на 2012 годЗадача для компании в 2012 году – запустить вкоммерческую эксплуатацию Bitrix24 Аренда Корпоративного портала как инструмента социального интранета Развитие социального Project- и Task-менеджмента Развитие Social CRM - готового, простого в использовании решения Собрать и накопить опыт по эксплуатации облачных веб- сервисов, поделиться им с партнерами
  • 3. Запускаем новый SaaS продуктBitrix24 Есть несколько задач на старте и в процессе работы Новый SaaS сервис – как коммерческие, так и «бесплатные» пользователи Минимизация расходов на эксплуатацию и снижение финансовых рисков на старте проекта Масштабирование при росте нагрузки и обратное масштабирование Надежность – обеспечение SLA Работа с разными рынками: США, Европа, Россия
  • 4. Для пользователя Быстро Без сбоев
  • 5. Независимые факторы надежностиЧеловечество уже сделалоопределенный путь - дляобеспечения независимыхфакторов надежности.Для Bitrix24 нуженаналогичный подход –продолжать работу безпотери данных в случаевыхода из строя одного ДЦ ибыть способнымивосстанавливать базы данныхза несколько минут.
  • 6. Из «бизнес-требований»появились технические Отказоустойчивость – умение размещаться сразу в нескольких разных территориально распределенных датацентрах (в разных странах) MultiTenancy архитектура Полное разделение логики (кода продукта) и данных Пользовательские данные – это большой объем статических файлов и база данных Универсальный API платформы для многолетней разработки Динамическое масштабирование по нагрузке Две итоговые задачи: Выбор технической платформы для инфраструктуры Выбор платформы разработки
  • 7. Традиционное устройствовеб-продуктов Веб-приложение Кэширование на диск База данныхОбычный продут не поддерживает гео веб-кластер, облачныефайлы, распределенное кэширование, multitenancy…
  • 8. Облачная платформа: веб-кластер• Вертикальный шардинг (вынесение модулей на отдельные серверы MySQL)• Репликация MySQL и балансирование нагрузки между серверами• Распределенный кеш данных (memcached)• Непрерывность сессий между веб-серверами (хранение сессий в базе данных)• Кластеризация веб-сервера: – Синхронизация файлов (это – проблема для облачного сервиса) – Балансирование нагрузки между серверами
  • 9. 1-ый этап реализации Балансировщик (клиентские запросы по HTTP) Веб-сервер 1 Веб-сервер 2 MySQL MySQL memcached 1 memcached 2 master slave
  • 10. Аварии на уровне целого датацентра Балансировщик (клиентские запросы по HTTP) Веб-сервер 1 Веб-сервер 2 MySQL MySQL memcached 1 memcached 1 master slave
  • 11. 2-ой этап – гео веб-кластер Асинхронная master-master репликация «Веб-кластер», для обеспечения работы географически «Веб-кластер», ДЦ в России распределенных веб-кластеров. ДЦ в США Потеря связи между ДЦ может Веб-нода составлять часы. Веб-нода Веб-нода Веб-нода Веб-нода Веб-нода Кэш Кэш Кэш Кэш Кэш Кэш «Веб-кластер», БД ДЦ в Германии БД БД БД БД БД Веб-нода Веб-нода Веб-нода Кэш Кэш Кэш БД БД БД
  • 12. Облачное хранилищефайлов ДЦ в России ДЦ в США Посетители Веб-сервер Веб-сервера Веб-сервер Веб-сервера Веб-серверы Веб-серверы Веб-приложение Веб-приложение Облачное хранилище БД (master) файлов (Amazon S3, БД (master) Azure, Google Storage, OpenStack Swift) + CDNslave slave
  • 13. Из «бизнес-требований»появились технические Отказоустойчивость – умение размещаться сразу в нескольких разных территориально распределенных датацентрах (в разных странах) Большой объем базы данных – шардинг – возможность разделить базу данных по территории и группам клиентов MultiTenancy архитектура Полное разделение логики (кода продукта) и данных Пользовательские данные – это большой объем статических файлов и база данных Универсальный API платформы для многолетней разработки Динамическое масштабирование по нагрузке
  • 14. Выбор платформы дляразворачивания инфраструктуры Минусы размещения на собственном оборудовании: Необходимы вложения в инфраструктуру на старте проекта Сложность масштабирования Сложность администрирования (в случае размещения в территориально удаленных датацентрах) Создание всех сопутствующих сервисов с нуля «Когда мы только начинали работу над стартапом (FriendFeed), нам нужно было решить, покупать собственные серверы или же выбрать одного из «облачных» хостинг-провайдеров – таких как Amazon (AWS). Мы выбрали первое – решили приобрести собственные серверы. Оглядываясь назад, я думаю, что это было большой ошибкой» Брет Тейлор технический директор Facebook
  • 15. Используем все возможности масштабирования вAmazon – исходя из экономики проекта.
  • 16. Web – автоматическоемасштабирование Используем связку Elastic Load Balancing + CloudWatch + Auto Scaling Очень высокая посещаемость Elastic Load Balancing Web 1 Web 2 … Web N CloudWatch + Auto Scaling
  • 17. Web – автоматическоемасштабирование Используем связку Elastic Load Balancing + CloudWatch + Auto Scaling Автоматически стартуют новые машины, если средняя нагрузка CPU превышает 50% (по метрикам CloudWatch) Автоматически останавливаются и выводятся из эксплуатации, если средняя нагрузка менее 20%
  • 18. Специфика web-нодЕсть несколько задач, которыенеобходимо решить: На веб-нодах нет пользовательского контента, все ноды должны быть абсолютно идентичны. Read only. Никакие пользовательские данные не пишутся и не сохраняются на веб-нодах, так как в любой момент времени любая машина может быть выключена или стартует новая из «чистого» образа. При этом необходимо обеспечить изоляцию пользователей друг от друга.
  • 19. Специфика web-нодНет Apache. Есть PHP-FPM + nginxУ каждого клиента свой доменБыл разработан модуль для PHP: проверяет корректность домена, завершает хит с ошибкой, если имя некорректно устанавливает соединение с нужной базой в зависимости от домена обеспечивает безопасность и изоляцию пользователей друг от друга служит для шардинга данных разных пользователей по разным базам
  • 20. Статический контентпользователей сервиса Статические данные пользователей храним в S3 Загрузка осуществляется «прозрачно» для пользователей – они работают с привычными интерфейсами Правильно формируются url’ы к картинкам, документам и т.п. Для каждого созданного Корпоративного портала создается персональный аккаунт – данные каждого КП полностью изолированы друг от друга
  • 21. Готов только первый «двигательсамолета» Elastic Elastic Load Balancing Load Balancing Web 1 Web 2 … Web N S3 Web 1 Web 2 … Web NДатацентр 1 в MySQL MySQL Датацентр 2 врегионе US East master master регионе US East master-master(Virginia) репликация (Virginia)Мониторинг и Мониторинг имасштабирование – масштабирование –CloudWatch + CloudWatch +AutoScaling AutoScaling management, monitoring, MySQL backup
  • 22. Используем master-masterрепликацию в MySQL Особенности настройки MySQL: auto_increment_increment auto_increment_offset Базы в разных датацентрах синхронны, при этом независимы друг от друга: потеря связности между датацентрами может составлять часы, данные синхронизируются после восстановления. Пользователь и все сотрудники этой компании работают в одном датацентре за счет управления балансировщиком.
  • 23. Сценарий 1: авария на одной илинескольких веб-нодах Elastic Load Balancing Web 1 Web 2 … Web N S3 Web 1 Web 2 … Web NДатацентр 1 в MySQL MySQL Датацентр 2 врегионе US East master master регионе US East master-master(Virginia) репликация (Virginia)Мониторинг и Мониторинг имасштабирование – масштабирование –CloudWatch + CloudWatch +AutoScaling AutoScaling management, monitoring, MySQL backup
  • 24. Сценарий 1: авария на одной илинескольких веб-нодах Load Balancing определяет вышедшие из строя машины Исходя из заданных параметров группы балансировки, автоматически восстанавливается нужное количество машин
  • 25. Сценарий 1: авария на одной илинескольких веб-нодах Elastic Load Balancing Web 1 Web 2 … Web N S3 Web 1 Web 2 … Web NДатацентр 1 в MySQL MySQL Датацентр 2 врегионе US East master master регионе US East master-master(Virginia) репликация (Virginia)Мониторинг и Мониторинг имасштабирование – масштабирование –CloudWatch + CloudWatch +AutoScaling AutoScaling management, monitoring, MySQL backup
  • 26. Сценарий 2: потеря связностимежду датацентрами Elastic Elastic Elastic Load Balancing Load Balancing Load Balancing Web 1 Web 2 … Web N S3 Web 1 Web 2 … Web NДатацентр 1 в MySQL MySQL Датацентр 2 врегионе US East master master регионе US East master-master(Virginia) репликация (Virginia)Мониторинг и Мониторинг имасштабирование – масштабирование –CloudWatch + CloudWatch +AutoScaling AutoScaling management, monitoring, MySQL backup
  • 27. Сценарий 2: потеря связностимежду датацентрами Каждый датацентр продолжает обслуживать свой сегмент клиентов Данные синхронизируются после восстановления связности
  • 28. Сценарий 3: плановые работы сбазой или авария всего ДЦ Elastic Load Balancing Web 1 Web 2 … Web N S3 Web 1 Web 2 … Web NДатацентр 1 в MySQL MySQL Датацентр 2 врегионе US East master master регионе US East master-master(Virginia) репликация (Virginia)Мониторинг и Мониторинг имасштабирование – масштабирование –CloudWatch + CloudWatch +AutoScaling AutoScaling management, monitoring, MySQL backup
  • 29. Сценарий 3: авария илиплановые работы с базой Весь траффик переключается в один работающий датацентр CloudWatch определяет возросшую нагрузку на машины и добавляет их в соответствие с правилами для AutoScaling Приостанавливается мастер-мастер репликация Проводятся все необходимые работы с базой, на которую не идет нагрузка База включается в работу, восстанавливается репликация Траффик распределяется на оба датацентра Гасятся лишние машины, если средняя нагрузка стала ниже порогового значения
  • 30. MySQL? Percona Server! Один из выводов в процессе эксплуатации: используем один из fork’ов MySQL – Percona Server (обратно совместим с MySQL) Быстрое восстановление кэша при рестарте базы Оптимизирован для Multitenancy приложений с тысячами таблиц Оптимизирован для сбора статистики по отдельным пользователям Подробная статистика по медленным запросам XtraDB и XtraBackup BLOB, TEXT в таблицах MEMORY (HEAP)
  • 31. Конфигурация машинс базами MySQL Виртуальная машина (EC2) «Узким» местом может оказаться производительность дисковой системы. Решение – из EBS дисков Amazon можно построить software RAID. Выбираем RAID-10, так как он и быстрый, и надежный.
  • 32. Бэкап базы данных Еще один вывод: для разных сценариев восстановления данных необходимо использовать разные бэкапы. Для восстановления целого сервера БД в случае аварии используем образ машин со всеми дисками (AMI) – делаем целостный бэкап RAID’а, используя файловую систему, поддерживающую freeze и механизм snapshot’ов в Амазоне. Логические (mysqldump) и бинарные инкрементальные (Xtrabackup) бэкапы используются для восстановления отдельных баз или таблиц, поврежденных в случае некорректных операций в системе или ошибок пользователей. Второй тип бэкапов делается на выделенном slave, на который не распределяется общая нагрузка. Тем самым ресурсоемкие операции создания бэкапов не влияют на работу пользователей.
  • 33. Обновления ПО на web-нодах Как ставить обновления на нодах, не допустив рассинхронизации данных (веб и база) Сервер Новый обновлений образ AMI Web 1 Elastic Load Web 2 Balancing Web N
  • 34. Итоговая архитектура Bitrix24 HTTP/HTTPS HTTP/HTTPS HTTP/HTTPS *.com *.com *.ru *.ru Elastic Elastic Load Balancing Load Balancing CloudWatch CloudWatch + + … S3 … AutoScaling AutoScaling Web 1 Web 2 Web N Web 1 Web 2 Web N cache MySQL MySQL cache master master master-master репликация management, CloudWatch monitoring, CloudWatch MySQL backup
  • 35. НадежностьОдин из приоритетов –постоянная доступность сервиса,его отказоустойчивость. Все веб-ноды идентичны и не зависимы друг от друга, в случае аварии автоматически стартуют новые. Два датацентра синхронизированы друг с другом и равноценно обслуживают клиентов. В случае аварии на уровне датацентра или плановых работ с базой, траффик прозрачно для клиентов переключается на рабочий датацентр.
  • 36. Мониторинг Мониторим все, но аккуратно Мгновенные уведомления (sms) Автоматика
  • 37. …и аналитика Логи Pinba и т.п. Munin и т.п.
  • 38. Надежность «облака» Само по себе «облако» не надежнее традиционного хостинга и собственного оборудования. «Облако» дает возможность организовать надежную инфраструктуру.
  • 39. Битрикс24www.bitrix24.ru
  • 40. Спасибо за внимание!Вопросы?Александр Демидовdemidov@1c-bitrix.ru+7 (915) 201-1500 @demidovhttp://www.1c-bitrix.ru