Файлы данных SQL Server в Azure

Файлы данных SQL Server в Azure обеспечивают встроенную поддержку файлов базы данных SQL Server, хранящихся в виде BLOB-объектов Azure. Это позволяет создавать базу данных в SQL Server, работающей в локальной среде или виртуальной машине в Azure, с выделенным расположением хранилища данных в хранилище BLOB-объектов Azure. Это улучшение особенно упрощает перемещение баз данных между компьютерами с помощью операций отсоединения и подключения. Кроме того, он предоставляет альтернативное расположение хранилища для файлов резервной копии базы данных, позволяя восстановить из службы хранилища Azure или из нее. Таким образом, он позволяет использовать несколько гибридных решений, предоставляя несколько преимуществ для виртуализации данных, перемещения данных, безопасности и доступности, а также простой низкой стоимости и обслуживания для обеспечения высокой доступности и эластичного масштабирования.

В этом разделе рассматриваются основные понятия и рекомендации по хранению файлов данных SQL Server в службе хранилища Azure.

Практический практический опыт использования этой новой функции см. в руководстве по файлам данных SQL Server в службе хранилища Azure.

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

Интеграция SQL Server с хранилищем Azure

Преимущества использования файлов данных SQL Server в Azure

  • Преимущества простой и быстрой миграции: Эта функция упрощает процесс миграции путем перемещения одной базы данных между компьютерами в локальной среде, а также между локальными и облачными средами без каких-либо изменений в приложении. Поэтому она поддерживает добавочную миграцию при сохранении существующей локальной инфраструктуры. Кроме того, доступ к централизованному хранилищу данных упрощает логику приложения, когда приложению необходимо выполнять в нескольких расположениях в локальной среде. В некоторых случаях может потребоваться быстро настроить центры компьютеров в географически распределенных расположениях, которые собирают данные из многих различных источников. С помощью этого нового улучшения вместо перемещения данных из одного расположения в другое можно хранить множество баз данных в виде больших двоичных объектов Azure, а затем запускать скрипты Transact-SQL для создания баз данных на локальных машинах или виртуальных машинах.

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

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

  • Преимущества безопасности: Это новое усовершенствование позволяет отделять вычислительный экземпляр от экземпляра хранилища. У вас может быть полностью зашифрованная база данных с расшифровкой только в вычислительном экземпляре, но не в экземпляре хранилища. Другими словами, используя это новое улучшение, можно шифровать все данные в общедоступном облаке с помощью сертификатов прозрачного шифрования данных (TDE), которые физически отделены от данных. Ключи TDE можно хранить в базе данных master, которая хранится на вашем локальном физически защищённом сервере и создается локальная резервная копия. Эти локальные ключи можно использовать для шифрования данных, которые находятся в службе хранилища Azure. Если учетные данные учетной записи хранения облака украдены, данные по-прежнему остаются безопасными, так как сертификаты TDE всегда находятся в локальной среде.

Основные понятия и требования

Основные понятия службы хранилища Azure

При использовании файлов данных SQL Server в Azure необходимо создать учетную запись хранения и контейнер в Azure. Затем необходимо создать учетные данные SQL Server, в том числе сведения о политике контейнера, а также подписанный URL-адрес, необходимый для доступа к контейнеру.

В Azure учетная запись хранения представляет самый высокий уровень пространства имен для доступа к BLOB-объектам. Учетная запись хранения может содержать неограниченное количество контейнеров, если их общий размер составляет менее 500 ТБ. Последние сведения об ограничениях хранилища см. в разделе “Ограничения подписки Azure, квоты и ограничения служб”. Контейнер объединяет набор BLOB-объектов. Все блобы должны находиться в контейнере. Учетная запись может содержать неограниченное количество контейнеров. Аналогичным образом контейнер также может хранить неограниченное количество BLOB-объектов. Существует два типа объектов, которые могут храниться в Azure Storage: блочные и страничные блобы. Эта новая функция использует страничные блобы, которые могут быть объемом до 1 ТБ и более эффективны при частом изменении диапазонов байтов в файле. Доступ к BLOB-объектам можно получить с помощью следующего формата URL-адреса: http://storageaccount.blob.core.windows.net/<container>/<blob>

