Поделиться через


Обзор эластичных пулов с гипермасштабированием в База данных SQL Azure

Применимо к: База данных SQL Azure

В этой статье представлен обзор эластичных пулов гипермасштабирования в База данных SQL Azure.

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

Примеры создания, масштабирования или перемещения баз данных в эластичный пул гипермасштабирования с помощью Azure CLI или PowerShell см. в статье "Работа с эластичными пулами с гипермасштабированием" с помощью средств командной строки

Примечание.

Эластичные пулы для гипермасштабирования в настоящее время находятся в предварительной версии.

Обзор

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

Сценарии использования эластичного пула с базами данных гипермасштабирования:

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

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

Архитектура

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

Ниже описана архитектура эластичного пула для баз данных гипермасштабирования:

  • Эластичные пулы гипермасштабирования состоят из основного пула, в котором размещаются базы данных с гипермасштабированием и при настройке до четырех дополнительных пулов высокой доступности.
  • Базы данных с гипермасштабированием, размещенные в основном эластичном пуле, используют вычислительный процесс ядра СУБД SQL Server (sqlservr.exe), виртуальные ядра, память и кэш SSD.
  • При настройке высокого уровня доступности для основного пула создаются дополнительные пулы высокой доступности, содержащие реплики баз данных только для чтения для баз данных в основном пуле. Каждый первичный пул может иметь не более четырех пулов реплик высокой доступности. Каждый пул высокой доступности использует вычислительные ресурсы, кэш SSD и память для всех вторичных баз данных только для чтения в пуле.
  • Базы данных гипермасштабирования в основном эластичном пуле используют одну и ту же службу журналов. Так как базы данных в пулах высокой доступности не имеют рабочей нагрузки записи, они не используют службу журналов.
  • Каждая база данных гипермасштабирования имеет собственный набор серверов страниц, и эти серверы страницы совместно используются между базой данных-источником в основном пуле и всеми базами данных-получателем реплик в пуле высокой доступности.
  • Геореплицированные базы данных вторичного гипермасштабирования можно разместить в другом эластичном пуле.
  • Указание ApplicationIntent=ReadOnly в базе данных строка подключения направляет вас в базу данных реплики только для чтения в одном из пулов высокой доступности.

На следующей схеме показана архитектура эластичного пула для баз данных гипермасштабирования:

Схема архитектуры эластичного пула с гипермасштабированием.

Управление базами данных эластичного пула гипермасштабирования

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

Единственное различие заключается в том, что возможность изменять количество реплик высокого уровня доступности (H/A) для существующего эластичного пула гипермасштабирования. Для этого:

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

Преобразование баз данных без гипермасштабирования в эластичные пулы гипермасштабирования

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

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

Преобразование баз данных без гипермасштабирования в эластичные пулы с гипермасштабированием с помощью T-SQL

Команды T-SQL можно использовать для преобразования нескольких баз данных общего назначения и их добавления в существующий эластичные пул гипермасштабирования с именем hsep1:

ALTER DATABASE gpepdb1 MODIFY (SERVICE_OBJECTIVE = ELASTIC_POOL(NAME = [hsep1]))
ALTER DATABASE gpepdb2 MODIFY (SERVICE_OBJECTIVE = ELASTIC_POOL(NAME = [hsep1]))
ALTER DATABASE gpepdb3 MODIFY (SERVICE_OBJECTIVE = ELASTIC_POOL(NAME = [hsep1]))
ALTER DATABASE gpepdb4 MODIFY (SERVICE_OBJECTIVE = ELASTIC_POOL(NAME = [hsep1]))

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

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

Преобразование баз данных без гипермасштабирования в эластичные пулы с гипермасштабированием с помощью PowerShell

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

  1. Используйте командлет Get-AzSqlElasticPoolDatabase для перечисления всех баз данных в эластичном пуле gpep1общего назначения.
  2. Командлет Where-Object фильтрует список только для имен баз данных, начиная с gpepdb.
  3. Для каждой базы данных командлет Set-AzSqlDatabase запускает преобразование. В этом случае вы неявно запрашиваете преобразование на уровень служб "Гипермасштабирование", указав целевой эластичные пулы гипермасштабирования с именем hsep1.
    • Параметр -AsJob позволяет каждому из Set-AzSqlDatabase запросов выполняться параллельно. Если вы предпочитаете запускать преобразования по одному, можно удалить -AsJob параметр.
