Горизонтальное масштабирование SSRS

Горизонтальное масштабирование SSRS — это архитектурный подход к увеличению производительности, отказоустойчивости и пропускной способности сервера отчетов SQL Server Reporting Services (SSRS) за счет добавления дополнительных серверов (узлов) в кластерную конфигурацию. В отличие от вертикального масштабирования (увеличения мощности одного сервера), горизонтальное масштабирование распределяет нагрузку между несколькими экземплярами служб, что позволяет обрабатывать большее количество одновременных запросов пользователей и отчетов большого объема.

Архитектура и принцип работы

Горизонтальное масштабирование SSRS реализуется через развертывание масштабируемого развертывания (scale-out deployment) на основе общей базы данных сервера отчетов (ReportServer) и, при необходимости, общего хранилища ключей шифрования. Все узлы кластера являются равноправными и используют одну и ту же базу данных для хранения метаданных, подписок, истории выполнения отчетов и настроек безопасности.

Компоненты архитектуры

• Узлы сервера отчетов (Report Server nodes) — экземпляры службы Reporting Services, установленные на отдельных физических или виртуальных машинах. Каждый узел имеет собственный пул рабочих процессов (AppDomain) и может обрабатывать запросы независимо.
• Общая база данных (ReportServer database) — единственная база данных SQL Server, к которой подключаются все узлы. Она хранит все объекты отчетов, источники данных, расписания, подписки и журналы выполнения.
• База данных временного хранения (ReportServerTempDB) — используется для кэширования промежуточных результатов и временных данных при рендеринге отчетов. В масштабируемой конфигурации она также является общей.
• Балансировщик нагрузки (Load Balancer) — внешнее устройство или программное обеспечение (например, NLB, HAProxy, F5, Azure Load Balancer), которое распределяет входящие HTTP/HTTPS запросы между узлами кластера. Балансировщик может быть настроен на использование «липких сессий» (sticky sessions) для обеспечения согласованности состояния сеанса пользователя.
• Общее хранилище ключей шифрования — для обеспечения безопасности, все узлы должны иметь доступ к одному и тому же симметричному ключу шифрования, используемому для защиты учетных данных источников данных и строк подключения. Ключ хранится в общей базе данных и извлекается каждым узлом при запуске.

Преимущества и ограничения

Преимущества

• Повышение производительности — распределение нагрузки между несколькими серверами позволяет обрабатывать большее количество одновременных запросов и отчетов большого объема без увеличения времени отклика.
• Отказоустойчивость — при выходе из строя одного узла, остальные продолжают обслуживать пользователей. Балансировщик нагрузки автоматически исключает недоступный узел из пула.
• Масштабируемость по требованию — добавление новых узлов может выполняться без остановки работы кластера, что позволяет гибко реагировать на рост нагрузки.
• Упрощение обслуживания — обновления и патчи могут устанавливаться на узлы поочередно (rolling upgrade), минимизируя время простоя.

Ограничения

• Зависимость от общей базы данных — база данных SQL Server является единой точкой отказа (single point of failure). Для обеспечения высокой доступности самой базы данных требуется использование технологий SQL Server Always On Availability Groups или зеркалирования.
• Сложность настройки — требуется корректная настройка балансировщика нагрузки, общего хранилища ключей и синхронизация времени между узлами.
• Проблемы с кэшированием — кэш отчетов хранится локально на каждом узле, что может привести к неконсистентности данных при использовании разных узлов для одного пользователя. Решается настройкой «липких сессий» или использованием общего кэша (например, Redis).
• Ограничения лицензирования — в редакциях SQL Server Standard и Express количество узлов в масштабируемом развертывании ограничено (до 2 узлов в Standard, до 1 в Express). В Enterprise Edition ограничений нет.
• Сложность управления подписками — подписки выполняются на том узле, который первым обработал запрос на создание подписки. При отказе этого узла подписка может не выполниться, если не настроена репликация.

Варианты развертывания

