Высокий уровень доступности и масштабируемость в службах Analysis Services

Применимо к: SQL Server Analysis Services Azure Analysis Services Fabric/Power BI Premium

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

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

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

Основные моменты

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

• В службах Analysis Services используются механизмы высокой доступности и масштабируемости, встроенные в платформу сервера Windows: балансировка нагрузки сети (NLB), отказоустойчивая кластеризация Windows Server или оба.

  Примечание

  Функция Always On ядра реляционной базы данных не распространяется на службы Analysis Services. Экземпляр служб Analysis Services нельзя настроить для работы в группе доступности Always On.

  Несмотря на то что службы Analysis Services не выполняются в группах доступности AlwaysOn, они могут извлекать и обрабатывать данные из реляционной базы данных Always On. Инструкции по настройке высокодоступной реляционной базы данных для использования со службами Analysis Services см. в разделе Службы Analysis Services с группами доступности AlwaysOn.

• Если единственной целью является высокий уровень доступности, она может быть достигнута за счет избыточности в отказоустойчивом кластере. Предполагается, что сменные узлы имеют такую же конфигурацию аппаратного и программного обеспечения, как у активного узла. Отказоустойчивая кластеризация Windows Server обеспечивает высокий уровень доступности, но без масштабирования.

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

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

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

Сравнение конфигураций с одним или несколькими серверами

При обычном развертывании с одним сервером рабочие нагрузки обработки и запросов выполняются одновременно, при условии, что системных ресурсов достаточно для обоих действий. Для поддержки запросов службы Analysis Services сохраняют существующие структуры данных неизменными, пока обновленная версия обрабатывается в фоновом режиме. Во всех режимах сервера существует аппаратное требование о наличии достаточного объема памяти и дискового пространства для обработки временных структур данных, хотя каждый режим предъявляет разные требования к системным ресурсам и имеет разную степень готовности к NUMA.

Одиночные серверы и масштабируемость

Одиночный высокопроизводительный, многоядерный сервер должен обеспечивать достаточный уровень масштабируемости сам по себе. Теоретически в высокопроизводительной системе с большим числом ядер, ОЗУ и дисковым пространством можно увеличить масштаб отдельной системы.

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

Развертывания в конфигурации с несколькими серверами

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

Аналогичным образом, если для выполнения рабочих нагрузок запросов требуется высокая доступность, необходимо использовать несколько серверов. В этом сценарии рекомендуется использовать сочетание баз данных только для чтения и чтения и записи, работающих на отдельных экземплярах служб Analysis Services на выделенном оборудовании. Базы данных, доступные только для чтения, обрабатывают запросы. Базы данных, доступные только для записи, используются для обработки. В следующем разделе приводится расширенное описание этого наиболее часто используемого метода.

Виртуальные машины и высокий уровень доступности

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

Масштабируемость с использованием баз данных, доступных только для чтения и для чтения и записи

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

Хотя рекомендации в статье Горизонтальное масштабирование запросов для служб Analysis Services с использованием баз данных, доступных только для чтения (опубликованной в 2008 году), устарели, в целом они по-прежнему действительны. Несмотря на то что операционные системы и компьютерное оборудование эволюционировали, а ссылки на конкретные платформы и ограничения ЦПУ больше не актуальны, основной метод использования баз данных, доступных только для чтения или для чтения и записи, для больших объемов данных по запросам остался неизменным.

Этот метод можно описать следующим образом.

• Для обработки базы данных используется выделенное оборудование и экземпляры служб Analysis Services. По завершении обработки база данных переводится в режим доступности только для чтения. Инструкции см. в разделе Switch an Analysis Services database between ReadOnly and ReadWrite modes .

• Используйте несколько идентичных серверов запросов для запуска копий одной и той же базы данных служб Analysis Services, доступной только для чтения. Серверы развертываются в кластере балансировки сетевой нагрузки, доступ к которым осуществляется через одно имя виртуального сервера, которое служит единой точкой входа в кластер.

• Для копирования всего каталога данных с сервера обработки на каждый сервер запросов и присоединения одной и той же базы данных в режиме только для чтения ко всем серверам запросов используется robocopy. Можно использовать моментальные снимки SAN, синхронизацию или любой другой инструмент или метод, применяемый для перемещения производственных баз данных.

Требования к ресурсам для табличных и многомерных рабочих нагрузок

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

Сервер и режим хранения	Влияние на системный ресурс
Табличная рабочая нагрузка в памяти (по умолчанию), где запросы выполняются как табличное сканирование структуры данных в памяти.	Выделяет ОЗУ и ЦПУ с высокой тактовой частотой.
Табличная рабочая нагрузка в режиме DirectQuery, где запросы переносятся на резервные серверы реляционных баз данных, а обработка ограничивается построением метаданных в модели.	Акцент на производительность реляционной базы данных, уменьшение задержки в сети и максимальное увеличение пропускной способности. Более быстрый ЦПУ может, помимо прочего, повысить производительность обработчика запросов для служб Analysis Services.
Многомерные модели с использованием хранилища MOLAP	Выбор сбалансированной конфигурации, включающей дисковые операции ввода-вывода для быстрой загрузки данных и достаточный объем ОЗУ для хранения кэшированных данных.
Многомерные модели с использованием хранилища ROLAP	Максимальное число дисковых операций ввода-вывода и минимальная задержка в сети.

Высокий уровень доступности и избыточности через WSFC

Службы Analysis Services можно установить в существующий отказоустойчивый кластер (WSFC) — это обеспечит высокий уровень доступности, позволяющий восстановить службу в кратчайшие сроки.

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

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

При рассмотрении WSFC учитывайте следующие моменты:

• Режим "активный/активный" в данный момент не поддерживается. Режим "активный/пассивный (отказоустойчивый)" — единственная поддерживаемая конфигурация WSFC для служб Analysis Services.
• При кластеризации служб Analysis Services убедитесь, что все узлы в кластере работают на одинаковом или схожем оборудовании и имеют одинаковый операционный контекст — версию и пакеты обновления операционной системы, версию и пакеты обновления (или накопительные обновления) служб Analysis Services и режим сервера.
• Избегайте переназначения пассивного узла в качестве активного узла другой рабочей нагрузки. Если в экстренной ситуации узел не справится с обоими потоками рабочей нагрузки, достигнутое повышение производительности компьютера потеряет смысл.

Подробные инструкции и справочные сведения по развертыванию служб Analysis Services в отказоустойчивом кластере см. в следующем документе Кластеризация служб SQL Server Analysis Services. Это руководство написано для SQL Server 2012, однако применяется и к более новым версиям служб Analysis Services.

См. также:

Синхронизация баз данных служб Analysis Services
Принудительное установление связь NUMA для табличных баз данных служб Analysis Services
Пример внедрения служб Analysis Services: использование табличных моделей в крупномасштабных коммерческих решениях