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

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

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

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

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

Ключевые моменты

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

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

  Замечание

  Функция AlwaysOn реляционного ядра СУБД не распространяется на службы Analysis Services. Экземпляр служб Analysis Services нельзя настроить для запуска в группе доступности AlwaysOn.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Этот подход можно свести к следующему:

• Используйте выделенное оборудование и экземпляры служб Analysis Services для обработки базы данных. Установите для базы данных значение только для чтения после завершения обработки. Инструкции см. в разделе "Переключение базы данных служб Analysis Services" между режимами ReadOnly и ReadWrite .

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

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

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

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

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

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

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

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

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

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

• Режим Active/Active в данный момент не поддерживается. Active/Passive (отказоустойчивость) — это единственная поддерживаемая конфигурация 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: использование табличных моделей в крупномасштабном коммерческом решении