Я думаю, публикуемая информация будет интересна прежде всего внедренцам и IT-менеджерам среднего и высшего звена, ориентированным на достижение адекватного результата максимально коротким путем. Многие вещи, убежден, будут интересны системным аналитикам, архитекторам, тимлидам и системным администраторам. Оторванного от реальности технического философствования, холиваров, интеллектуальных рассусоливаний на тему "ООП или на функциях" - не будет, предупреждаю сразу
Итак. Много чего интересного происходит в нашей компании каждый день. Разбираемся и внедряем в продуктах самые новые, самые эффективные технологии. А особенно приятно видеть, как воплощенные в продукты технологии приносят пользу Клиентам, РЕШАЯ возникающие задачи. Абсолютно честно - видеть работающее решение приносит инженеру огромное удовольствие!
Поэтому просто не могу не писать! Горю желанием поделиться с Вами, коллеги, тем, что произвело на меня большое впечатление.
Сегодня хочу рассказать о появившейся поддержке кластеризации в платформе "1С-Битрикс: Управление сайтом 10.0" и вышедшем вчера, в День Космонавтики, "1С-Битрикс: Корпоративный портал 10.0".
"Кластер" (англ. "cluster" ) - это, простыми словами, группа компьютеров, сформированная:
- Для увеличения производительности. Как в хоре - чем больше голосов, тем громче звучит мелодия. Такая группа называется HP-кластер (high performance).
- Для увеличения надежности. Один компьютер сгорает, остальные - работают. Т.к. снаружи мы работаем с группой, как одним целым, мы поломку компьютера не замечаем, или замечаем некое ухудшение производительности. Такая группа называется HA-кластер (high availability).
Интернет-проекту нужна производительность (HP-кластер)
HP-кластер очень пригодится для интернет-проектов, которые работают на прееееееделе возможностей.
Допустим, вами было сделано все, что только можно и нельзя, для увеличения производительности интернет-проекта:
- С виртуального хостинга переехали на выделенных сервер.
- Долго тюнили производительность этого сервера.
- Дисковая подсистема сервера сделала максимально быстрой. С SATA-дисков переехали на SAS-диски. С рейда1 переехали на рейд10 на нескольких дисках. Аппаратный контроллер рейда выбран разумно - он имеет неплохой кэш и батарейку для поддержки кэша с отложенной записью (что значительно ускоряет запись на диск).
- Процессоров на серверах аж по 8. Оперативной памяти тоже много, допустим по 16GB.
- Сделали отдельный сервер для отдачи статических файлов с производительной дисковой подсистемой.
- Базу данных вынесли на отдельный сервер.
- Настроили master-slave репликацию и написали код, разделяющий запросы за запись и чтение. Возможно, настроили MySQL Proxy. Но, т.к. платформа не поддерживала до 10 версии использование более одной базы данных, приходилось для этого модифицировать ядро и выполнять глубокую кастомизацию.
Но посещаемость интернет-проекта растет так быстро и интенсивность работы Посетителей с данными настолько интенсивна, что ... нужно что-то срочно делать дальше! Нужно повышать производительность!
Интернет-проекту нужна высокая доступность (HA-кластер)
Наверно все, имеющие на хостинге хоть один важный интернет-проект, при пятиминутной недоступности которого звонят телефоны и начинаются финансовые потери с далеким репутационным резонансом, сразу влюбятся в HA-кластер и захотят его использовать как можно скорее. Действительно, но кому не нужна высокая доступность?
К сожалению, страдающих паранойей прошу не читать три следующих раздела.
Розовые очки 1 - "Недорогой сервер своими руками"
Бывает так, что для интернет-проекта купили недорогой новый сервер, сделали на нем рейд1 (или 10), развернули систему, отвезли в дата-центр и запустились.
К сожалению, не подумали о том, что в сервере может "сломаться" не только жесткий диск, а ... блок питания или вентилятор (интересно, для чего в дорогих серверах их резервируют?
). И это событие внезапно произошло. На поиск аналогичного блока питания и замену потрачен - день и проект был недоступен все это время. Репутация интернет-проекта - "подмочена".Розовые очки 2 - "Дорогой надежный сервер"
Для интернет-проекта купили дорогой, "фирменный" сервер, в котором все, что можно, зарезервировано. Проект запустили. Все спокойно, несколько месяцев. Вдруг сгорает рейд-контроллер. Пока искали аналогичный с похожей прошивкой, интернет-проект был недоступен два дня.
Розовые очки 3 - "Экскаватор"
К сожалению, рядом с дата-центром проводили строительные работы и ... повредили силовые кабели (нередко происходят аварии на силовых подстанциях). Интернет-проект был недоступен полдня.
К сожалению, начинаешь задумываться о вышеуказанных проблемах только тогда, когда "беда" случилась.
Давайте попробуем задуматься заранее
Возможные решения
Очевидно, что данные задачи нужно как-то решать и ... их пытаются решить, каждый как может. К сожалению, многое зависит от компетенции привлекаемых к работе системных администраторов. И не всегда удается протестировать решение - действительно ли оно сработает в случае аварии.
В отношении облачных хостингов часть этих задач решают хостеры, но есть особенности, которые мы разберем в ближайших постах.
Из множества возможных решений постараемся отобрать самые простые и эффективные.
Проактивный мониторинг!
Но прежде всего, и об этом нужно было написать в начале поста, необходимо обеспечить мониторинг работы интернет-проекта. Как мы узнаем, что интернет-проект "завис"? Когда начнут звонить/писать Пользователи сайта?
Обязательно, прежде всяких экспериментов с кластеризацией/надежностью/производительностью, настроим мониторинг интернет-проекта. Самое простое, с чего можно начать, это установить monit или, посложнее, nagios (zabbix и др.) и проверять каждые 5 минут, что главная страница интернет-проекта загружается без ошибок. Для проекта на платформе 1С-Битрикс также мониторингом проверяем, чтобы на главной странице интернет-проекта не выводилось сообщение "DB query error", говорящее о возможных проблемах с сервером базы данных (проверяем с помощью поиска подстроки или регулярного выражения). Более правильно - мониторить отдельные сервисы.
Настоятельно рекомендую запустить машину низкой/средней производительности для мониторинга на надежном оборудовании и отдельно (
) от основных серверов. Оповещения обычно настраивают на e-mail и/или SMS. Цель - как только случился инцидент, узнать об этом раньше Пользователей и оперативно отреагировать. Рецепт 1 - "Горячий" резерв
Достаточно распространенным и относительно простым решением для повышения доступности интернет-проекта является покупка и установка рядом с работающим сервером идентичного (или похожего по производительности) физического сервера, на который реплицируются как файлы, так и база данных.
В случае аварийного отключения основного сервера, система мониторинга оповещает ответственных сотрудников об инциденте и они вручную переключают обработку запросов на резервный сервер. Процедура переключения может занять несколько десятков минут.
Конечно можно автоматизировать процедуру переключения и для этого имеется богатый инструментарий типа Linux-HA (об этом в будущих постах). Однако любую "автоматизацию переключения" нужно тщательно тестировать, поддерживать и иногда ручное вмешательство более просто, предсказуемо и эффективно.
Рецепт 2 - Активный "горячий" резерв
Очень хочется как-то задействовать вычислительные возможности "горячего" резерва. В самом деле - стоит рядом машина, которая "возможно будет работать когда-то". В принципе, можно организовать выполнение на нем php-скриптов интернет-проекта. Однако, для этого нужно добавить в конфигурацию третий элемент - координатор/балансировщик, который получает запросы Пользователей и направляет их на работающий сервер/распределяет запросы. Добавляя новый узел и усложняя этим систему, не забываем подключить его к системе мониторинга.
Готовое решение под ключ - поддержка технологий кластеризации в "1С-Битрикс: Управление сайтом" (редакции "Веб-кластер", "Бизнес веб-кластер" ) и "1С-Битрикс: Корпоративный портал" (редакция "Холдинг" )
Как видим, веб-кластер очень актуален и востребован для решения широкого спектра задач обеспечения надежности и производительности. Особенно сейчас, когда нагрузки на интернет-проекты растут экспоненциально, а требования к доступности и надежности ужесточаются с каждым днем.
Для того, чтобы предложить нашим Клиентам эффективное и надежное решение вышеперечисленных задач, не требующее, с другой стороны, серьезных затрат на дальнейшую поддержку, мы тщательно проанализировали современные технологии кластеризации, выбрали и включили в "веб-кластерные" редакции продукта следующие технологии и инструменты:
- Поддержка распределения файлов интернет-проекта на несколько серверов для повышения производительности и отказоустойчивости веб-кластера. Для этого рекомендуем использовать простой и надежный инструмент асинхронной кластерной синхронизации - csync2.
- Полная поддержка master-slave (MySQL) репликации на уровне ядра платформы, включая встроенный и настраиваемый SQL-балансировщик. Что особенно важно - не потребуется модифицировать код ранее созданных проектов! Просто добавляем новый сервер БД и производительность работы интернет-проекта с базой данных значительно возрастает.
- Добавлять серверов БД в интернет-проект можно теперь столько, сколько нужно, практически без ограничений (узким местом когда-нибудь станет master-сервер, используемый для записи, но для этого нужно очень постараться).
- Благодаря технологии "вертикального шардинга" стало возможным вынести отдельные части базы данных (модули) в отдельные базы данных. Если честно, это очень круто - и это стало возможным именно благодаря сбалансированной и модульной архитектуре платформы. Теперь можете выносить активно используемые модули "Поиск" и "Веб-аналитика" в отдельные базы данных.
- Для эффективного централизованного хранения кэшей интернет-проекта реализована поддержка отказоустойчивого и высокопроизводительного кластера memcached-серверов. В ближайших постах я подробно остановлюсь на теме кластерного кэширования.
- Особо хочу отметить встроенный инструмент нагрузочного тестирования веб-кластера, расположенный в модуле "Монитор производительности". Изюминка в том, что инструмент позволяет измерить и вывести на максимальный уровень фактическую производительность веб-кластера, а не отдельного сервера. До этого, необходимо было использовать для решения подобной задачи инструменты типа jmeter, apachetop и т.п.
Процедура развертывания веб-кластера подробно описана в . Для ознакомления с возможностями веб-кластера рекомендую посмотреть .
В следующих постах постараюсь более детально рассмотреть особенности вышеуказанных технологий кластеризации, на конкретных примерах рассмотреть кейсы их использования.
И вообще где взять спеца по Битриксу для полноценной работы с проектом, требующим развития, и полного внимания и рабочего времени (не аутсорсинг)?
Партнерская система образовала перекос именно в аутсорсинг.
А где конкретно брать тех, кто предугадывает интересы клиентов, отличается высшей степенью организованности, вносит инновационные предложения и т. д. - вот эти розовые очки можно прокомментировать?
Для реализации проекта можно выбрать одного из наших . Как самостоятельно искать разработчиков, обучать на наших бесплатных курсах и постараться сделать так, чтобы они не уходили через 2-3 года - напишите мне (serbul@1c-bitrix.ru), поделюсь опытом.