Архитектура	  и	  запуск	  облачного	  сервиса	  в	  Amazon	  AWS.	  Как	  обеспечить	  реальные	  24?	  	                ...
Цель	  на	  2012	  годЗадача	  для	  компании	  в	  2012	  году	  –	  запустить	  в	  коммерческую	  эксплуатацию	  «Битри...
Битрикс24
Битрикс24
Запускаем	  новый	  SaaS-­‐сервис	  «Битрикс24» Есть	  несколько	  задач	  на	  старте	  и	   в	  процессе	  работы	    • ...
Из	  «бизнес-­‐требований»	   появились	  технические   •  Отказоустойчивость	  –	  умение	  размещаться	  сразу	  в	  нес...
Независимые	      факторы	  надежностиЧеловечество	  уже	  сделало	  определенный	  путь	  для	  обеспечения	  независимых...
Традиционное	  устройство	  веб-­‐продуктов	                                                 Веб-­‐приложение	  	         ...
1	  этап	  :	  Веб-­‐кластер	  	                                           Балансировщик	  (клиентские	  запросы	         ...
Облачная	  платформа:	  веб-­‐кластер	  	  •  Вертикальный	  шардинг	  (вынесение	  модулей	  на	  отдельные	  серверы	   ...
2	  этап	  –	  гео	  веб-­‐кластер	                                    Асинхронная	  master-­‐master	  репликация	        ...
Облачное	  хранилище	  файлов	      ДЦ в России                                                               ДЦ в США    ...
Платформа	  для	  разработки	  облачных	  веб-­‐сервисов •  В	  версии	  10.	  0	  реализована	  поддержка	  веб-­‐кластер...
Из	  «бизнес-­‐требований»	  появились	  технические•  Отказоустойчивость	  –	  умение	  размещаться	  сразу	  в	  несколь...
Выбор	  платформы	  для	  разворачивания	  инфраструктуры	   Минусы	  размещения	  на	   собственном	  оборудовании:	   • ...
Используем	  все	  возможности	  масштабирования	  в	  Amazon,	  исходя	  из	  экономики	  проекта.	  
Архитектура	  «Битрикс24»	                                                                           ElasZc	              ...
Web	  –	  автоматическое	  масштабирование	  Используем	  связку	  Elaswc	  Load	  Balancing	  +	  CloudWatch	  +	  Auto	 ...
Web	  –	  автоматическое	  масштабирование	  Используем	  связку	  Elaswc	  Load	  Balancing	  +	  CloudWatch	  +	  Auto	 ...
 	  Специфика	  веб-­‐нод	  Есть	  несколько	  задач,	  которые	  необходимо	  решить:	  	  •  На	  веб-­‐нодах	  нет	  по...
 	  Специфика	  веб-­‐нод	  •  Нет	  Apache.	  Есть	  PHP-­‐FPM	  +	  nginx	  •  У	  каждого	  клиента	  свой	  домен	  • ...
Bitrix24	  -­‐	  cвой	  модуль	  для	  PHP	  	        •  Обеспечивает	  переопределние	  функции	  соединения	           с...
Статический	  контент	     пользователей	  сервиса	  "   Статические	  данные	  пользователей	      храним	  в	  S3.	  "  ...
Полная	  изоляция	  данных	  	   •  Данные	  одной	  компании	  полностью	  изолированы	  от	  данных	      другой.	  	   ...
Готов	  только	  первый	       «двигатель	  самолета»	                             ElasZc	                                ...
Используем	  master-­‐master	  репликацию	  в	  MySQL	   •  Особенности	  настройки	  MySQL:	         •  auto_increment_in...
Сценарий	  1:	  авария	  на	  одной	    или	  нескольких	  веб-­‐нодах	                                                   ...
Сценарий	  1:	  авария	  на	  одной	  или	  нескольких	  веб-­‐нодах	  "   Load	  Balancing	  определяет	  вышедшие	  из	 ...
Сценарий	  1:	  авария	  на	  одной	    или	  нескольких	  веб-­‐нодах	                                                   ...
Сценарий	  2:	  потеря	  связности	    между	  датацентрами	                             ElasZc	                          ...
Сценарий	  2:	  потеря	  связности	  между	  датацентрами	  "   Каждый	  датацентр	  продолжает	  обслуживать	  свой	  сег...
Сценарий	  3:	  плановые	  работы	  с	       базой	  или	  авария	  всего	  ДЦ	                                           ...
Сценарий	  3:	  плановые	  работы	  с	   базой	  или	  авария	  всего	  ДЦ	  "   Весь	  трафик	  переключается	  в	  один	...
MySQL?	  Percona	  Server!	  Один	  из	  выводов	  в	  процессе	  эксплуатации:	  используем	  один	  из	  fork’ов	  MySQL...
Конфигурация	  машин	  с	  базами	  MySQL   Виртуальная	  машина	  (EC2)	     -­‐	  Extra	  Large	  Instance	  –	  15	    ...
Бэкап	  базы	  данных	  Еще	  один	  вывод:	  для	  разных	  сценариев	  восстановления	  данных	  необходимо	  использова...
Обновления	  ПО	  на	  веб-­‐нодах	   Как	  ставить	  обновления	  на	  нодах,	  не	  допустив	   рассинхронизации	  данны...
Контроллер	  	  Используется	  для	  логического	  управления	  проектами,	  выполнения	  любых	  команд,	  SQL-­‐запросов...
Итоговая	  архитектура	  Битрикс24	                                 HTTP/HTTPS	                                           ...
 	  Надежность	  Один	  из	  приоритетов	  –	  постоянная	  доступность	  сервиса,	  его	  отказоустойчивость.	  "   Все	 ...
Идет	  тестирование                                               Ваш	  персональный	                                     ...
Следите	  за	  нами!	                	                	     twi¦er.com/1C_Bitrix	                	                	       ...
Спасибо	  за	  внимание!	  Вопросы?	  
Upcoming SlideShare
Loading in …5
×

CodeFest 2012. Рыжиков С. — Архитектура и запуск облачного сервиса в Amazon AWS. Как обеспечить реальные 24?

1,183 views

Published on

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

  • Be the first to like this

No Downloads
Views
Total views
1,183
On SlideShare
0
From Embeds
0
Number of Embeds
402
Actions
Shares
0
Downloads
10
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

CodeFest 2012. Рыжиков С. — Архитектура и запуск облачного сервиса в Amazon AWS. Как обеспечить реальные 24?

  1. 1. Архитектура  и  запуск  облачного  сервиса  в  Amazon  AWS.  Как  обеспечить  реальные  24?     Сергей  Рыжиков   генеральный  директор   компании  «1С-­‐Битрикс»  
  2. 2. Цель  на  2012  годЗадача  для  компании  в  2012  году  –  запустить  в  коммерческую  эксплуатацию  «Битрикс24»    •  Аренда  Корпоративного  портала  как  инструмента  социального   интранета  •  Развитие  социального  Project-­‐  и  Task-­‐менеджмента  •  Развитие  Social  CRM  -­‐  готового,  простого  в  использовании   решения      •  Собрать  и  накопить  опыт  по  эксплуатации  облачных  веб-­‐ сервисов,  поделиться  им  с  партнерами  
  3. 3. Битрикс24
  4. 4. Битрикс24
  5. 5. Запускаем  новый  SaaS-­‐сервис  «Битрикс24» Есть  несколько  задач  на  старте  и   в  процессе  работы   •  Новый  SaaS  сервис  –  как  коммерческие,  так  и  «бесплатные»   пользователи   •  Минимизация  расходов  на  эксплуатацию  и  снижение  финансовых   рисков  на  старте  проекта   •  Масштабирование  при  росте  нагрузки  и  обратное  масштабирование   •  Надежность  –  обеспечение  SLA   •  Работа  с  разными  рынками:  США,  Европа,  Россия   •  Быстрая  отдача  статического  контента  
  6. 6. Из  «бизнес-­‐требований»   появились  технические •  Отказоустойчивость  –  умение  размещаться  сразу  в  нескольких   разных  территориально  распределенных  датацентрах  (в  разных   странах)   •  MulJTenancy  архитектура   •  Полное  разделение  логики  (кода  продукта)  и  данных   •  Пользовательские  данные  –  это  большой  объем  статических  файлов   и  база  данных   •  Универсальный  API  платформы  для  многолетней  разработки   •  Динамическое  масштабирование  по  нагрузке  Две  итоговые  задачи:   •  Выбор  технической  платформы  для  инфраструктуры   •  Выбор  платформы  разработки  
  7. 7. Независимые   факторы  надежностиЧеловечество  уже  сделало  определенный  путь  для  обеспечения  независимых  факторов  надежности.      Для  «Битрикс24»  нужен  аналогичный  подход  –  продолжать  работу  без  потери  данных  в  случае  выхода  из  строя  одного  ДЦ  и  быть  способными  восстанавливать  базы  данных  за  несколько  минут.  
  8. 8. Традиционное  устройство  веб-­‐продуктов   Веб-­‐приложение     Кэширование   на  диск   База  данных  Обычный  продукт  не  поддерживает  гео  веб-­‐кластер,  облачные  файлы,  распределенное  кэширование,  mulwtenancy…  
  9. 9. 1  этап  :  Веб-­‐кластер     Балансировщик  (клиентские  запросы   по  HTTP)   Веб-­‐сервер  1   Веб-­‐сервер  2         MySQL   MySQL     memcached  1   memcached  2   master   slave  
  10. 10. Облачная  платформа:  веб-­‐кластер    •  Вертикальный  шардинг  (вынесение  модулей  на  отдельные  серверы   MySQL)  •  Репликация  MySQL  и  балансирование  нагрузки  между  серверами  •  Распределенный  кеш  данных  (memcached)  •  Непрерывность  сессий  между  веб-­‐серверами  (хранение  сессий  в  базе   данных)  •  Кластеризация  веб-­‐сервера:   –  Синхронизация  файлов  (это  –  проблема  для  облачного  сервиса)   –  Балансирование  нагрузки  между  серверами    
  11. 11. 2  этап  –  гео  веб-­‐кластер   Асинхронная  master-­‐master  репликация   «Веб-­‐кластер»,     для  обеспечения  работы  географически   «Веб-­‐кластер»,     ДЦ  в  России   распределенных  веб-­‐кластеров.   ДЦ  в  США     Потеря  связи  между  ДЦ  может   Веб-­‐нода   составлять  часы.   Веб-­‐нода   Веб-­‐нода   Веб-­‐нода   Веб-­‐нода   Веб-­‐нода   Кэш   Кэш   Кэш   Кэш   Кэш   Кэш   «Веб-­‐кластер»,     БД   ДЦ  в  Германии   БД   БД   БД   БД   БД   Веб-­‐нода   Веб-­‐нода   Веб-­‐нода   Кэш   Кэш   Кэш   БД   БД   БД  
  12. 12. Облачное  хранилище  файлов   ДЦ в России ДЦ в США Посетители Веб-сервер Веб-сервера Веб-сервер Веб-сервера Веб-серверы Веб-серверы Веб-­‐приложение Веб-приложение Облачное  хранилище  файлов  (Amazon   БД (master) S3,  Azure,  Google  Storage,  OpenStack   БД (master) Swi…)  +  CDN  slave slave
  13. 13. Платформа  для  разработки  облачных  веб-­‐сервисов •  В  версии  10.  0  реализована  поддержка  веб-­‐кластера.   •  В  версии  11.0  –  географический  веб-­‐кластер  master-­‐master.   •  В  версии  11.0  –  поддержка  облачных  хранилищ,  тайм-­‐зон,   автомасштабирования.     •  В  2011  году  разработана  облачная  архитектура  эксплуатации  в   Амазоне.   •  Накоплен  опыт  работы  в  Амазоне  ,  опыт  эксплуатации  и   особенности  работы  в  облачной  инфраструктуре.     •  В  конце  2011  г  была  запущена  первая  опытная  версия  сервиса   «Битрикс24».    
  14. 14. Из  «бизнес-­‐требований»  появились  технические•  Отказоустойчивость  –  умение  размещаться  сразу  в  нескольких  разных   территориально  распределенных  датацентрах  (в  разных  странах)  •  Большой  объем  базы  данных  –  шардинг  –  возможность  разделить   базу  данных  по  территории  и  группам  клиентов  •  MulJTenancy  архитектура  •  Полное  разделение  логики  (кода  продукта)  и  данных  •  Пользовательские  данные  –  это  большой  объем  статических  файлов  и   база  данных  •  Универсальный  API  платформы  для  многолетней  разработки  •  Динамическое  масштабирование  по  нагрузке  
  15. 15. Выбор  платформы  для  разворачивания  инфраструктуры   Минусы  размещения  на   собственном  оборудовании:   •  Необходимы  вложения  в  инфраструктуру  на  старте  проекта   •  Сложность  масштабирования   •  Сложность  администрирования  (в  случае  размещения  в   территориально  удаленных  датацентрах)   •  Создание  всех  сопутствующих  сервисов  с  нуля   «Когда  мы  только  начинали  работу  над  стартапом  (FriendFeed),  нам  нужно   было  решить,  покупать  собственные  серверы  или  же  выбрать  одного  из   «облачных»  хостинг-­‐провайдеров  –  таких  как  Amazon  (AWS).  Мы  выбрали   первое  –  решили  приобрести  собственные  серверы.  Оглядываясь  назад,  я   думаю,  что  это  было  большой  ошибкой»     Брет  Тейлор   технический  директор  Facebook  
  16. 16. Используем  все  возможности  масштабирования  в  Amazon,  исходя  из  экономики  проекта.  
  17. 17. Архитектура  «Битрикс24»   ElasZc   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  
  18. 18. Web  –  автоматическое  масштабирование  Используем  связку  Elaswc  Load  Balancing  +  CloudWatch  +  Auto  Scaling   Очень  высокая  посещаемость   ElasZc  Load  Balancing         …      Web  1   Web  2      Web  N     CloudWatch  +  Auto  Scaling  
  19. 19. Web  –  автоматическое  масштабирование  Используем  связку  Elaswc  Load  Balancing  +  CloudWatch  +  Auto  Scaling  "   Автоматически  стартуют  новые  машины,  если  средняя  нагрузка  CPU  превышает   60%  "   Автоматически  останавливаются  и  выводятся  из  эксплуатации,  если  средняя   нагрузка  менее  30%  "   Ставили  верхний  порог  на  80%,  однако  начинается  общая  деградация  системы   –  пользователям  работать  некомфортно  (долго  загружаются  страницы)  
  20. 20.    Специфика  веб-­‐нод  Есть  несколько  задач,  которые  необходимо  решить:    •  На  веб-­‐нодах  нет  пользовательского   контента,  все  ноды  должны  быть   абсолютно  идентичны.  •  Read  only.  Никакие  пользовательские   данные  не  пишутся  и  не  сохраняются   на  веб-­‐нодах,  так  как  в  любой  момент   времени  любая  машина  может  быть   выключена  или  стартует  новая  из   «чистого»  образа.  •  При  этом  необходимо  обеспечить   изоляцию  пользователей  друг  от   друга.  
  21. 21.    Специфика  веб-­‐нод  •  Нет  Apache.  Есть  PHP-­‐FPM  +  nginx  •  У  каждого  клиента  свой  домен  •  Был  разработан  модуль  для  PHP:   •  проверяет  корректность  домена,   завершает  хит  с  ошибкой,  если  имя   некорректно   •  устанавливает  соединение  с   нужной  базой  в  зависимости  от   домена   •  обеспечивает  безопасность  и   изоляцию  пользователей  друг  от   друга   •  служит  для  шардинга  данных   разных  пользователей  по  разным   базам  
  22. 22. Bitrix24  -­‐  cвой  модуль  для  PHP     •  Обеспечивает  переопределние  функции  соединения   с  базой  данных.     •  В  отдельной  таблице  хранит  строки  соединения  с   разными  мастерами  и  «слейвами»,   обслуживающими  БД.   •  Позволяет  выполнять  горизонтальное   масштабирование  БД  (шардинг)  по  любому   количеству  серверов  вплоть  до  «один  клиент  на   одном  сервере».   •  Обеспечивает  запуск  (fork)  процессов  для  PHP  и   быструю  отдачу  страницы  пользователю.    
  23. 23. Статический  контент   пользователей  сервиса  "   Статические  данные  пользователей   храним  в  S3.  "   Загрузка  осуществляется   «прозрачно»  для  пользователей  –   они  работают  с  привычными   интерфейсами.  "   Правильно  формируются  url’ы  к   картинкам,  документам  и  т.п.  "   Для  каждого  созданного   Корпоративного  портала  создается   персональный  аккаунт  –  данные   каждого  КП  полностью  изолированы   друг  от  друга.  
  24. 24. Полная  изоляция  данных     •  Данные  одной  компании  полностью  изолированы  от  данных   другой.     •  Для  каждого  клиента  данные  хранятся  раздельно:     o  свой  логин  пароль  к  БД     o  своя  БД  со  структурой  таблиц     o  свое  облачное  хранилище  S3  с  отдельным  логином/ паролем   o  отдельное  пространство  для  кеширования  данных     •  Все  веб-­‐ноды  могут  обслуживать  любых  клиентов,  набор   данных  определяется  по  домену  и  не  может  быть  изменен.    
  25. 25. Готов  только  первый   «двигатель  самолета»   ElasZc   ElasZc   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  
  26. 26. Используем  master-­‐master  репликацию  в  MySQL   •  Особенности  настройки  MySQL:   •  auto_increment_increment   •  auto_increment_offset   •  Базы  в  разных  датацентрах  синхронны,  при  этом  независимы  друг  от   друга:  потеря  связности  между  датацентрами  может  составлять  часы,   данные  синхронизируются  после  восстановления.   •  В  любое  время  можно  добавить  новые  датацентры.   •  Пользователь  и  все  сотрудники  этой  компании  работают  в  одном   датацентре  за  счет  управления  балансировщиком.   •  Сессии  храним  в  базе,  но  не  реплицируем  между  серверами  из-­‐за   большого  траффика:   •  SET  sql_log_bin  =  0      …  или  …   •  replicate-­‐wild-­‐ignore-­‐table  =  %.b_sec_session%  
  27. 27. Сценарий  1:  авария  на  одной   или  нескольких  веб-­‐нодах   ElasZc   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  
  28. 28. Сценарий  1:  авария  на  одной  или  нескольких  веб-­‐нодах  "   Load  Balancing  определяет  вышедшие  из  строя  машины.  "   Исходя  из  заданных  параметров  группы  балансировки,   автоматически  восстанавливается  нужное  количество   машин.  
  29. 29. Сценарий  1:  авария  на  одной   или  нескольких  веб-­‐нодах   ElasZc   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  
  30. 30. Сценарий  2:  потеря  связности   между  датацентрами   ElasZc   ElasZc   ElasZc   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  
  31. 31. Сценарий  2:  потеря  связности  между  датацентрами  "   Каждый  датацентр  продолжает  обслуживать  свой  сегмент   клиентов.  "   Данные  синхронизируются  после  восстановления   связности.  
  32. 32. Сценарий  3:  плановые  работы  с   базой  или  авария  всего  ДЦ   ElasZc   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  
  33. 33. Сценарий  3:  плановые  работы  с   базой  или  авария  всего  ДЦ  "   Весь  трафик  переключается  в  один  работающий  датацентр.  " CloudWatch  определяет  возросшую  нагрузку  на  машины  и   добавляет  их  в  соответствие  с  правилами  для  AutoScaling.  "   Приостанавливается  мастер-­‐мастер  репликация.  "   Проводятся  все  необходимые  работы  с  базой,  на  которую   не  идет  нагрузка.  "   База  включается  в  работу,  восстанавливается  репликация.  "   Траффик  распределяется  на  оба  датацентра.  "   Гасятся  лишние  машины,  если  средняя  нагрузка  стала  ниже   порогового  значения.  
  34. 34. MySQL?  Percona  Server!  Один  из  выводов  в  процессе  эксплуатации:  используем  один  из  fork’ов  MySQL  –  Percona  Server  (обратно  совместим  с  MySQL)  •  Оптимизирован  для  работы  в  «облаке»  (с  относительно  медленными  дисками)  •  Быстрое  восстановление  кэша  при  рестарте  базы  •  Оптимизирован  для  Mulwtenancy  приложений  с  тысячами  таблиц    •  Оптимизирован  для  сбора  статистики  по  отдельным  пользователям  •  Подробная  статистика  по  медленным  запросам    •  XtraDB  и  XtraBackup  
  35. 35. Конфигурация  машин  с  базами  MySQL Виртуальная  машина  (EC2)   -­‐  Extra  Large  Instance  –  15   Gb  RAM  Этапы  масштабирования:    1)  Вертикальное  масштабирование   (дисковая  система  RAID-­‐10  на  EBS)    2)  Веб-­‐кластер  master-­‐slave.  Запуск   необходимого  числа  слейвов  в   конфигурации  веб-­‐кластера   master-­‐slave  3)  Горизонтальное   масштабирование,  разделение   мастера  на  несколько  серверов      Все  этапы  выполняются  без  остановки  сервиса.    
  36. 36. Бэкап  базы  данных  Еще  один  вывод:  для  разных  сценариев  восстановления  данных  необходимо  использовать  разные  бэкапы.  "   Для  восстановления  целого  сервера  БД  в  случае  аварии  используем   образ  машин  со  всеми  дисками  (AMI)  –  делаем  целостный  бэкап   RAID’а,  используя  файловую  систему,  поддерживающую  freeze  и   механизм  snapshot’ов  в  Амазоне.  "   Логические  (mysqldump)  и  бинарные  инкрементальные  (Xtrabackup)   бэкапы  используются  для  восстановления  отдельных  баз  или  таблиц,   поврежденных  в  случае  некорректных  операций  в  системе  или  ошибок   пользователей.  "   Второй  тип  бэкапов  делается  на  выделенном  slave,  на  который  не   распределяется  общая  нагрузка.  Тем  самым  ресурсоемкие  операции   создания  бэкапов  не  влияют  на  работу  пользователей.  
  37. 37. Обновления  ПО  на  веб-­‐нодах   Как  ставить  обновления  на  нодах,  не  допустив   рассинхронизации  данных  (веб  и  база)      Сервер      Новый   обновлений   образ  AMI        Web  1       ElasZc     Load    Web  2   Balancing      Web  N  
  38. 38. Контроллер    Используется  для  логического  управления  проектами,  выполнения  любых  команд,  SQL-­‐запросов  и  PHP-­‐кода  на  любой  из  копии  проекта.      Обеспечивает  биллинг,  включение  тарифных  планов,  ограничения  по  пользователям,  дисковому  пространству  и  т.д.  
  39. 39. Итоговая  архитектура  Битрикс24   HTTP/HTTPS   HTTP/HTTPS   HTTP/HTTPS   *.com   *.com   *.ru   *.ru   ElasZc   ElasZc   Load  Balancing   Load  Balancing   CloudWatch   CloudWatch               … … +   +                   AutoScaling     S3       AutoScaling      Web  1    Web  2    Web  N    Web  1    Web  2    Web  N   cache   MySQL   MySQL   cache   master   master   master-­‐master   репликация   MySQL  slave   MySQL  slave   management,   CloudWatch     monitoring,   CloudWatch     MySQL  backup  
  40. 40.    Надежность  Один  из  приоритетов  –  постоянная  доступность  сервиса,  его  отказоустойчивость.  "   Все  веб-­‐ноды  идентичны  и  не   зависимы  друг  от  друга,  в  случае   аварии  автоматически  стартуют   новые.  "   Два  датацентра  синхронизированы   друг  с  другом  и  равноценно   обслуживают  клиентов.  В  случае   аварии  на  уровне  датацентра  или   плановых  работ  с  базой,  трафик   прозрачно  для  клиентов   переключается  на  рабочий   датацентр.  
  41. 41. Идет  тестирование Ваш  персональный   «инвайт»  на  Битрикс24   XXX-­‐XXX-­‐XX  •  Не  раздавайте  «инвайты»,  используйте  только  сами!  •  Для  тестирования  ограничение  по  пользователям  не   установлено.    •  Тем,  кто  перейдет  на  использование  компанией,  сервис   предоставим  бесплатно  (50  Гб).  
  42. 42. Следите  за  нами!       twi¦er.com/1C_Bitrix         facebook.com/1CBitrix           www.1c-­‐bitrix.ru  
  43. 43. Спасибо  за  внимание!  Вопросы?  

×