$dbs = Get-AzSqlElasticPoolDatabase -ResourceGroupName "myResourceGroup" -ServerName "mylogicalserver" -ElasticPoolName "gpep1"
$dbs | Where-Object { $_.DatabaseName -like "gpepdb*" } | % { Set-AzSqlDatabase -ResourceGroupName "myResourceGroup" -ServerName "mylogicalserver" -DatabaseName ($_.DatabaseName) -ElasticPoolName "hsep1" -AsJob }

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

Ограничения ресурсов

Ниже перечислены поддерживаемые ограничения для работы с базами данных гипермасштабирования в эластичных пулах:

  • Поддерживаемое поколение оборудования: standard-series (Gen5), premium-series и premium-series memory оптимизировано.
  • Максимальное количество виртуальных ядер на пул: 80 или 128 виртуальных ядер в зависимости от цели уровня обслуживания.
  • Максимальный поддерживаемый размер данных для каждой базы данных: 100 ТБ.
  • Максимальный общий размер данных в пуле: 100 ТБ.
  • Максимальная поддерживаемая пропускная способность журнала транзакций для каждой базы данных: 100 МБ.
  • Максимальная поддерживаемая общая пропускная способность журнала транзакций в пуле: 131,25 МБ/секунда.
  • Каждый эластичные пулы гипермасштабирования могут содержать до 25 баз данных.

Дополнительные сведения см. в ограничениях ресурсов эластичных пулов гипермасштабирования для стандартных, премиум-рядов и памяти серии Premium.

Примечание.

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

Ограничения

Необходимо учитывать следующие ограничения.

  • Изменение существующего эластичного пула, отличного от гипермасштабирования, на выпуск Hyperscale не поддерживается. В разделе преобразования представлены некоторые альтернативные варианты, которые можно использовать.
  • Изменение выпуска эластичного пула гипермасштабирования на выпуск, отличный от гипермасштабирования, не поддерживается.
  • Чтобы выполнить обратную миграцию соответствующей базы данных, которая находится в эластичном пуле гипермасштабирования, сначала ее необходимо удалить из эластичного пула гипермасштабирования. После этого автономная база данных гипермасштабирования может быть "обратно перенесена" в автономную базу данных общего назначения.
  • Для уровня служб гипермасштабирования поддержка избыточности зоны может быть указана только во время создания базы данных или эластичного пула и не может быть изменена после подготовки ресурса. Дополнительные сведения см. в разделе "Миграция База данных SQL Azure в поддержку зоны доступности".
  • Добавление именованной реплики в эластичном пуле гипермасштабирования не поддерживается. Попытка добавить именованную реплику базы данных Гипермасштабирования в эластичном пуле гипермасштабирования приводит к ошибке UnsupportedReplicationOperation . Вместо этого создайте именованную реплику в виде одной базы данных гипермасштабирования.

Рекомендации по избыточным зонам эластичных пулов

Ниже приведены некоторые рекомендации по избыточным зонам эластичных пулов гипермасштабирования.

Примечание.

Эластичные пулы с гипермасштабированием с избыточностью зоны доступны в настоящее время в предварительной версии. Дополнительные сведения см . в записи блога: гипермасштабирование эластичных пулов с избыточностью зоны.

  • В гипермасштабируемые пулы эластичных баз данных с избыточностью между зонами можно добавить только базы данных с избыточностью в зонах (ZRS или GZRS).
  • Отдельная база данных гипермасштабирования должна быть создана с избыточностью между зонами и хранилищем резервных копий с избыточностью между зонами (ZRS или GZRS), чтобы добавить его в эластичном пуле, избыточном между зонами. Для баз данных Гипермасштабирования без избыточности зоны выполните передачу данных в новую базу данных гипермасштабирования с включенным параметром избыточности зоны. Клон необходимо создать с помощью копирования базы данных, восстановления на определенный момент времени или геореплики. Дополнительные сведения см. в разделе "Повторное развертывание" (гипермасштабирование).
  • Чтобы переместить базу данных Гипермасштабирования из одного эластичного пула в другой, необходимо сопоставить параметры избыточности зоны и хранилища резервных копий, избыточных между зонами.
  • Чтобы преобразовать базу данных из другого уровня служб, отличного от гипермасштабирования, в эластичном пуле с гипермасштабированием с избыточностью зоны:
    • В портал Azure сначала включите избыточность зоны и хранилище резервных копий с избыточностью между зонами (ZRS). Затем можно добавить базу данных в избыточный в зоне эластичного пула Гипермасштабирования.
    • С помощью PowerShell сначала включите избыточность зоны. Затем с помощью Set-AzSqlDatabase убедитесь, что -BackupStorageRedundancy параметр используется для указания избыточного между зонами хранилища резервных копий (ZRS или GZRS).