Классическое масштабируемое развертывание (On-premises)

Наиболее распространенный вариант для локальных сред. Включает:

• 2 и более серверов с установленной службой Reporting Services в режиме Native Mode (режим SharePoint также поддерживается, но устарел).
• Балансировщик нагрузки (например, Windows NLB или аппаратный балансировщик).
• Общая база данных на отдельном экземпляре SQL Server.
• Общее хранилище ключей шифрования (обычно хранится в базе данных, но может быть экспортировано в файл).

Горизонтальное масштабирование в облаке (Azure)

В среде Microsoft Azure можно использовать следующие подходы:

• Azure Virtual Machines (IaaS) — развертывание нескольких виртуальных машин с SSRS, объединенных в масштабируемый набор (Scale Set) с балансировщиком нагрузки Azure.
• Azure SQL Managed Instance + SSRS — использование управляемого экземпляра SQL Server в качестве общей базы данных, что обеспечивает высокую доступность и автоматическое резервное копирование.
• Azure PaaS (Power BI Report Server) — альтернатива SSRS, где масштабирование управляется платформой автоматически.

Гибридные конфигурации

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

Настройка и развертывание

Предварительные требования

1. Установка SQL Server Reporting Services в режиме Native Mode на каждом узле.
2. Наличие экземпляра SQL Server для общей базы данных (рекомендуется использовать SQL Server Standard или Enterprise с поддержкой Always On).
3. Настройка балансировщика нагрузки (например, Windows NLB или стороннего).
4. Синхронизация времени между всеми узлами (использование NTP).
5. Обеспечение доступа всех узлов к общей базе данных по сети (обычно через порт 1433).

Процесс настройки

1. Установка первого узла — выполняется стандартная установка SSRS, при которой создается база данных сервера отчетов.
2. Добавление дополнительных узлов — на каждом новом сервере запускается установка SSRS, но при настройке базы данных выбирается опция «Подключиться к существующей базе данных сервера отчетов».
3. Настройка ключей шифрования — с помощью утилиты rsconfig или Configuration Manager экспортируется ключ шифрования с первого узла и импортируется на каждом дополнительном узле.
4. Настройка балансировщика нагрузки — создается виртуальный IP-адрес или DNS-имя, которое направляет трафик на все узлы. Для HTTP-трафика обычно используется порт 80 или 443.
5. Проверка работоспособности — выполняется тестирование доступа к отчетам через балансировщик, выполнение подписок и проверка отказоустойчивости.

Примеры использования

• Крупные корпоративные порталы отчетности — организации с тысячами пользователей, ежедневно формирующих десятки тысяч отчетов, используют горизонтальное масштабирование для обеспечения приемлемого времени отклика.
• Системы бизнес-аналитики (BI) — в компаниях, где отчеты генерируются в реальном времени на основе больших объемов данных (например, в ритейле или финансовом секторе).
• Государственные и муниципальные учреждения — для обеспечения бесперебойной работы систем отчетности, критичных для принятия решений.

Сравнение с вертикальным масштабированием

Интересные факты

• В SSRS 2016 и более ранних версиях масштабируемое развертывание поддерживалось только в режиме Native Mode. Начиная с SSRS 2017, также поддерживается режим Power BI Report Server.
• Максимальное количество узлов в масштабируемом развертывании SSRS не ограничено программно, но на практике редко превышает 8–10 узлов из-за нагрузки на общую базу данных.
• В некоторых конфигурациях для повышения производительности базы данных используется разделение (sharding) таблиц ExecutionLog и Subscriptions по узлам, но это нестандартное решение, не поддерживаемое Microsoft.

Источники

• Microsoft Docs: «Scale-out deployment for Reporting Services» (SQL Server Reporting Services documentation).
• Microsoft Learn: «Plan for scale-out deployment of Reporting Services».
• SQL Server Reporting Services Team Blog: «Best practices for scale-out deployments».
• TechNet: «Deploying SQL Server Reporting Services in a Scale-Out Configuration».