1с битрикс веб кластер. И еще в коробочной версии сервиса
C «Битрикс24» можно работать как с облачным сервисом, так и установить как программный продукт отдельно внутри компании.В чем отличие? Коробочная версия - «1С-Битрикс24» - устанавливается на ваш сервер, размещенный в вашей компании или у хостинг-провайдера.
Вы можете индивидуально настроить бизнес-логику корпоративного портала, доработать интерфейс, интегрировать с «1С:ЗУП» и многое другое.
Сравнить с «облаком»Веб-кластер
Постройте свой Веб-кластер - повысьте производительность, масштабируемость и надежность вашего портала!Веб-кластер позволяет распределить один портал на несколько серверов, решая тем самым несколько задач: обеспечение высокой доступности портала; его масштабирование в условиях возрастающей нагрузки; балансирование нагрузки, трафика, данных между несколькими серверами.
Виртуальная машина
«1C-Битрикс: Виртуальная машина» - бесплатный программный продукт, готовый к немедленному использованию виртуальный сервер, полностью настроенный, протестированный и адаптированный для оптимальной работы как с продуктами «1С-Битрикс», так и с любыми PHP-приложениями.С этим продуктом вы экономите время и деньги на развертывании и настройке корпоративного портала, на покупке необходимого оборудования, на обеспечении безопасности проекта.
Контроллер для интеграции с внешним сайтом
Контроллер сайтов - это принципиально новое технологическое решение, задача которого состоит в том, чтобы в едином месте консолидировать управление над множеством совершенно независимых друг от друга веб-проектов, построенных на отдельных копиях продукта «1С-Битрикс: Управление сайтом» вне зависимости от их физического расположения.Персональный генератор одноразовых паролей (OTP)
Использование одноразовых паролей позволит существенно повысить вашу безопасность при работе с сайтом или корпоративным порталом. Одноразовые пароли не позволят злоумышленнику получить доступ к вашим персональным данным на сайте, даже если ваш пароль будет украден или перехвачен.С помощью Bitrix OTP вы сможете самостоятельно включать или отключать использование на портале системы одноразовых паролей для своей учетной записи.
Администрирование корпоративного портала
Коробочная версия сервиса содержит административную часть, позволяющую полностью управлять структурой корпоративного портала, настраивать его инструменты, управлять доступом к системе, пользователями, группами пользователей и содержимым портала.Администраторы могут работать непосредственно из публичной части портала. Для этого им достаточно авторизоваться и включить режим правки в Панели управления. В этом режиме еще легче выполнять все типовые операции, например, добавлять
Учебный курс: «Администратор сервиса Битрикс24 (коробочная версия)»
Управление контентом (визуальный редактор страниц)
Визуальный HTML-редактор уже встроен в продукт «1С-Битрикс24», и вам не нужно его устанавливать. С помощью этого редактора вы можете изменять свои страницы на портале в режиме реального времени - прямо через браузер. Редактор позволяет не просто править и форматировать обычный текст, но и работать с визуальными компонентами.Встроенный в продукт визуальный редактор совместим со всеми популярными браузерами!
Расширенное управление правами доступа
Коробочная версия содержит мощную систему управления доступом, которая содержит несколько аспектов:- доступ к модулям;
- доступ к элементам динамического контента;
- доступ к файлам и папкам.
Варианты и кастомизация дизайна
Коробочная версия сервиса поставляется в двух стандартных шаблонах дизайнов: Light и «Битрикс24». Эти варианты удовлетворяют подавляющее большинство пользователей. Однако некоторые компании хотят иметь свой фирменный дизайн.1С-Битрикс: Веб-кластер Основные задачи, которые необходимо решить: 1.Обеспечение высокой доступности сервиса (так называемые HA - High Availability или Failover кластеры) 2.Масштабирование веб-проекта в условиях возрастающей нагрузки (HP - High Performance кластеры) 3.Балансирование нагрузки, трафика, данных между несколькими серверами. 4.Создание целостной резервной копии данных для MySQL.
1С-Битрикс: Веб-кластер «Веб-кластер» обеспечивает непрерывность бизнеса, отказоустойчивость, масштабирование, распределение нагрузки. Любой новый или работающий проект на 1С-Битрикс: Управление сайтом 10.0 может быть представлен как веб-кластер взаимозаменяемых серверов. 1.При увеличении посещаемости можно быстро добавить в кластер новые сервера. 2.В случае выхода из строя одного из серверов кластера система продолжает беспрерывно обслуживать Клиентов. 3.Балансирование нагрузки, трафика, данных между несколькими серверами. 4.Система позволяет снимать резервные копии со специально выделенных узлов кластера, не влияя на работу сайта.
История производительности платформы До 2005 года вопросом производительности системно не занимались год – производительность стала существенной задачей для разработки год – появление инструментов отладки SQL-запросов. Cистемная работа над производительностью продукта год – первое нагрузочное тестирование с QSOFT (1.5 млн. хитов в сутки на редакции «Бизнес», 6 млн. – на редакции «Старт») годы – развернуто 4 конфигурации Oracle RAC с 4 серверами год – «монитор производительности» во всех редакциях продукта годы – выпущены «1С-Битрикс: Виртуальная машина» и «1С- Битрикс: Веб-окружение» – сертификация хостинг-провайдеров год – рост производительности – на 430%! Новые нагрузочные тесты: 8.5 млн. хитов – «Бизнес», 12.4 млн. – «Старт», 85 млн. – «HTML кеш».
Варианты масштабирования до Разделение на два сервера: веб-сервер + база данных. 2.Увеличение мощности оборудования (чем мощнее – тем дороже; рост стоимости не пропорционален). 3.Выделение кеша на один внешний сервер через memcached. 4.Переход на Oracle (минимальная лицензия +5000$ за процессор). 5.Создание Oracle RAC (Real Application Cluster). Проект – около $ (оборудование + лицензия + «общая полка»). Очень мало специалистов. Для большинства клиентов производительности достаточно, но не решены проблемы отказоустойчивости, резервирования, сетевой доступности.
1С-Битрикс: Веб-кластер «1С-Битрикс: Веб-кластер» - это комбинация технологий: Вертикальный шардинг (вынесение модулей на отдельные серверы MySQL) Репликация MySQL (Oracle и MS SQL в дальнейшем) и балансирование нагрузки между серверами Распределенный кеш данных (memcached) Непрерывность сессий между веб-серверами (хранение сессий в базе данных) Кластеризация веб-сервера: – Синхронизация файлов – Балансирование нагрузки между серверами
Hазделение одной базы данных веб- приложения на две и более базы данных за счет выделения отдельных модулей, без изменения логики работы веб- приложения: Веб-аналитика Поиск 1.Эффективное распределение нагрузки. 2.Масштабирование. 3.Разделение больших объемов данных. Вертикальный шардинг
Веб-сервер База данных MySQL Веб-приложение Высокая нагрузка: ~10^3 writes/sec ~10^4 reads/sec Высокая посещаемость 1) Запросы обрабатываются только одним сервером СУБД 2) CPU и дисковая подсистема СУБД – перегружены Масштабирование при росте нагрузки MySQL
Высокая эффективность - за счет централизованного использования кэша веб- приложением Надежность - за счет устойчивости подсистемы кешировния к выходу из строя отдельных компонентов Неограниченная масштабируемость - за счет добавления новых memcached-серверов. memcached 1 memcached 2 memcached 3 Веб-кластер «1С-Битрикс» 40%30% Веб-сервер Распределенный кеш данных (memcached)
Непрерывность сессий между веб-серверами Пользовательская сессия должна быть "прозрачной" для всех серверов веб- кластера. 1.После авторизации на одном из серверов пользователь должен считаться авторизованных и для всех других серверов. 2.И наоборот - окончание сессии на любом сервере должно означать ее окончание на всех серверах сразу.
80% Высокая посещаемость 1) Нагрузка обрабатывается только одним веб-сервером 2) CPU перегружен обработкой PHP, прекомпилятор включен, наблюдаются segmentation faults Задача: масшта" title="Веб-сервер База данных MySQL Веб-приложение Высокая нагрузка на CPU >80% Высокая посещаемость 1) Нагрузка обрабатывается только одним веб-сервером 2) CPU перегружен обработкой PHP, прекомпилятор включен, наблюдаются segmentation faults Задача: масшта" class="link_thumb"> 22 Веб-сервер База данных MySQL Веб-приложение Высокая нагрузка на CPU >80% Высокая посещаемость 1) Нагрузка обрабатывается только одним веб-сервером 2) CPU перегружен обработкой PHP, прекомпилятор включен, наблюдаются segmentation faults Задача: масштабирование при росте нагрузки 80% Высокая посещаемость 1) Нагрузка обрабатывается только одним веб-сервером 2) CPU перегружен обработкой PHP, прекомпилятор включен, наблюдаются segmentation faults Задача: масшта"> 80% Высокая посещаемость 1) Нагрузка обрабатывается только одним веб-сервером 2) CPU перегружен обработкой PHP, прекомпилятор включен, наблюдаются segmentation faults Задача: масштабирование при росте нагрузки"> 80% Высокая посещаемость 1) Нагрузка обрабатывается только одним веб-сервером 2) CPU перегружен обработкой PHP, прекомпилятор включен, наблюдаются segmentation faults Задача: масшта" title="Веб-сервер База данных MySQL Веб-приложение Высокая нагрузка на CPU >80% Высокая посещаемость 1) Нагрузка обрабатывается только одним веб-сервером 2) CPU перегружен обработкой PHP, прекомпилятор включен, наблюдаются segmentation faults Задача: масшта"> title="Веб-сервер База данных MySQL Веб-приложение Высокая нагрузка на CPU >80% Высокая посещаемость 1) Нагрузка обрабатывается только одним веб-сервером 2) CPU перегружен обработкой PHP, прекомпилятор включен, наблюдаются segmentation faults Задача: масшта">
Почему мы выбрали csync2? Быстрый доступ к файлам приложения за счет использования локальных хранилищ. Высокая скорость работы. Низкое потребление ресурсов (CPU, дисковые операции). Два этих фактора позволяют запускать процесс синхронизации максимально часто, поэтому данные на серверах становятся идентичными практически в "реальном времени". Простота настройки для обмена данными между любым количеством серверов. Возможность синхронизации удаления файлов. Защищенный обмен данными между хостами (SSL).
Веб-сервер База данных MySQL MASTER «1С-Битрикс: Веб-кластер» База данных MySQL SLAVE 1 База данных MySQL SLAVE N Он-лайн бэкап данных Диск Целостный логический/физический бэкап MySQL без замедления работы основной системы База данных MySQL MASTER candidate DRBD – он-лайн бэкап диска с базой данных Организация резервного копирования - MySQL
Веб-сервер «1С-Битрикс: Веб-кластер» /var/www LVM /var/www – снепшот 1 /var/www – снепшот 2 /var/www – снепшот 3 Быстрый, целостный бэкап на уровне Linux Быстрый, целостный, инкрементальный, автоматически консолидирумый бэкап инструментами хостера Организация резервного копирования - файлы
«1С-Битрикс: Веб- кластер», ДЦ в Москве БД Веб-нода «1С-Битрикс: Веб-кластер», ДЦ в Нью-Йорке «1С-Битрикс: Веб- кластер», ДЦ в Новосибирске круговой, асинхронной, master-master репликацией для обеспечения работы географически распределенных веб- кластеров 1С-Битрикс Кэш БД Веб-нода Кэш БД Веб-нода Кэш Мы работаем над…
«1С-Битрикс: Веб- кластер», ДЦ в Москве БД Веб-нода «1С-Битрикс: Веб- кластер», ДЦ в Нью-Йорке «1С-Битрикс: Веб- кластер», ДЦ в Новосибирске круговой, асинхронной, master-master репликацией для обеспечения работы географически распределенных веб- кластеров 1С-Битрикс Кэш БД Веб-нода Кэш БД Веб-нода Кэш БД Веб-нода Кэш БД Веб-нода Кэш БД Веб-нода Кэш БД Веб-нода Кэш БД Веб-нода Кэш БД Веб-нода Кэш Мы работаем над…
Устойчивость системы при выключении узлов веб-кластера При отключении узлов кластера система не прерывает обслуживание клиентов. Увеличивается очередь (растет время отдачи страниц клиентам), однако в целом система сбалансирована по нагрузке. Обратное добавление узла веб- кластера пропорционально увеличивает производительность системы. Нагрузочный тест – отключение одного из узлов кластера
Сегодня Битрикс презентовал своё новое решение – “веб-кластер”. Для тех кто не в курсе – поясню, что эта штука позволяет разместить высокопосещаемый проект не на одном, а на нескольких серверах, и в любой момент добавлять новые сервера для ускорения работы сайта. А так же безопасно изымать любой сервер для ремонта, апгрейда, или в случае его выхода из строя. Разумеется, мне как их первому конкуренту (в лице компании Юмисофт) в первую очередь было нужно узнать, что же они принципиально нового предлагают рынку.
А ничего. В хорошем смысле ничего. Битрикс перестал валять дурака и “изобретать велосипед” – видимо попался таки в команду умный технолог, поэтому вместо “велосипедов” они взяли и сделали всё так как принято делать у нормальных людей. В этом посте я расскажу простыми словами – что конкретно они сделали и как вам повторить то же самое в своём проекте.
Рассмотрим основные части кластера:
0. Cloud – облако, набор серверов, на котором всё это будет крутиться.
1. Load balancer – балансировщик входящей нагрузки.
2. MySQL replication – популярный вид кластеризации баз данных.
3. Network file system – распределённое файловое хранилище.
Как было сказано выше, кластер – это набор из произвольного количества веб-серверов. Они могут выполнять одну и ту же задачу, либо разные в зависимости от целей. Начнём с серверов: тут для них предлагается использовать виртуальные машины aws.amazon.com. Я не сказал бы, что это разумное решение: виртуалки априори медленные, но здесь ключевой момент – простота их создания. Нажал на кнопку – создалась. Причём не дефолтная машина, а настроенная конкретно под ваши нужды. Можно создавать по расписанию или вообще динамически при росте нагрузки. Попал ваш сайт под мощный поток посетителей – оно р-р-р-аз и создало несколько новых машин. Кончилась нагрузка – машины отключились. Красота.
Разумеется, в качестве серверов кластера могут выступать любые сервера в интернете: хоть виртуальные, хоть железные. Для справки: свой личный “амазоновский” кластер бесплатно может сделать себе любой человек, который не поленится запустить установку свежего дистрибутива Ubuntu Server.
Балансировщик нужен для того, чтобы распределять входящие запросы посетителей сайта между серверами кластера. В качестве него предлагается использовать nginx, гуглите “nginx load balance” и получаете кучу ссылок на готовые примеры.
Репликация баз данных нужна для того, чтобы записывать данные на одном сервере (он называется master – мастер), а читать их со всех остальных (соответственно slave – слейв). Так как обычно операций записи мало, а операций чтения много, то путём простого увеличения количества слейвов можно неограниченно наращивать “мощность” проекта. Данные с мастера на слейвы перетекают в фоновом режиме чисто средствами MySQL, причём слейвы можно добавлять и убирать в любой момент. Гуглите “mysql replication” и получаете инструкции.
Распределённое файловое хранилище нужно для того, чтобы все сервера имели один и тот же набор файлов. Если пользователь загрузил картинку “куда-то” на один из серверов, то она должна появиться везде. Почему? Потому что другим пользователям информация может быть отдана с другого сервера. Для реализации товарищи из Битрикса рекомендуют “csync2” – оно работает в фоновом режиме и тупо синхронизирует файлы между серверами, чтобы везде всё было одинаково.
Всё. Вот вы и сделали кластер. А теперь – файн-тюнинг:
Первый же камень преткновения, на который вы наткнётесь при переводе своего проекта (я имею в виду проект на другой CMS или самописный) на такую модель – будет в операциях с базой данных. Суть в том, что приложение должно уметь отличать “пишущие” запросы от “читающих”. Другими словами, INSERT, UPDATE, DELETE, а так же CREATE, ALTER и DROP нужно выполнять только на мастере. Запросы SELECT в принципе можно выполнять везде. Чтобы переучить ваш движок на такой способ мышления, потребуется весьма ощутимое время.
Кроме того, битриксоиды придумали интересную штуку: так как данные с мастера на слейвы утекают с некоторой задержкой, они приучили систему распознавать “критические” пишущие запросы. После такого запроса все данные до самого конца выполнения php-скриптов берутся (SELECT) только с мастера во избежание ошибок из-за той самой задержки.
Вторая мысль, которую нужно рассмотреть – это выделение серверов под задачи. Не обязательно делать все сервера одинаковыми и поручать им одинаковые задачи. Пусть часть из них обслуживают, например, интернет-магазин, а другая часть – собирает статистику.
Третья мысль – кластеризация memcached. Битрикс вынес его в начало своей презентации, но вы можете запустить его и позже. Его преимущество в том, что он напрямую вяжется с nginx (помните первый пункт?) и позволяет тому отдавать закэшированные страницы (или блоки) фактически напрямую из оперативной памяти. Ваша задача – точнее задача ваших скриптов – помещать кэшируемый контент в memcached.
Как разрабатывать проект на кластере? Частый вопрос для представителей веб-студий. Да точно так же, как на обычном сервере. Кластер для вас будет всего лишь одним большим компьютером, на который вы точно так же заходите по ssh и работаете.
Я ментор в IT-проектах. Это значит, что если вы - собственник или руководитель, я могу помочь вам взять новую высоту. Навести порядок в процессах, разобраться с мотивацией команды, внедрить инструменты и достичь конкретных целей. Я не учу делать бизнес, а лишь помогаю обойти щедро рассыпанные грабли на вашем пути. .
Любой новый или работающий проект на « » может быть представлен как веб-кластер взаимозаменяемых серверов.Основные задачи, которые позволяет решить подобная конфигурация проекта:
- При увеличении посещаемости можно быстро добавить в кластер новые сервера.
- В случае выхода из строя одного из серверов кластера система продолжает беспрерывно обслуживать Клиентов.
- Балансирование нагрузки, трафика, данных между несколькими серверами.
- Система позволяет снимать резервные копии со специально выделенных узлов кластера, не влияя на работу сайта.
«Географический веб-кластер»
«Географический веб-кластер» повышает отказоустойчивость проекта и обеспечивает независимость от дата-центра. В различных дата-центрах объединяются несколько групп веб-кластеров, находящихся в разных городах или странах. В случае отказа одного дата-центра, в работу мгновенно включается другой, без необходимости восстановления «бэкапа».
Географический веб-кластер позволяет поднимать целые группы серверов. В каждой из этих групп работает свой мастер - в независимых друг от друга датацентрах. Тем самым ваши сайты, ваш бизнес полностью защищены от недоступности самих датацентров.
«1С-Битрикс: Веб-кластер» - это комбинация технологий:
- Вертикальный шардинг (вынесение модулей на отдельные серверы MySQL)
- Репликация MySQL и балансирование нагрузки между серверами
- Распределенный кеш данных (memcached)
- Непрерывность сессий между веб-серверами (хранение сессий в базе данных)
- Кластеризация веб-сервера :
- Синхронизация файлов
- Балансирование нагрузки между серверами
Как работает
1. Вертикальный шардинг
Разделение одной базы данных веб-приложения на две и более базы данных за счет выделения отдельных модулей, без изменения логики работы веб-приложения.
В отдельные базы можно вынести следующие модули продукта:
2. Репликация MySQL и балансирование нагрузки между серверами
Схема «master - slave» реализуется средствами MySQL.Платформа «1С-Битрикс: Управление сайтом» позволяет гибко балансировать нагрузку между серверами, участвующими в репликации.
- гибкая балансировка нагрузки SQL
- простота администрирования
- дешевое и быстрое неограниченное масштабирование
- он-лайн бэкап
- не требуется доработка логики веб-приложения
3. Распределенный кеш данных (memcached)
«1С-Битрикс: Веб-кластер» позволяет использовать пул серверов memcached для работы с кешем данных. 
Это обеспечивает:
- высокую эффективность - за счет централизованного использования кеша веб-приложением
- надежность - за счет устойчивости подсистемы кешировния к выходу из строя отдельных компонентов
- неограниченную масштабируемость - за счет добавления новых memcached-серверов
4. Непрерывность сессий между веб-серверами (хранение сессий в базе данных)
Возможность хранения данных пользовательских сессий в базе данных обеспечивает «прозрачность» сессии для всех веб-серверов кластера:- После авторизации на одном из серверов пользователь должен считаться авторизованных и для всех других серверов.
- И наоборот - окончание сессии на любом сервере должно означать ее окончание на всех серверах сразу.
Приветствую, уважаемые сообщники!
Эта статья - о том, как мы реализовали веб-кластер для новостного портала (с пиком посещений в 130 тысяч уникальных посетителей в день - это 7Тб траффика за 3 дня - выборы и 2 последующих. Сейчас в среднем кластер раздаёт 35-40 Тб траффика в месяц), о том, как по-разному понимают одинаковые задачи программисты и журналисты, о том, как можно достичь одной и той же цели, идя разными путями.
Она будет интересна тем, кто хочет построить легко масштабируемый географически распределённый веб-кластер, не вкладывая астрономических сумм в оборудование (а по меркам телевидения - будут вообще смешные суммы).
Я больше чем уверен, что маркетологи, толкающие убер-решения свежевыпущенных продуктов, имеющих в своём названии слова «масштабируемый веб-кластер» или «horizontal infinite scalable web cluster», меня возненавидят.
Я больше чем уверен, что конкуренты наших клиентов будут удивлены простотой решения, которое мы использовали.
Я не буду приводить банальных конфигов, которые можно найти в любом тоториале по настройке PHP, Nginx и Firebird (у последнего, строго говоря, и настраивать-то нечего - всё работает с пол-пинка «из коробки») и вообще буду рассказывать о сути решения, а не о том, какая из версий PHP лучше.
Опытным проектировщикам вряд ли будет интересно - они и так всё знают, а вот тем, кто только начинает путь на нелёгком поприще проектирования систем сложнее, чем «Hello, World!» наверняка будет что подчерпнуть - решение в боевом режиме уже скоро как 2 года, при этом никаких архитектурных проблем не возникало (хотя выход из строя сразу двух жёстких дисков на двух из трёх узлов был, но никто ничего не заметил - сайты чуть-чуть медленнее открывались, чем обычно).
Итак, пара слов, с чего всё начиналось. Жил-был сайтик группы независимых журналистов, которые очень мечтали стать настоящим телевидением (забегая вперёд, скажу, что у них это получилось - они создали своё, вполне успешное телевидение с «блэкджеком и шл...» - далее по тексту). Страна у нас маленькая, ничего страшного не происходит (и мы этому рады), но раз в 4 года у нас традиционно проходят выборы в Парламент. Который уже традиционно никак не избирает Президента. (Не бойтесь, политики тут не будет, это просто для общего понимания момента).
Разумеется, в период перед выборами и немного после все интернет СМИ очень сильно колбасит. Некоторые сайты не просто лежат, они валяются, некоторые переодически пытаются выдать хотя бы строчку текста, но проблема всеобщая и известная - сайты не справляются с наплывом посетителей. Я про обычные, текстовые сайты. А у наших клиентов сайт был необычный. Дело в том, что у них было и видео - новостные сюжеты, они производили 10 гигабайт в месяц - в то время, сейчас они создают такое количество видео в день. Ко всему прочему (это последнее упоминание политики, честное слово) эти журналисты не отличались особой лояльностью к власти. Говорили и писали что хотели. Совсем обнаглели, да? Мы всегда себя позиционируем как наёмников - клиент предлагает задачу, мы предлагаем её решение. Всё остальное нас не интересует, мы соблюдаем нейтралитет.
Перед нами была поставлена задача - предложить решение для новостных сайтов, которое позволит не просто выстоять при наплыве 50-100 тыс посетителей, но ещё было бы и географически разбросано по миру и управлялось из мобильного бункера любой точки Вселенной планеты. Разумеется, географический разброс узлов кластера оставался за нами. В результате мы предложили следующую схему (художник из меня никакой, вы уж меня извините):
(Это упрощённая схема на ноябрь, в дальнейшем почти все сервера перенесли к Hetzner-у, так как у Netdirekt-a в то время постоянно колбасило канал. Сейчас у них с сетью ситуация обстоит намного лучше).
Обычные посетители видят один из 3-х серверов, при этом, мы сделали так, что «лёгкий» контент в виде текста и картинок все посетители из Молдовы тянули с одного их 3-х, а «тяжёлый» контент (видео) - тянули с сервера, расположенного у местного провайдера. Внешние посетители просто не видели молдавское зеркало и весь контент тянули с одного из немецких серверов.
Вот, что у нас получилось с посетителями в результате (каждая часть портала имеет свой счётчик):
Эта схема позволяет сменить управляющий сервер в любой момент, сама проверяет доступность узлов кластера, легко масштабируется - в качестве резервного рассматривался и Amazon EC – более того, Amazon EC даже использовался некоторое время для видеостриминга (около 4-х месяцев), но из-за дороговизны траффика решено было всё-таки стриминг-ноды перенести к немецкому Hetzner-у.
Непосредственно за 2 недели до часа «Х» мы взяли резервные сервера и держали их наготове (но пользователи их не видели, так как держать активным сервер несколько дешевле, чем использовать его в боевом режиме - только из-за траффика).
Как это всё работает? Очень просто - молча и круглосуточно;).
На управляющем сервере (как я уже упоминал, у портала 2 больших «раздела»: новости в виде текста с картинками и новости в виде текстового дайджеста и видео- де-факто используется 2 сервера, но для простоты я изобразил один) есть то, что обычно именуется системой управления контентом.
Основная задача этого сервера - позволять журналистам добавлять новости. Раз в определённое время (3-5 минут) стартует скрипт, который создаёт… offline-копию сайта. Разумеется, генерируются только страницы, которые были изменены или которые нуждаются в перестройке из-за кроссылок и зависимостей.
Это очень просто реализуется при помощи генераторов (sequense) и каскадных триггеров в Firebird - процедуре требуется внести изменения только в основную страницу сайта, а каскадные триггеры обновят все зависимости, пометив каждую страницу, которая нуждается в обновлении. Пометка выставляется не в виде флага 1/0, а в виде уникального номера, получаемого на основе генератора. Скрипт создания оффлайновой версии при старте узнаёт новое значение генератора, считывает значение этого генератора от своего предыдущего запуска и пересоздаёт все страницы в полученном диапазоне. При этом, так как мы используем транзакционный механизм Firebird – скрипту глубоко наплевать, какие изменения происходят во время его выполнения - т.е. у нас всегда создаётся целостная и непротиворечивая версия сайта, что бы при этом не делали репортёры.
Таким образом, у нас создаётся мастер-копия портала (ну или двух порталов, если угодно - текстового и видео). Скрипт (как и сама админка) написан на PHP и для работы с Firebird использует ADODB – так что его довольно-таки просто можно перестраивать по желанию заказчика*.
(* Но мы собираемся избавиться от ADODB в скором времени во всех наших будущих проектах - его универсальность только вредит, так как нормального механизма работы с БД, позволяющего использовать все особенности Firebird SQL сервера (впрочем, как и остальных) там не реализовано - к примеру, невозможно перехватывать исключения при выборке из селективных процедур, нет гибкого управления транзакциями и вообще, у этих классов слишком много ИИ - я предпочитаю самостоятельно решать, когда я хочу откатить тразакцию, а когда - подтвердить.)
Единственное, что пришлось менять в настройках Firebird – это значение размера кэша страниц БД - так как количество подключений к БД очень небольшое (редко когда более 50-60 одновременных подключений), то и количество страниц экспериментальным путём было увеличено до 2048 (мы используем Classic вариант, для архитектуры Super это значение спокойно можно увеличить в 10 раз, так как там общий кэш страниц. В грядущей версии Firebird 3.0 разработчики обещают одну SMP-friendly архитектуру с общим кэшем, так что для неё вполне можно будет использовать большие значения для настроек страничного кэша).
Затем, при помощи обычного rsync-а разница изменений раскидывается по зеркалам, которые из себя представляют обычные узлы для раздачи статики на основе Nginx. Я думаю, не требуется рассказывать, на что способен 4-хядерный сервер с 12 Гигабайтами оперативки при раздаче одной только статики? ;-)
При этом, 10% канала каждой ноды (это как раз 10 или 100 мегабит, в зависимости от конкретного подключения) зарезервировано для синхронизации. Синхронизация происходит в 2 этапа - сначала синхронизируется «тяжёлый» контент - картинки и видео, потом - текст (html/xml/js).
Иногда (при загруженных каналах от управляющего сервера к зеркалам) посетитель может увидеть маленькие несоответствия в виде негрузящихся картинок и/или видеороликов - так как используется round-robin DNS, то текст страницы пользователь может получить с одного зеркала, а ссылку на видео - с другого. Это не мешает порталу работать - текст есть всегда, а картинка или видео рано или поздно объявятся.
Так как на сайтах есть динамические формочки - например, подписка на рассылку новостей - то эти формочки обрабатываются отдельно выделенным сервером (он не изображён на схеме, но сути это не меняет). Даже если предположить, что все посетители одновременно ломанутся подписываться на новости и этот сервер «ляжет» - ничего страшного не случится - формы подгружаются в iframe и на доступности новостей отсутствие этих формочек никак не отражается.
Добавление нового узла происходит просто - сначала синхронизируется новое зеркало с основной копией (это происходит параллельно с обычным режимом работы синхронизатора), затем запись добавляется в DNS и… никто ничего не замечает.
Удаление ноды происходит проще - просто убирается запись из DNS. Добавление и удаление вполне поддаются автоматизации (именно так мы поступили с частью, которая отвечала за веб-стриминг около 1000 мегабитных потоков на Amazom EC), но если вы вдруг решитесь повторять подобное - советую сначала посчитать, сколько занимает первичная синхронизация данных (у нас это 2 Гигабайта для «лёгкой версии портала» и примерно 1 Терабайт для видео, хранится только несколько последних месяцев).
Именно поэтому динамическое добавление/удаление нод из пула запасных мы убрали через некоторое время работы проекта - слишком много занимает контент и слишком уж параноидальным получился скрипт - убирал ноды при каждой проблеме связи с ними.
Отдельно стоит упомянуть про подсчёты отображений новости. У меня сложилось впечатление, что любимое занятие у журналистов (помимо написаний/съёмок репортажей) - это мерянье количеством посетителей той или иной новости. Примерно литр крови и километр нервов нам пришлось потратить, чтобы убедить журналистскую братию в том, что не требуется выводить изменения счётчиков в реальном времени.
Программисты прекрасно понимают, что узнать, сколько человек в настоящий момент читают статью просто невозможно, можно только посчитать количество запросов статьи с сервера, для журналистов же это одинаковые понятия. :)
Для подсчёта просмотров мы связались с Кирилом Коринским (также известным, как catap), который любезно согласился добавить фичу подсчёта просмотров URL в свою ветку Nginx-а. Ну а дальше уже всё просто - все узлы переодически опрашиваются и счётчики страниц учитываются в свойствах самой страницы. Так как счётчики (т.е. сами значения) хранятся в отдельных файлах (сейчас это по одному файлу на новость, в скором времени мы планируем сделать группу счётчиков в одном файле, чтобы уменьшить количество самих файлов) - то при синхронизации передаётся не страницы сайта целиком, а только файл-счётчик. При большом количестве файлов это создаёт дополнительную нагрузку на дисковую подсистему - поэтому, при использовании такого же подхода сразу продумывайте о том, как разбить счётчики по группам - мы остановились на разбиении счётчиков по типам новостей и дате - файлы относительно маленькие и со временем они перестают меняться, так как старые новости никого практически не интересуют.
Вот вкратце, плюсы использованного нами решения:
- Использование статических сайтов в качестве узлов веб-кластера позволяет свести администрирование всего кластера к нескольким рутинным задачам - обновлению операционной системы узлов и оплате траффика. Этот же пункт позволяет раскидать географически узлы кластера, что вкупе с GEO-DNS может рассматриваться вообще как некоторый аналог сети доставки контента (CDN) - по сути это оно и есть.
- Использование транзакционного механизма БД и перенос логики в саму БД позволяет всегда иметь целостную и логически непротиворечивую версию сайта - впрочем, я бы очень удивился, если бы «срез» данных с сервера был бы логически нецелостным.
- Если ожидается наплыв посетителей - то простым увеличением узлов кластера можно легко с ним справиться. В нашем случае, полный ввод нового узла в строй занимал чуть более часа для текстовой части портала и около суток (нельзя впихнуть невпихуемое) для видео. Если смириться с частичной синхронизацией сайтов и остальное «доливать» в фоне - то ввод нового узла для видео также можно сократить до часа.
- Административный сервер можно сделать из любого из узлов (при необходимости) - достаточно просто развернуть бэкап базы (в сжатом виде около сотни мегабайт). Весь остальной контент уже есть.
Ну и парочка минусов, чтобы не всё казалось таким безоблачным:
- Решение не подходит для случаев, когда есть части сайта, которые по-разному должны видеть разные пользователи, т.е. когда по условию задачи страницы генерируются персонально для каждого пользователя. В нашем случае этого оказалось и ненужно.
- Счётчики посещений обновляются с отставанием примерно в полчаса-час. Терпимо, но вам придётся в этом долго убеждать клиента.
- Больше всего проблем доставляет синхронизация с местным зеркалом - наши провайдеры ещё не продают траффик по цене в 7 евро за Терабайт и если и предоставляют 100 честных Мегабит в мир - то по очень неадекватным ценам.
- Проектируйте менее параноидальную систему слежения за узлами кластера - наша оказалась слишком чувствительной, пришлось переводить добавление и удаление узлов в ручной режим.
И буквально маленькая щепотка опыта, которая позволит разнообразить пресную кашу будней.
Для хранения оффлайн-копии сайта мы используем файловую систему JFS. Она себя очень хорошо зарекомендовала и при работе с множеством мелких файлов и при работе с большими файлами (по моему опыту ещё только XFS может практически моментально удалить файл размером в 200-300Гб).
Так вот - по умолчанию файловая система монтировалась с параметрами по умолчанию. Но так как у нас со временем стало очень много файлов, дисковые операции стали немного подтормаживать. Так как время последнего доступа к файлу нам не требуется, я добавил опцию «noatime» к параметрам монтирования ФС. Вот что получилось - момент добавления, думаю, вы определите сами:
Кратко повторюсь - для стабильной работы в обычном режиме используется:
- 3 сервера для раздачи контента
- 2 сервера для «админки»
- 2 сервера для DNS и системы слежения за остальными серверами.
В случае ожидаемых событий, привлекающих большое количество посетителей - подключаются дополнительные сервера для раздачи контента.
В месяц потребляется около 40Тб траффика, общий объём контента - чуть более 1 Терабайта, видеоконтент хранится около 3-х месяцев.
Я с удовольствием отвечу на вопросы хабрасообщества.
