Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

1,537 views

Published on

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

Published in: Technology
  • Be the first to comment

  • Be the first to like this

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

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

×