Известные проблемы

Проблема Рекомендация
При добавлении многих баз данных, не относящихся к гипермасштабированию, в эластичном пуле гипермасштабирования может возникнуть ошибка Could not perform the operation because server would exceed the allowed Database Throughput Unit quota of 54000. (Code: ServerDtuQuotaExceeded). Хотя сообщение относится к единицам пропускной способности базы данных (DTU), оно связано с общей квотой DTU /vCore, применяемой на каждом логическом сервере. Эта проблема связана с дефектом, из-за которого виртуальные ядра вычисляются неправильно на отдельном уровне базы данных. Ниже приведены некоторые варианты решения проблемы.
• Добавление баз данных в один раз в эластичном пуле гипермасштабирования.
• Перед добавлением базы данных в эластичном пуле гипермасштабирования сначала преобразуйте базу данных в автономный гипермасштабирование базы данных.
• Запросить увеличение квоты на уровне сервера, как описано здесь.
Настройка георепликации для базы данных из избыточного между зонами эластичного пула гипермасштабирования в избыточном пуле гипермасштабирования в другом регионе завершается ошибкой Provisioning of zone redundant Hyperscale database with local backup redundancy is not supported. Zone redundant Hyperscale databases must use either zone or geo zone backup redundancy. Эта ошибка не возникает, если второй эластичное пул гипермасштабирования является избыточным по зонам или находится в одном регионе. Чтобы обойти эту проблему, можно использовать Azure PowerShell и явно указать избыточность между зонами в командной строке. New-AzSqlDatabaseSecondary -ResourceGroupName "primary-rg" -ServerName "primary-server" -DatabaseName "hsdb1" -PartnerResourceGroupName "secondary-rg" -PartnerServerName "secondary-server" -AllowConnections "All" -SecondaryElasticPoolName "secondary-nonzr-pool" -BackupStorageRedundancy Local -ZoneRedundant:$false
Добавление базы данных из избыточного между зонами эластичного пула гипермасштабирования в группу отработки отказа с избыточным гипермасштабированием пула эластичных пулов гипермасштабирования в другом регионе завершится сбоем, но операция, как представляется, выполняется без какого-либо прогресса. При использовании таких средств, как SSMS, может отображаться геоторичная база данных, но вы не можете подключиться и использовать геоторичную базу данных. Группа отработки отказа может показать состояние "Начальное значение 0%" для гео-вторичной базы данных. Эта проблема не возникает, если второй эластичного пула гипермасштабирования является избыточным по зонам. Чтобы обойти эту проблему, настройте георепликацию вне группы отработки отказа с помощью Azure PowerShell, явно указывая избыточность между зонами в командной строке New-AzSqlDatabaseSecondary -ResourceGroupName "primary-rg" -ServerName "primary-server" -DatabaseName "hsdb1" -PartnerResourceGroupName "secondary-rg" -PartnerServerName "secondary-server" -AllowConnections "All" -SecondaryElasticPoolName "secondary-nonzr-pool" -BackupStorageRedundancy Local -ZoneRedundant:$false. Затем можно добавить базу данных в группу отработки отказа.
В редких случаях при попытке переместить или восстановить базу данных гипермасштабирования в эластичном пуле может возникнуть ошибка 45122 - This Hyperscale database cannot be added into an elastic pool at this time. In case of any questions, please contact Microsoft support. Это ограничение связано с подробными сведениями о реализации. Если эта ошибка блокирует вас, вызовите инцидент поддержки и запрос справки.