Проектирование, разработка, внедрение, высокие нагрузки, качество (Александр Сербул)

В прошлый раз мы говорили об эффективном кэшировании на базе memcached, которое появилось в 10 версии платформы "1C-Битрикс: Управление сайтом" (редакции "Веб-кластер", "Бизнес веб-кластер" ).
Сегодня хочу рассказать о появившейся возможности практически неограниченно увеличить "мощность" базы данных интернет-проекта - путем ее кластеризации.

Все лучшее ... Базе!

Обычно для высоконагруженного сайта, особенно со сложной бизнес-логикой, покупают/арендуют отдельный сервер. Мы же не хотим заставить Клиента ждать 10 минут, пока пройдет его платежная транзакция или выгрузится отчет?

Сервер базы данных, так сказать "сердце" сайта, выбирают и покупают, можно сказать, "с трепетом" - еще бы, тут будут хранится оформленные и оплаченные заказы, лицевые счета, персональные данные Клиентов и прочая критичная для бизнеса информация.

Да, мы выбираем конфигурацию для сервера базы данных с резервным блоком питания, подключенным к отдельной шине питания в датацентре, с задублированными вентиляторами.

Иногда, зная что пролет элементарной частицы через микросхему оперативной памяти может инвертировать бит информации, мы устанавливаем более дорогую память типа ECC (я не шучу, такие технологии нередко востребованы, например в системах управления полетами, медицине и др.).  

Для быстрой работы дисковой подсистемы, если позволяет бюджет, мы конечно используем эффективный и надежный RAID-10. Ну или хотя бы, как минимум, RAID-1 - для надежного зеркалирования информации.

Для быстрой работы базы данных нам все чаще требуется распространенная сейчас технология отложенной записи на диск (write back disk cache). Разумеется, зная, что при экстренном выключении питания рейд-контроллер или жесткий диск может потерять закэшированную им информацию (несколько заказов, финансовых транзакций) - мы обязательно покупаем рейд-контроллер с батарейкой.

Ну и конечно мы устанавливаем на наш сервер побольше оперативной памяти. Идеальная ситуация, это когда база данных полностью помещается в оперативную память. Например у магазина база занимает 10 Гигабайт - вот если установить на сервер 15 Гигабайт - приложение будет нам благодарно (иначе будет происходить периодическая загрузка данных базы с диска, что конечно медленнее).

Если мы работаем на MySQL - то, как известно, самый производительный (данные размещаются в оперативной памяти) и устойчивый к конкурентной нагрузке формат базы данных -  Innodb.

И еще раз внимательно просмотрев курс по оптимизации мы наконец запускаем быстрый, надежный и крутой сервер базы данных!

Да, да. Мы еще настроили резервное копирование информации из базы данных. Оно делается раз в сутки и архив переносится на отдельный сервер бэкапов ( расположенный в отдельном охраняемом помещении ).

Можем ли мы быть теперь уверенными в быстрой и надежной работе базы данных интернет-проекта?

К сожалению, нет. Мы упустили два ключевых риска...


Проблема 1 - Дорогое масштабирование вверх

В наш век информации, когда объемы данных экспоненциально увеличиваются каждый год, мы достаточно быстро (кто через полгода, кто через 1-2 года) упремся в производительность сервера базы данных.
Почему? Ведь мы все тщательно будем кэшировать, мы собрали крутой сервер базы данных, быстрый и с большим объемом оперативной памяти...

Дело в том, что интересной и ценной для принятия бизнес-решений информации - много и ее будет все больше и больше. Вы захотите, к примеру, сохранять пути клиентов по сайту и их хиты на ... полгода для детального анализа отделом маркетинга.

Или вам потребуется открыть и подключить к интернет-сайту десяток-другой филиалов с каталогами и ценами и отдельными остатками. И очень захочется (именно захочется) синхронизировать информацию в каталогах с 1С каждые, к примеру, 5 минут.

И наш крутой и мощный сервер базы данных через определенное время начнет уже неуспевать и спотыкаться за полетом фантазии и креативных идей руководителя интернет-проекта.

Вы достаточно быстро выпустите "последнюю пулю" - купите самый самый быстрый процессор и самую большую планку памяти (причем топовые, самые быстрые комплектующие стоят значительно дороже - зависимость нелинейная), которые еще можно установить в сервер базы данных и ... и всё.

Я нередко вижу проекты, которым для базы данных уже не хватает 8 ядер и 32G оперативной памяти.

Придется снова покупать и настраивать мощный сервер. Или может купить для сервера базы данных мейнфрейм


Решение проблемы 1 - "Master-Slave репликация"

Master-Slave репликация, доступная в модуле "Веб-кластер" платформы "1C-Битрикс: Управление сайтом", позволяет эффективно решить описанную выше проблему вертикального масштабирования сервера базы данных.

Технология репликации базы данных существует довольно давно и она успешно используется для решения задач повышения производительности. Однако мы понимаем, что в данном случае приложение работает не с одной, а несколькими базами данных:
- в одну базу данных приложение пишет (есть еще более сложные варианты, но опускаем их)
- из остальных читает

