Для чего используют кластеризацию серверов СУБД? Вопрос не совсем праздный, особенно для крупных компаний. Если с кластеризацией/масштабированием серверов приложений, терминалов, web‑серверов и т. д. все понятно и прозрачно, то вот с СУБД не всё так просто. Особенно для 1С систем.

Предлагаю немного поподробнее покопаться с кластерами СУБД. Разобрать предпосылки к их развертыванию, плюшки, которые они дают. Ну, и не забудем про подводные камни.

Поскольку на проблему смотреть будем, как всегда, через призму 1С, то в качестве СУБД берем MS SQL и PostgreSQL.

В крупных компаниях кластеризация серверов СУБД — это must have. Выделил наиболее главные причины для разворачивания кластеров СУБД (они, впрочем, подходят и для любых других серверов):

1. Отказоустойчивость или обеспечение высокой доступности (High Availability).

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

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

2. Катастрофоустойчивость.

   Это, скорее, частный случай High Availability. Имеется в виду защита данных при авариях (пожар/наводнение, сбой ЦОД, кибератаки) за счёт геораспределённых кластеров.

   Цель здесь такая же — обеспечить сохранность данных и возможность их восстановления после катастрофических сбоев с минимальными простоями.

3. Масштабируемость.

   Возможность распределять нагрузку между узлами или горизонтальное масштабирование. Т. е. использовать дополнительные ноды не только для отказоустойчивости, но и для перенаправления запросов к ним — балансировки. Когда один сервер СУБД не справляется, кластеризация позволяет распределять запросы, особенно на чтение, между несколькими репликами. Такой подход не только увеличивает производительность, но и помогает избежать узких мест в системе, особенно в периоды пиковых нагрузок.

   Вообще, горизонтальное масштабирование на серверах СУБД — это не частая история. Если для тех же серверов приложений — это обычная практика, то перераспределить поток запросов на реплики не всегда получается.

   Обычно дополнительные ноды используются для ручного перенаправления запросов, выполняющихся на чтение вне транзакции. Решения multi‑master кластеров в каком‑то виде существуют, но все же имеют значительные просадки в скорости для OLTP‑систем и требуют тщательного управления конфликтами.

Кластеризация

Какими технологиями или инструментами чаще всего пользуются?

В сегменте MS SQL Server отказоустойчивость — это преимущественно AlwaysOn Availability Groups в связке с Windows Server Failover Clustering (WSFC). На каждом сервере — свой экземпляр боевой базы. Через настройку Listiner настраивается единое окно подключения к базе данных, чтобы при переключении серверов не нужно было менять настройки подключения. Есть еще Failover Cluster Instance (FCI), но в своей практике почти не встречаем.

Из плюсов:

• Высокая доступность на уровне базы данных/серверов.

• Поддержка автоматического и ручного переключения при сбое основной ноды.

• Вторичные ноды доступны для чтения.

• Возможно сделать геораспределенный кластер серверов.

Из минусов:

• Отсутствие балансировки. Если планируете вторичные ноды использовать для чтения, то SQL должен быть обязательно редакции Enterprise Edition. При этом перенаправление самих запросов — это либо функция самого бизнес-приложения, либо должно быть какое-то middleware-решение, которое возьмет на себя анализ трафика запросов и распределения его между репликами.

Для сегмента PostgreSQL из коробки есть потоковая репликация (Streaming Replication, SR). Репликация работает с журналом с упреждающей записью (WAL). Для управления кластером потоковую репликацию используют обычно вместе с фреймворком Patroni, который обеспечивает единую точку входа на кластер, полную автоматизацию переключения и геораспределенный кластер. Для балансировки (распределения запросов) между репликами можно использовать HAProxy/PgBouncer.

Понятно, что для настройки и управления всем этим хозяйством нужно иметь компетентную команду с глубокими знаниями Linux+PG, т. к. основной подводный камень — это довольно скудные возможности мониторинга и контроля за производительностью системы на PostgreSQL, но вендоры работают в этом направлении, и ситуация меняется в лучшую сторону.

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

Теперь затронем тему производительности СУБД — как ее наращивать?

Предположим, что у нас есть такой конь в вакууме — идеально настроенная и спроектированная система, где оптимизировать по коду нечего. Все запросы выполняются оптимально, насколько это возможно. А производительности всё равно не хватает. Что делать?

Администраторы/разработчики как правило используют вертикальное масштабирование серверов. То есть увеличивают аппаратные мощности. Это с одной стороны просто, понятно, и почти всегда предсказуемо, а с другой — финансово затратно. Затратно потому, что высоконагруженные системы развернуты и так на достаточно мощных многопроцессорных системах, и каждый следующий шаг по увеличению того же CPU — это серьезные инвестиции в оборудование. Ценник на новое оборудование может отличаться от ценника на текущее не на проценты, а в разы. Кроме этого, всегда есть потолок (в моменте), когда расширяться уже некуда — «у нас и так самый топовой сервер». Остается горизонтальное масштабирование — распределение нагрузки по репликам кластера СУБД.

Стоит отметить, что горизонтальное масштабирование подходит не всем. Если в вашем профиле нагрузки доминирует транзакционная нагрузка (OLTP), то распараллеливание запросов тут не поможет. Потому что запросы на изменение выполняются все равно (почти всегда) только на основном master‑сервере, а та небольшая часть запросов на чтение вне транзакции не спасет ситуацию. А вот, если у вас система по профилю нагрузки больше похожа на OLAP, то это точно ваш вариант.