Рекомендации по выставлению счетов Azure

Оценка стоимости использования служб Azure является важным вопросом в процессе принятия решений и планирования. При хранении файлов данных SQL Server в службе хранилища Azure необходимо платить за расходы, связанные с хранилищем и транзакциями. Кроме того, для внедрения файлов данных SQL Server в хранилище Azure необходимо неявное продление аренды контейнеров Blob каждые 45–60 секунд. Это также приводит к затратам на транзакции для каждого файла базы данных, например .mdf или LDF. На основе наших оценок стоимость продления аренды для двух файлов базы данных (.mdf и LDF) составляет около 2 центов в месяц в соответствии с текущей моделью ценообразования. Мы рекомендуем использовать сведения на странице цен Azure , чтобы оценить ежемесячные затраты, связанные с использованием службы хранилища Azure и виртуальных машин Azure.

Основные понятия SQL Server

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

  • Необходимо создать политику для контейнера, а также создать подписанное ключевое значение общего доступа (SAS).

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

  • Необходимо хранить сведения о контейнере службы хранилища Azure, его связанном имени политики и ключа SAS в хранилище учетных данных SQL Server.

В следующем примере предполагается, что был создан контейнер в службе хранилища Azure и создана политика с правами на чтение, запись и список. Создание политики для контейнера создает ключ SAS, который безопасно хранить в памяти в незашифрованном виде и который необходим SQL Server для доступа к файлам блоба в контейнере. В следующем фрагменте кода замените 'your SAS key' запись, аналогичную следующей: 'sr=c&si=<MYPOLICYNAME>&sig=<THESHAREDACCESSSIGNATURE>' Дополнительные сведения см. в статье Создание и использование сигнатуры общего доступа