Сложность в том, что если сразу при разработке приложения не учитывать что оно в будущем должно работать с несколькими базами данных, переделать его когда это потребуется может оказаться сложной и трудоемкой, а иногда и практически невыполнимой задачей ( ради эксперимента, спросите у разработчиков проекта - сможет приложение работать с двумя базами данных? и вы будете удивлены ответом ).

Благодаря тому, что возможность работы с несколькими базами данных была изначально заложена в архитектуру платформы 1С-Битрикс и реализована в кластерных редакциях, вашему проекту открываются новые вершины производительности.

И, на что хочется обратить особое внимание, В КОД РАБОТАЮЩЕГО ПРОЕКТА ПРИ КЛАСТЕРИЗАЦИИ БАЗЫ ДАННЫХ НЕ НУЖНО ВНОСИТЬ ИЗМЕНЕНИЯ! Технологию распределения запросов на серверы базы данных мы взяли на себя, предоставим вам возможность эффективно "дирижировать" нагрузкой через определение весов для каждого дополнительного сервера.

Вам достаточно лишь настроить и подключить к платформе один или несколько стандартных недорогих серверов базы данных, с помощью удобного мастера в течении нескольких минут перенести туда данные и ... наслаждаться увеличенной в N-раз производительностью базы данных!

Если нагрузка через полгода-год на базу данных снова возрастет (вы подключите к проекту еще 5-10 филиалов и откроете 2 языковых зеркала) или планируется увеличение нагрузки в ближайшие выходные в связи с рекламной акцией - вы снова просто можете добавить к платформе стандартный сервер базы данных (операция подключения и миграции данных занимает несколько минут).
Отключается сервер базы данных также легко и интуитивно через админку.




Подключение дополнительного сервера базы данных к сайту занимает несколько минут.




Наслаждаемся эффективной и производительной работой кластеризованной базы данных. Добавляем серверы к кластеру при необходимости - за несколько минут.




Проблема 2 - "Непрерывное" резервное копирование

Итак. Нагрузку на базу данных мы победили и в случае чего - добавим в кластер сервер в течение минут. А как обстоят дела с резервным копированием данных?

Оно выполняется раз в сутки. Иногда этого недостаточно.

Допустим, наш прекрасный мощный сервер базы данных ломается - сгорает процессор или материнская плата или ее элемент. Текущие заказы и транзакции где - на дисках этого сгоревшего сервера. Нужно ехать, вынимать их оттуда, подключать к другому и т.п. - в это время вам будут беспрерывно звонить клиенты.

Есть достаточно сложные решения, как "пережить" выход из строя сервера базы данных, типа DRBD репликации, кластерных файловых систем OCFS2, GFS2... но мы рассмотрим наиболее простое, распространенное и надежное решение - да, да, снова репликацию.


Решение проблемы 2 - "Master-Slave репликация"

Master-Slave репликация, доступная в модуле "Веб-кластер" платформы "1C-Битрикс: Управление сайтом", позволяет эффективно решить задачу "непрерывного" резервного копирования и высокой доступности базы данных.

При репликации, данные с главного сервера базы данных в онлайне передаются на дополнительные (SLAVE) сервера - т.е. вы имеете копию данных = онлайн бэкап в нескольких экземплярах.

Более того, чтобы не замедлять основной и дополнительные сервера при создании логического бэкапа (который также необходимо делать периодически - иначе после случайного удаления, например, таблицы заказов, у вас не будет шансов ее вернуть, т.к. изменения реплицируются на все сервера базы данных) - мы можете выделить для этого отдельный сервер базы данных, на котором и выполнять процедуру создания логического бэкапа:




А для решения задачи быстрого переключения интернет-сайта на работающую базу данных (простой проекта составит пару минут или даже меньше) - вы скриптом или вручную переключаете систему на использование дополнительного сервера базы данных, на котором, благодаря репликации, имеется самая свежая копия бизнес-данных.



Выводы

Мы рассмотрели основные задачи, которые необходимо решить для организации высокопроизводительной и отказоустойчивой конфигурации базы данных, и увидели, как они просто решаются модулем "Веб-кластер"  в 10 версии платформы "1C-Битрикс: Управление сайтом" (редакции "Веб-кластер", "Бизнес веб-кластер" ).

В следующей статье поговорим о создании высокопроизводительного кластера серверов приложений - такая задача нередко возникает при создании высоконагруженных интернет-проектов на платформе 1С-Битрикс.

Коллеги, добрый день!

Я думаю, публикуемая информация будет интересна прежде всего внедренцам и 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 и т.п.
  

Процедура развертывания веб-кластера подробно описана в руководстве. Для ознакомления с возможностями веб-кластера рекомендую посмотреть презентацию.

В следующих постах постараюсь более детально рассмотреть особенности вышеуказанных технологий кластеризации, на конкретных примерах рассмотреть кейсы их использования.