Балансировка

Иногда балансировка запросов — это единственный разумный способ сохранить приемлемый отклик от СУБД.

Особенности платформы 1С ограничивают использование вторичных реплик для чтения, что требует дополнительных решений для балансировки нагрузки и автоматического переключения. Мы использовали эту потребность для разработки middleware решения Data Cluster — прокси сервиса для «умной» балансировки трафика между серверами в кластере СУБД. Это пример того, как специфика бизнес‑приложений влияет на выбор архитектуры кластеризации.

По нашему опыту почти любая 1С‑система — это не только OLTP. В ней много аналитики и отчетов. Часто OLTP‑нагрузка значительно меньше OLAP‑нагрузки, и система имеет неплохой потенциал для балансировки — значительную её часть можно утилизировать на дополнительных нодах, где можно выполнять запросы на чтение. Это позволит высвободить ресурсы на основном сервере для транзакционной нагрузки, особенно если бизнес развивается и количество документооборота растет.

Как понять, какая у вас система и какой у нее потенциал к балансировке? Перед внедрением Data Cluster или при проведении любого аудита производительности мы всегда оцениваем возможность системы к балансировке. Для этого собираем в активный рабочий период несколько минут трассы тяжелых запросов и анализируем их по критериям: на чтение/на изменение, в транзакции/вне транзакции, чтение из реальных/временных таблиц. Понимая количественное распределение запросов в разных трассах мы даем оценку готовности системы к горизонтальному масштабированию.

Ниже показан пример балансировки 1С-системы под управлением PostgreSQL при помощи Softpoint Data Cluster (SDC).

Исходные данные: есть высоконагруженная система 1С на PostgreSQL, которая прям задыхалась. Типичная картина: выходные дни, идут самые продажи, отдел поддержки полностью мобилизован и пытается спасать систему. Причин просадки производительности множество: настройки PG, неоптимальные запросы, которые никак не хотели работать под PG также замечательно, как под MS SQL, ограничения по железу. Проблема комплексная, и одним из шагов по исправлению ситуации стало внедрение системы балансировки запросов.

Поскольку у заказчика уже был развернут кластер СУБД для задач отказоустойчивости, то для балансировки почти всё было готово. Осталось лишь развернуть дополнительный сервер SDC.

Начнем с профиля нагрузки на исходном сервере. На графиках ниже три метрики: общая нагрузка на CPU, количество активных соединений к серверу и трафик в виде количества запросов/сек. Данные взяты за полную календарную неделю до внедрения SDC и за другую полную неделю после внедрения. Картинки сделаны из программы мониторинга Perfexpert.

По процессору сразу видно, что ему не очень сладко. Трафик sql достигал 9-10 тысяч запросов в секунду. Пиковые значения не берем.

Перенаправлять на другую реплику можно только запросы на чтение вне транзакции и без использования временных таблиц. Последнее ограничение, конечно, снижает коэффициент балансировки, поскольку 1С очень активно использует работу с временными таблицами, но мы работаем над этой задачей. Тем не менее, даже это позволило перекинуть на реплику значительный объем нагрузки.

Ниже приведено два рисунка с профилем нагрузке после балансировки. Верхний — для master сервера, нижний — для реплики.

Нагрузка по процессору значительно спала и ушла в зону комфортных 50–60%. А на дополнительном сервере она составляет 20–30% – как раз та самая дельта, что ушла с первого сервера. Количество запросов в секунду распределилось в абсолютном значении даже в пользу реплики. То есть доля запросов на чтение сама по себе довольно большая, больше половины, но они простые и не нагружают ресурсы дополнительного сервера в той же степени, что на master-ноде.

Еще один положительный эффект от балансировки — это более оптимальная работа с памятью. Так как данные для трафика OLTP и OLAP разные, то и область памяти shared buffer на мастере станет более эффективно использоваться, а значит снизится нагрузка на дисковую подсистему.

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

На рисунке выше представлена вкладка с правилами модификации и балансировки запросов.

Любое правило состоит из поиска запроса с помощью регулярного выражения и его модификации и/или перенаправления. Модификация запросов на лету относится к модулю QProcessing, о котором мы рассказываем почти в каждой своей статье. Кстати, в редакции для PG мы объединили программы QProcessing и Data Cluster в единый продукт, с сохраненным наименования Data Cluster. Перенаправление запросов по умолчанию всегда работает в автоматическом режиме, но можно жестко указать ему сервер, где ему всегда следует выполняться.

Подробнее о Data Cluster можно почитать на страничке продукта.

Итого в сухом остатке.

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

Высокая доступность — ключевой мотив. Система должна продолжать работать, несмотря на отказ одного из узлов. Автоматическое переключение нагрузки на резервный сервер снижает время простоя до минимально возможного. Минута простоя в таких организациях оборачивается серьезными убытками и потерей репутации. При этом нагрузка на базы данных часто достигает масштабов, при которых один сервер не справляется. Кластеризация может позволить распределять запросы между несколькими репликами. Балансировка не только увеличивает производительность, но и помогает избежать узких мест в системе.

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

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