Изучение управляемого экземпляра SQL

  • 9 мин

Хотя многие организации изначально переходят на Azure с помощью предложений IaaS, служба "платформа как услуга" (PaaS) предоставляет дополнительные преимущества. Также вам больше не нужно устанавливать SQL Server или соответствующие исправления, так как за это отвечает сама служба. Кроме того, проверка согласованности и резервные копии также являются частью управляемой службы, включая средства обеспечения безопасности и повышения производительности в составе предложений PaaS.

Управляемый экземпляр SQL Azure — это полностью функциональный экземпляр SQL Server, который почти на 100 % совместим с локальной экосистемой. Он включает такие функции, как агент SQL, доступ к tempdb, межбазовый запрос и среда CLR. Служба использует ту же инфраструктуру, что и База данных SQL Azure, и имеет все преимущества службы PaaS, такие как автоматическое резервное копирование, автоматизированное исправление и встроенные средства обеспечения высокой доступности.

Функции Управляемого экземпляра SQL Azure

Управляемый экземпляр SQL Azure упрощает перенос существующих приложений, разрешая восстановление из локальных резервных копий. В отличие от Базы данных SQL Azure, которая разработана на базе структур отдельных баз данных, Управляемый экземпляр SQL предоставляет весь экземпляр SQL Server, допуская использование до 100 баз данных, а также предоставляя доступ к системным базам данных. Управляемый экземпляр предоставляет и другие функции, недоступные в Базе данных SQL Azure, включая запросы между базами данных, среду CLR и системную базу данных msdb, а также позволяет использовать Агент SQL.

Параметры

При создании Управляемого экземпляра SQL Azure доступны два уровня служб, которые совпадают с моделью на основе виртуальных ядер для Базы данных SQL Azure (управляемый экземпляр приобретается с использованием модели на основе виртуальных ядер), — уровни "Критически важный для бизнеса" и "Общего назначения". Между этими двумя уровнями есть минимальные различия в функциональных возможностях, два основных — это поддержка выполняющейся в памяти OLTP и предоставление вторичной реплики для чтения на критически важном для бизнеса уровне. На уровне общего назначения эти возможности недоступны. Оба уровня обеспечивают одинаковую доступность и позволяют независимо настраивать хранение и вычисления.

Функция связывания обеспечивает гибридную возможность репликации баз данных из экземпляров SQL Server в Управляемый экземпляр SQL Azure. Функция канала реплицирует данные с помощью распределенных групп доступности, доступных на основе технологического стека групп доступности Always On. Записи журнала транзакций реплицируются как часть распределенных групп доступности.

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

Функцию связывания также можно использовать в качестве решения для гибридного аварийного восстановления, тогда можно выполнить отработку отказа баз данных SQL Server, размещенных в любом месте в базе данных, работающей на Управляемом экземпляре SQL. Аналогичным образом можно использовать функцию связывания, чтобы предоставить вторичную базу данных только для чтения в Управляемом экземпляре SQL Базы данных SQL для разгрузки ресурсоемких операций только для чтения.

Дополнительные сведения о настройке функции связывания для Управляемого экземпляра SQL Azure см. в статье Подготовка среды для функции связи — Управляемый экземпляр SQL Azure.

Пул экземпляров (предварительная версия)

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

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

Сведения о развертывании пула экземпляров для Управляемого экземпляра SQL см. в статье Развертывание управляемого экземпляра SQL Azure в пуле экземпляров.

Высокая доступность

Так как Управляемый экземпляр SQL Azure поддерживается службой PaaS, в этот продукт уже встроены средства обеспечения высокого уровня доступности. Автономный Управляемый экземпляр SQL предлагает Соглашение об уровне обслуживания (SLA) с покрытием 99,99 %, гарантирующее простой не более 52,60 минут в год. Архитектура аналогична Базе данных SQL Azure с уровнем общего назначения, где используется репликация хранилища для обеспечения доступности, и критически важным для бизнеса уровнем, где используется несколько реплик.

Резервные копии

Автоматическое резервное копирование также настраивается для Управляемого экземпляра SQL Azure автоматически. Одно из ключевых различий между Управляемым экземпляром SQL Azure и Базой данных SQL Azure заключается в том, что при использовании Управляемого экземпляра можно вручную создать резервную копию базы данных, предназначенную только для копирования. Необходимо выполнять резервное копирование по URL-адресу, так как доступ к локальному хранилищу запрещен. Кроме того, можно настроить долгосрочное хранение (LTR) для сохранения автоматических резервных копий до 10 лет в геоизбыточном хранилище BLOB-объектов Azure.

Резервное копирование базы данных выполняется по тому же расписанию, что и для Базы данных SQL Azure. Эти расписания невозможно настроить.

  • Полное — раз в неделю
  • Разностное — каждые 12 часов
  • Журнал транзакций — каждые 5–10 минут в зависимости от использования журнала транзакций

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

  • Портал Azure
  • PowerShell
  • Azure CLI

Однако при восстановлении действуют некоторые ограничения. Для восстановления из одного экземпляра в другой оба эти экземпляра должны находиться в одной подписке Azure и в одном регионе Azure. Кроме того, восстановить весь управляемый экземпляр невозможно — только отдельные базы данных в управляемом экземпляре SQL.

Как и в случае с Базой данных SQL Azure, восстановление поверх существующей базы данных невозможно. Удалите или переименуйте существующую базу данных перед ее восстановлением из резервной копии. Так как управляемый экземпляр SQL является полнофункциональным экземпляром SQL Server, можно выполнить команду RESTORE, в то время как в Базе данных Azure SQL это невозможно. Однако так как это служба PaaS, существуют некоторые ограничения:

  • Необходимо осуществлять восстановление из конечной точки URL-адреса. У вас нет доступа к локальным дискам.
  • Можно использовать следующие параметры (помимо указания базы данных):
    • FILELISTONLY
    • HEADERONLY
    • LABELONLY
    • VERIFYONLY
  • Файлы резервных копий, содержащие несколько файлов журнала, невозможно восстановить.
  • Файлы резервных копий, содержащие несколько резервных наборов данных, невозможно восстановить.
  • Резервные копии, содержащие In-Memory/FILESTREAM, невозможно восстановить.

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

Аварийное восстановление

Управляемый экземпляр Базы данных SQL Azure предлагает группы автоматической отработки отказа в качестве средства для реализации аварийного восстановления. Эта функция защищает весь управляемый экземпляр и все содержащиеся в нем базы данных, а не только отдельные базы данных. Этот процесс асинхронно реплицирует данные из Управляемого экземпляра SQL Azure во вторичную реплику; однако сейчас все это ограничено сопряженным регионом Azure первичной копии и допускается только одна реплика.

Подобно Базе данных SQL Azure, группы автоматической отработки отказа предлагают конечные точки прослушивателя, доступные для чтения и записи и только для чтения, что упрощает управление строками подключения. В случае отработки отказа строки подключения приложения будут автоматически перенаправлены к соответствующему экземпляру. Хотя эти конечные точки в целом согласуются с Базой данных SQL Azure, они имеют слегка отличный формат — <fog-name>.zone_id.database.windows.net whereas Azure SQL Database is in the <fog-name>.secondary.database.windows.net.

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

Чтобы узнать о новых возможностях Управляемого экземпляра SQL Azure, ознакомьтесь с разделом Что нового в управляемом экземпляре SQL Azure?.