-- Create a credential  
CREATE CREDENTIAL [https://testdb.blob.core.windows.net/data]  
WITH IDENTITY='SHARED ACCESS SIGNATURE',  
SECRET = 'your SAS key'  
  
-- Create database with data and log files in Azure container.  
CREATE DATABASE testdb   
ON  
( NAME = testdb_dat,  
    FILENAME = 'https://testdb.blob.core.windows.net/data/TestData.mdf' )  
 LOG ON  
( NAME = testdb_log,  
    FILENAME =  'https://testdb.blob.core.windows.net/data/TestLog.ldf')

Это важно

Если в контейнере есть активные ссылки на файлы данных, попытка удалить соответствующие учетные данные SQL Server завершается ошибкой.

Безопасность

Ниже приведены рекомендации по безопасности и требования при хранении файлов данных SQL Server в службе хранилища Azure.

  • При создании контейнера для службы хранения объектов Blob в Azure рекомендуется установить приватный доступ. При установке доступа на "частный" данные контейнера и BLOB-объектов могут быть прочитаны только владельцем учетной записи Azure.

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

  • Кроме того, мы рекомендуем продолжить реализацию традиционных локальных методик безопасности для баз данных.

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

Ниже приведены предварительные требования для установки при хранении файлов данных SQL Server в Azuree.

  • Локальная среда SQL Server: Версия SQL Server 2014 включает эту функцию. Сведения о том, как скачать SQL Server 2014, см. в статье SQL Server 2014.

  • SQL Server, работающий на виртуальной машине Azure: если вы устанавливаете SQL Server на виртуальной машине Azure, установите SQL Server 2014 или обновите существующий экземпляр. Аналогичным образом можно также создать новую виртуальную машину в Azure с помощью образа платформы SQL Server 2014. Сведения о том, как скачать SQL Server 2014, см. в статье SQL Server 2014.

Ограничения

  • В текущем выпуске этой функции хранение FileStream данных в службе хранилища Azure не поддерживается. Данные можно хранить Filestream в интегрированной локальной базе данных Azure Storage, но нельзя перемещать данные FileStream между компьютерами с помощью Azure Storage. Для FileStream данных рекомендуется продолжать использовать традиционные методы перемещения файлов (.mdf, LDF), связанных с Filestream между разными компьютерами.

  • В настоящее время это новое усовершенствование не поддерживает более одного экземпляра SQL Server, обращаюющегося к тем же файлам базы данных в службе хранилища Azure одновременно. Если ServerA находится в сети с активным файлом базы данных и если ServerB случайно запущен с базой данных, указывающей на тот же файл данных, то второй сервер не сможет запустить базу данных и выдаст код ошибки 5120: Не удается открыть физический файл "%.*ls". Ошибка операционной системы %d: "%ls".

  • В службе хранилища Azure с помощью функции "SQL Server Data Files in Azure" можно хранить только файлы .mdf, .ldf и .ndf.

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

  • Каждый Blob может иметь размер до 1 ТБ. Это создает верхний предел для отдельных данных базы данных и файлов журналов, которые могут храниться в службе хранилища Azure.

  • Невозможно хранить In-Memory данных OLTP в BLOB-объекте Azure с помощью файлов данных SQL Server в службе хранилища Azure. Это связано с тем, что In-Memory OLTP имеет зависимость FileStream и в текущем выпуске этой функции хранение FileStream данных в службе хранилища Azure не поддерживается.

  • При использовании функции файлов данных SQL Server в Azure SQL Server выполняет все сравнения URL-адресов или пути к файлам с использованием набора сортировки в master базе данных.

  • AlwaysOn Availability Groups поддерживается до тех пор, пока в основную базу данных не добавляются новые файлы базы данных. Если для операции базы данных требуется создать новый файл в базе данных-источнике, сначала отключите группы доступности AlwaysOn на вторичном узле. Затем выполните операцию базы данных в базе данных-источнике и создайте резервную копию базы данных на первичном узле. Затем восстановите базу данных на дополнительный узел и включите группы доступности AlwaysOn на вторичном узле. Обратите внимание, что экземпляры отказоустойчивого кластера AlwaysOn не поддерживаются при использовании функции «Файлы данных SQL Server в Azure».

  • Во время обычной работы SQL Server использует временные закрепления для резервирования Blob-хранилищ, продлевая аренду каждого Blob каждые 45–60 секунд. Если сервер аварийно завершает работу, а другой экземпляр SQL Server настроен на использование тех же BLOB-объектов, новый экземпляр будет ожидать до 60 секунд до окончания арендной записи на BLOB. Если вы хотите подключить базу данных к другому экземпляру и не можете ждать, пока срок действия аренды истечет в течение 60 секунд, вы можете явно разорвать аренду на Blob, чтобы избежать сбоев в операциях подключения.

Поддержка средств и справочников по программированию

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

Поддержка PowerShell

В SQL Server 2014 можно использовать командлеты PowerShell для хранения файлов данных SQL Server в службе хранилища BLOB-объектов Azure, ссылаясь на URL-адрес хранилища BLOB-объектов вместо пути к файлу. Вы можете получить доступ к BLOB-объектам, используя следующий формат URL-адреса: http://storageaccount.blob.core.windows.net/<container>/<blob>.

Поддержка счетчиков объектов и производительности SQL Server

Начиная с SQL Server 2014, добавлен новый объект SQL Server для использования с файлами данных SQL Server в службе хранилища Azure. Новый объект SQL Server называется SQL Server, HTTP_STORAGE_OBJECT и может использоваться системным монитором для мониторинга действий при запуске SQL Server с хранилищем Azure.

Поддержка SQL Server Management Studio

SQL Server Management Studio позволяет использовать эту функцию через несколько диалоговых окон. Например, можно ввести путь URL-адреса контейнера хранилища, такой как https://teststorageaccnt.blob.core.windows.net/testcontainer/, в качестве Пути в нескольких диалоговых окнах, таких как Создать базу данных, Присоединить базу данных и Восстановить базу данных. Дополнительные сведения см. в руководстве по файлам данных SQL Server в службе хранилища Azure.

Поддержка объектов управления SQL Server

При использовании файлов данных SQL Server в Azure поддерживаются все объекты управления SQL Server (SMO). Если для объекта SMO требуется путь к файлу, используйте формат URL-адреса BLOB вместо локального пути к файлу, например https://teststorageaccnt.blob.core.windows.net/testcontainer/. Дополнительные сведения о объектах управления SQL Server (SMO) см. в руководстве по программированию объектов управления SQL Server (SMO) в электронной документации по SQL Server.

поддержка Transact-SQL

Эта новая функция представила следующее изменение в области поверхности Transact-SQL:

  • Новый столбец типа intcredential_id в системном представлении sys.master_files. Столбец credential_id используется для того, чтобы обеспечить возможность перекрестной ссылки файлов данных с поддержкой хранилища Azure обратно на учетные данные sys.credentials, созданные для них. Его можно использовать для устранения неполадок, например, если учетные данные не могут быть удалены из-за существования файла базы данных, который их использует.

Устранение неполадок для файлов данных SQL Server в Azure

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

Ниже приведен список ошибок, которые могут возникнуть при использовании файлов данных SQL Server в службе хранилища Azure.

Ошибки проверки подлинности

  • Не удается удалить учетные данные "%.*ls", так как он используется активным файлом базы данных.
    Решение. Эта ошибка может возникать при попытке удалить учетные данные, которые по-прежнему используются активным файлом базы данных в службе хранилища Azure. Чтобы удалить учетные данные, сначала необходимо удалить связанный двоичный объект (BLOB), который содержит этот файл базы данных. Чтобы удалить большой двоичный объект с активной арендой, необходимо сначала разорвать аренду.

  • Подпись общего доступа не была создана в контейнере правильно.
    Решение: Убедитесь, что вы правильно создали общий подписанный URL-адрес для контейнера. Ознакомьтесь с инструкциями, приведенными на занятии 2, в руководстве. Файлы данных SQL Server в службе хранилища Azure.

  • Учетные данные SQL Server были созданы неправильно.
    Убедитесь, что вы использовали "подпись общего доступа" для поля удостоверения и правильно создали секрет. Ознакомьтесь с инструкциями, приведенными на занятии 3, в руководстве. Файлы данных SQL Server в службе хранилища Azure.

Ошибки BLOB-аренды:

  • Ошибка при попытке запустить SQL Server после сбоя другого экземпляра, использующего те же blob-файлы. Решение проблемы: Во время нормальной работы SQL Server использует временные права аренды для резервирования объектов BLOB для хранения, с продлением права аренды каждого объекта BLOB каждые 45–60 секунд. Если сервер завершает работу, а другой экземпляр SQL Server настроен на использование тех же больших двоичных объектов, новый экземпляр ожидает до 60 секунд до истечения срока действия существующей аренды большого двоичного объекта. Если вы хотите подключить базу данных к другому экземпляру и не можете ждать, пока срок аренды истечет в течение 60 секунд, вы можете явно разорвать аренду на блобе, чтобы избежать любых сбоев при выполнении операций подключения.

Ошибки базы данных

  1. Ошибки при создании базы данных
    Решение. Ознакомьтесь с инструкциями, приведенными на занятии 4, в руководстве. Файлы данных SQL Server в службе хранилища Azure.

  2. Ошибки при запуске инструкции Alter
    Убедитесь, что выполняете команду Alter Database, когда база данных находится в сети. При копировании файлов данных в Azure Storage всегда создавайте страничный blob, а не блочный blob. В противном случае команда ALTER DATABASE завершится неудачей. Ознакомьтесь с инструкциями, приведенными на занятии 7 в руководстве по файлам данных SQL Server в службе хранилища Azure.

  3. Код ошибки 5120 Не удается открыть физический файл%.*ls. Ошибка операционной системы %d: "%ls"
    Решение. В настоящее время это новое улучшение не поддерживает более одного экземпляра SQL Server, обращаюющегося к тем же файлам базы данных в службе хранилища Azure одновременно. Если ServerA находится в сети с активным файлом базы данных и если ServerB случайно запущен и его база данных указывает на этот же файл данных, второй сервер не сможет запустить базу данных, получив код ошибки 5120: Не удается открыть физический файл "%.*ls". Ошибка операционной системы %d: "%ls".

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

    1. Задайте путь к файлу сервера A в локальную папку с помощью инструкции ALTER Database.

    2. Установите базу данных в автономном режиме на сервере A.

    3. Затем скопируйте файлы базы данных из службы хранилища Azure в локальную папку на сервере A. Это гарантирует, что ServerA по-прежнему имеет копию базы данных локально.

    4. Задайте базу данных в сети.

См. также

Руководство: Файлы данных SQL Server в облаке Azure

  • Last updated on