Часто задаваемые вопросы о службе Azure Database Migration Service

В этой статье приведены часто задаваемые вопросы об использовании службы Azure Database Migration Service вместе с соответствующими ответами.

Обзор

Что такое служба Azure Database Migration Service?

Azure Database Migration Service — это полностью управляемая служба, которая выполняет непрерывную миграцию из множества источников баз данных на платформы данных Azure с минимальным временем простоя. Эта служба сейчас предоставляется в режиме общедоступной версии. Основное внимание уделяется оптимизации следующих возможностей:

• надежность и производительность;
• итеративное добавление пар исходного и целевого объектов;
• Продолжение инвестиций в беспрепятственную миграцию.

Какие пары источника и целевого объекта поддерживают Azure Database Migration Service в настоящее время?

В настоящее время служба поддерживает различные пары источника и целевого объекта или сценарии миграции. Полный список состояний всех доступных сценариев миграции см. в статье Состояние сценариев миграции, поддерживаемых службой Azure Database Migration Service.

Какие версии SQL Server поддерживают Azure Database Migration Service в качестве источника?

При миграции с SQL Server поддерживаемые источники для Azure Database Migration Service: SQL Server 2008 и новее версии.

При использовании Azure Database Migration Service, в чем различия между автономной и онлайн-миграцией?

Вы можете использовать службу Azure Database Migration Service для автономной миграции или миграции по сети. При автономной миграции простой приложения начинается с момента начала переноса. При использовании онлайн-миграции простой ограничен только временем переключения в конце переноса. Мы рекомендуем выполнить тестирование автономной миграции, чтобы определить, допустим ли простой, и, если нет, выполнить миграцию с подключением к сети.

Примечание.

Чтобы выполнить онлайн-миграцию с помощью Azure Database Migration Service, необходимо создать экземпляр в тарифной категории "Премиум". Дополнительные сведения см. на странице с ценами на Azure Database Migration Service.

Как Azure Database Migration Service сравнивается с другими средствами миграции баз данных Майкрософт, такими как помощник по миграции SQL Server (SSMA)?

Служба Azure Database Migration Service является предпочтительным методом переноса базы данных в Microsoft Azure в нужном масштабе. Дополнительные сведения о сравнении Azure Database Migration Service с другими средствами миграции баз данных Майкрософт и рекомендациями по использованию службы для различных сценариев см. в разделе "Различные средства миграции баз данных Майкрософт и службы".

Как Azure Database Migration Service сравнивается с услугой Миграция Azure?

Служба "Миграция Azure" помогает выполнять миграцию локальных виртуальных машин в Azure IaaS. Оценивается пригодность для миграции, показатели производительности, на основе которых определяется требуемый размер, и расходы на работу локальных виртуальных машин в Azure. Служба "Миграция Azure" полезна для переноса рабочих нагрузок с локальных виртуальных машин на виртуальные машины IaaS Azure методом lift-and-shift. Однако, в отличие от службы Azure Database Migration Service, Миграция Azure не является специализированной службой для миграции баз данных на платформы реляционных баз данных Azure PaaS, такие как База данных SQL Azure или Управляемый экземпляр SQL Azure.

Хранят ли данные клиента Database Migration Service?

№ Database Migration Service не хранит данные клиента.

Как убедиться, что Служба управления данными (DMS) выполнила миграцию всех данных из исходной базы данных в целевые базы данных Azure SQL?

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

• Автономная миграция: во время автономной миграции на SQL Server на виртуальной машине Azure и целевых объектах Управляемого экземпляра SQL Azure время простоя приложения начинается при запуске миграции. DMS восстанавливает все файлы резервной копии в целевой объект, если последняя версия файла резервного копирования из источника была передана в сетевое хранилище SMB или в контейнер BLOB-объектов Azure (согласно конфигурации миграции). Если резервная копия выполняется с параметром CHECKSUM, операция восстановления DMS автоматически выполняет проверку. При отсутствии контрольной суммы целостность резервной копии явно проверяется перед восстановлением. Это гарантирует, что файл восстановления идентичен файлу резервной копии и, следовательно, имеет одинаковые данные. Вы можете проверить все файлы резервного копирования, включая имя последнего файла из исходного резервного копирования, используя примененные или восстановленные файлы резервной копии на целевом устройстве, отображаемом на странице мониторинга миграции DMS, и затем проверить их соответствующие контрольные суммы.

• Миграция в режиме онлайн: Во время миграции в режиме онлайн на виртуальную машину в Azure и управляемый экземпляр Azure SQL, время простоя начинается с момента, когда вы инициируете завершение миграции и останавливаете приложение. DMS восстанавливает все файлы резервной копии в целевой объект, если последняя версия файла резервного копирования из источника была передана в сетевое хранилище SMB или в контейнер BLOB-объектов Azure (согласно конфигурации миграции). После нажатия кнопки переключения DMS показывает количество необработанных файлов резервного копирования (если таковые имеются), которые присутствуют в сетевом хранилище SMB или контейнере Azure Blob и ещё не применены или не восстановлены на целевом объекте. Если резервная копия выполняется с параметром CHECKSUM, операция восстановления DMS автоматически выполняет проверку. При отсутствии контрольной суммы целостность резервной копии явно проверяется перед восстановлением. Это гарантирует, что файл восстановления идентичен файлу резервной копии и, следовательно, имеет одинаковые данные. Вы можете проверить все резервные копии, включая имя последнего файла из источника, и убедиться, что применённая резервная копия и восстановление на целевом объекте, отображенные на странице мониторинга миграции DMS, соответствуют контрольным суммам.

Для целевых объектов База данных SQL Azure DMS выполняет логическую миграцию. То есть он копирует данные из таблиц исходной базы данных SQL и записывает его в целевые таблицы базы данных SQL Azure. Так как DMS поддерживает только автономную миграцию в базу данных SQL Azure, время простоя приложения начинается при запуске миграции. Вы можете отслеживать и проверять количество строк, считываемых (из исходной таблицы базы данных) и скопированных (записанных в целевую таблицу базы данных SQL Azure) на странице мониторинга миграции. В качестве дополнительного подтверждения можно использовать следующие варианты, чтобы получить контрольную сумму как в исходных, так и в целевых базах данных, а также убедиться, что исходные и восстанавливаемые данные идентичны.

• Для базовой проверки непосредственно в базе данных:

  SELECT CHECKSUM_AGG(CHECKSUM(*)) FROM <table_name>;
  

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

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

Какие службы создаются и используются при создании и запуске экземпляра DMS (классического) ?

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

• Azure Monitor
• Azure ВМ
• Хранилище Azure
• Служебная шина Azure
• Фабрика данных Azure

Как метаданные и клиентские данные извлекаются из источника и записываются в целевой объект?

Внутри DMS поддерживает хранилище метаданных, которое содержит сведения о сетевых расположениях, учетных данных, файлах резервного копирования и выполненных задачах. Учетные данные и выбранные поля, такие как ключи учетной записи, шифруются. Данные, такие как имена таблиц, которые могут быть включены в телеметрию, хэшируются. Имена пользователей могут отображаться в виде обычного текста в журналах служб, но пароли никогда не будут. Данные телеметрии разложены по регионам, управляются политиками хранения и доступны только авторизованным сотрудникам корпорации Майкрософт в целях устранения неполадок. Имена ресурсов Azure, такие как имена серверов и баз данных, должны соответствовать правилам для ресурсов Azure.

DmS (классическая модель) использует разделы служебной шины Azure для упрощения взаимодействия между вычислительными слоями. Темы Служебной шины Azure уникальны для каждого экземпляра DMS, и все персональные данные шифруются.

Управляемый экземпляр SQL Azure и SQL Server на виртуальных машинах Azure

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

База данных SQL Azure

Миграция в База данных SQL Azure выполняется двумя шагами. Первым шагом является миграция схемы. DMS (классическая модель) использует объекты управления SQL (SMO) для миграции схемы. Второй шаг — это фактическая миграция данных. SqlBulkCopy используется для переноса данных. DMS не поддерживает миграцию схемы. Данные переносятся с помощью Фабрика данных Azure. Опционально, но настоятельно рекомендуется использовать файл, содержащий данные о производительности Windows, чтобы предоставить рекомендации по размеру рабочей нагрузки.

База данных Azure для PostgreSQL

В этом сценарии конечный пользователь извлекает метаданные, в данном случае схему, с помощью служебных программ командной строки pg_dump и pg_restore. При настройке отслеживания изменений данных для PostgreSQL DMS внутренне использует pg_dump и pg_restore, чтобы выполнить начальное засеяние для CDC. Данные хранятся в зашифрованном временном хранилище, доступном только экземпляру DMS. Файл, содержащий данные о производительности Windows, может использоваться для предоставления необязательных (но настоятельно рекомендуемых) рекомендаций по размеру рабочей нагрузки.

База данных Azure для MySQL

В этом сценарии извлечение схемы и миграция выполняются с помощью DMS (classic) и mysql-net/MySqlConnector. По возможности репликация двоичных журналов MySQL используется для репликации изменений данных и схем. Пользовательский код используется для синхронизации изменений, в которых репликация binlog не может использоваться.

Из MongoDB в Azure Cosmos DB

DMS извлекает и вставляет данные из MongoDB в Cosmos DB. Он также предлагает возможность извлечь данные из дампа BSON или JSON.

Для дампов BSON сервис DMS использует данные в формате bsondump в одной и той же папке внутри контейнера BLOB. DMS ищет только файлы метаданных с помощью формата collection.metadata.json.

Для дампов JSON DMS считывает файлы в папках контейнеров BLOB-объектов с именем содержащихся баз данных. В каждой папке базы данных DMS использует только файлы данных, помещенные в вложенную папку data . DMS проверяет только файлы, помещенные в metadata вложенную папку, имена которых соответствуют формату collection.json для метаданных.

Oracle для базы данных Azure для PostgreSQL

Как и Oracle для базы данных SQL Azure, в этом сценарии отчет AWR или файл Windows perfmon используется для предоставления опциональных (но настоятельно рекомендуемых) рекомендаций по размеру рабочей нагрузки. Библиотека ora2pg используется для извлечения схемы и переноса данных вручную пользователем, выполняющим миграцию.

Используются ли общедоступные конечные точки?

DMS (классическая модель) зависит от конфигурации сети клиента. Если источник миграции использует частные конечные точки, мы используем частные конечные точки, что является предпочтительной конфигурацией. Мы используем общедоступные конечные точки, если они единственные.

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

Шифруются ли все данные при передаче и хранении?

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

Все передаваемые данные защищены с помощью шифрования TLS 1.2 по умолчанию. Устаревшие клиенты, требующие более старых версий TLS, нуждаются в необходимых версиях, включенных на странице портала DMS (классическая версия). Для DMS компьютер, на котором установлена локальная среда выполнения интеграции, можно настроить, чтобы разрешить необходимые параметры TLS для размещения устаревших клиентов. Дополнительные сведения о конфигурации TLS для SQL Server см. в статье о поддержке TLS 1.2 для Microsoft SQL Server.

Используют ли все службы Azure, которые лежат в основе DMS и DMS (классические) частные конечные точки?

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

Используются ли все службы Azure, которые лежат в основе DMS и DMS (классическая модель) для неактивных данных?

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

Какой тип шифрования используется для передаваемых данных?

Все данные при передаче шифруются с помощью шифрования TLS 1.2 по умолчанию. Страница портала DMS (классическая) позволяет использовать старые версии TLS для устаревших клиентов. Для DMS компьютер, на котором установлена локальная среда выполнения интеграции, можно настроить, чтобы разрешить управление параметрами TLS для размещения устаревших клиентов. Дополнительные сведения о конфигурации TLS для SQL Server см. в статье о поддержке TLS 1.2 для Microsoft SQL Server.

Есть ли какие-либо данные, которые не защищены CMK, и какой тип данных? Например, метаданные, журналы и т. д.

Мы не предоставляем возможность использовать управляемые клиентами ключи для шифрования данных на уровне управления или передачи. Все данные клиента удаляются при удалении экземпляра DMS, кроме журналов служб. Журналы служб DMS хранятся только в течение 6 месяцев.

Как DMS поддерживает управляемые клиентом ключи (CMK)?

TDE

DMS поддерживает миграцию управляемых клиентом ключей (CMK) в SQL Azure для прозрачного шифрования баз данных (TDE).

Шифрование ячеек

Шифрование уровня ячеек обрабатывается на уровне схемы. Средства миграции схемы переносят все объекты схемы, включая функции и хранимые процедуры, необходимые для реализации шифрования на уровне ячеек.

Всегда зашифровано

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

Гарантирует ли DMS, что доступ к данным контролируется с помощью контроль доступа Location Aware?

Мы не реализуем никакого контроля доступа, учитываемого расположением, за пределами того, что уже доступно в Azure. Все данные, связанные с экземпляром DMS, находятся в том же регионе, что и ресурс DMS.

Как DMS гарантирует, что данные в одной среде нельзя переместить в другую с помощью DMS?

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

Как используется внедрение виртуальной сети в DMS (классическая версия) Предоставляет ли корпорация Майкрософт доступ к моей сети?

Инъекция виртуальной сети — это процесс добавления ресурса Azure, который находится в тенанте Microsoft, в подсеть виртуальной сети в тенанте клиента. Этот подход был принят с DMS, чтобы позволить нам управлять вычислительными ресурсами от имени клиента, сохраняя доступ к ресурсам клиентов. Так как сеть находится в подписке клиента, Microsoft не может управлять виртуальной машиной, за исключением выдачи команд "Запустить", "Остановить", "Удалить" или "Развернуть". Все остальные действия управления, требующие доступа к виртуальной машине, требуют запроса на поддержку и его утверждения, инициированных клиентом.

Настройка

Каковы предварительные требования для использования Azure Database Migration Service?

Есть несколько предварительных требований, которые необходимо выполнить, чтобы служба Azure Database Migration Service работала без проблем при переносе баз данных. Одни предварительные требования применяются во всех сценариях (с парами исходного и целевого объектов), поддерживаемых службой, другие уникальны и используются в определенных сценариях.

Ниже приведены предварительные требования для использования службы Azure Database Migration Service, которые применяются во всех поддерживаемых сценариях миграции.

• Создайте виртуальную сеть Microsoft Azure для Azure Database Migration Service с помощью модели развертывания Azure Resource Manager. Она обеспечивает подключение "сеть — сеть" к локальным исходным серверам через ExpressRoute или VPN.
• Убедитесь, что правила группы безопасности виртуальной сети не блокируют порт 443 для ServiceTags ServiceBus, Storage и AzureMonitor. Для получения дополнительной информации о фильтрации трафика NSG для виртуальных сетей, см. статью Фильтрация сетевого трафика с помощью групп безопасности сети.
• При использовании устройства брандмауэра перед исходными базами данных может потребоваться добавить правила брандмауэра, чтобы разрешить Azure Database Migration Service получить доступ к исходным базам данных для миграции.

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

Как найти IP-адрес для Azure Database Migration Service, чтобы создать список разрешений для правил брандмауэра, используемых для доступа к исходной базе данных для миграции?

Возможно, потребуется добавить правила брандмауэра, позволяющие Azure Database Migration Service получить доступ к исходной базе данных для миграции. IP-адрес для этой службы является динамическим, однако при использовании ExpressRoute этот адрес будет в закрытом порядке назначен корпоративной сети. Самый простой способ определить соответствующий IP-адрес — перейти в ту же группу ресурсов, в которой подготовлен ресурс службы Azure Database Migration Service, чтобы найти связанный сетевой интерфейс. Обычно имя ресурса сетевого интерфейса начинается с префикса сетевого адаптера, за которым следует уникальный символ и последовательность чисел, например NIC-jj6tnztnmarpsskr82rbndyp. Выбрав этот ресурс сетевого интерфейса, вы увидите IP-адрес, который необходимо включить в список разрешений на странице обзора ресурсов Azure портале.

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

SELECT DISTINCT
    local_tcp_port
FROM sys.dm_exec_connections
WHERE local_tcp_port IS NOT NULL;

Вы также можете определить порт, который SQL Server прослушивает, запросив журнал ошибок SQL Server:

USE master;
GO
xp_readerrorlog 0, 1, N'Server is listening on';
GO

Как настроить виртуальную сеть Microsoft Azure?

В нескольких руководствах корпорации Майкрософт приведены пошаговые инструкции по настройке виртуальной сети, а официальную документацию можно найти в этой статье.

Использование

Что такое сводка шагов, необходимых для выполнения миграции базы данных с помощью Azure Database Migration Service?

Во время обычного переноса базы данных вы:

1. Создание целевых баз данных.
2. Оцените исходные базы данных с помощью SSMA. SSMA также может преобразовать объекты базы данных и перенести схему на целевую платформу.
3. Создайте экземпляр Azure Database Migration Service.
4. Создайте проект миграции, указывающий исходные базы данных, целевые базы данных и таблицы для миграции.
5. Запускаете полную загрузку.
6. Выбираете последующую проверку.
7. Вручную переключаете рабочую среду на использование новой облачной базы данных.

Устранение неполадок и оптимизация

Я настраиваю проект миграции в DMS, и у меня возникают трудности при подключении к исходной базе данных. Что делать?

Если при подготовке миграции у вас возникли проблемы с подключением к системе базы данных-источника, создайте виртуальную машину в той же подсети виртуальной сети, где настроен экземпляр DMS. На виртуальной машине вы сможете запустить тест подключения, например с помощью файла UDL, чтобы проверить связь с SQL Server, или скачав Robo 3T для проверки подключений MongoDB. Если проверка подключения завершилась успешно, у вас не должно возникнуть проблем с подключением к базе данных-источнику. Если проверка подключения завершилась ошибкой, обратитесь к администратору сети.

Почему моя служба Azure Database Migration Service недоступна или остановлена?

Если пользователь явно останавливает Azure Database Migration Service (DMS) или если служба неактивна в течение 24 часов, служба находится в состоянии остановленной или автоматической приостановки. В каждом случае служба недоступна и в остановленном состоянии. Чтобы возобновить активную миграцию, перезапустите службу.

Есть ли рекомендации по оптимизации производительности Azure Database Migration Service?

Вы можете выполнить ряд действий, чтобы ускорить перенос базы данных с использованием службы:

Для DMS (классическая версия):

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

Для DMS:

• Если вы копируете резервные копии из локального файлового хранилища в Хранилище BLOB-объектов Azure или выполняете миграцию в целевую базу данных Azure SQL, DMS использует в качестве вычислительной мощности узел SHIR. Поэтому следите за использованием ресурсов этого узла SHIR.
• Временно масштабируйте целевой экземпляр базы данных SQL Azure до SKU уровня "Премиум" во время операции миграции данных, чтобы свести к минимуму ограничение дисков базы данных SQL Azure, которое может повлиять на операции передачи данных при использовании SKU более низкого уровня.
• Дополнительные сведения см. в статье "Улучшение производительности миграции базы данных SQL— Azure Database Migration Service".

Связанный контент

• Что такое Azure Database Migration Service.

В этой статье приведены часто задаваемые вопросы об использовании службы Azure Database Migration Service вместе с соответствующими ответами.

Azure Database Migration Service — это полностью управляемая служба, которая выполняет непрерывную миграцию из множества источников баз данных на платформы данных Azure с минимальным временем простоя. Эта служба сейчас предоставляется в режиме общедоступной версии. Основное внимание уделяется оптимизации следующих возможностей:

• надежность и производительность;
• итеративное добавление пар исходного и целевого объектов;
• Продолжение инвестиций в беспрепятственную миграцию.

В настоящее время служба поддерживает различные пары источника и целевого объекта или сценарии миграции. Полный список состояний всех доступных сценариев миграции см. в статье Состояние сценариев миграции, поддерживаемых службой Azure Database Migration Service.

При миграции с SQL Server поддерживаемые источники для Azure Database Migration Service: SQL Server 2008 и новее версии.

Вы можете использовать службу Azure Database Migration Service для автономной миграции или миграции по сети. При автономной миграции простой приложения начинается с момента начала переноса. При использовании онлайн-миграции простой ограничен только временем переключения в конце переноса. Мы рекомендуем выполнить тестирование автономной миграции, чтобы определить, допустим ли простой, и, если нет, выполнить миграцию с подключением к сети.

Примечание.

Чтобы выполнить онлайн-миграцию с помощью Azure Database Migration Service, необходимо создать экземпляр в тарифной категории "Премиум". Дополнительные сведения см. на странице с ценами на Azure Database Migration Service.

Служба Azure Database Migration Service является предпочтительным методом переноса базы данных в Microsoft Azure в нужном масштабе. Дополнительные сведения о сравнении Azure Database Migration Service с другими средствами миграции баз данных Майкрософт и рекомендациями по использованию службы для различных сценариев см. в разделе "Различные средства миграции баз данных Майкрософт и службы".

Служба "Миграция Azure" помогает выполнять миграцию локальных виртуальных машин в Azure IaaS. Оценивается пригодность для миграции, показатели производительности, на основе которых определяется требуемый размер, и расходы на работу локальных виртуальных машин в Azure. Служба "Миграция Azure" полезна для переноса рабочих нагрузок с локальных виртуальных машин на виртуальные машины IaaS Azure методом lift-and-shift. Однако, в отличие от службы Azure Database Migration Service, Миграция Azure не является специализированной службой для миграции баз данных на платформы реляционных баз данных Azure PaaS, такие как База данных SQL Azure или Управляемый экземпляр SQL Azure.

№ Database Migration Service не хранит данные клиента.

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

• Автономная миграция: во время автономной миграции на SQL Server на виртуальной машине Azure и целевых объектах Управляемого экземпляра SQL Azure время простоя приложения начинается при запуске миграции. DMS восстанавливает все файлы резервной копии в целевой объект, если последняя версия файла резервного копирования из источника была передана в сетевое хранилище SMB или в контейнер BLOB-объектов Azure (согласно конфигурации миграции). Если резервная копия выполняется с параметром CHECKSUM, операция восстановления DMS автоматически выполняет проверку. При отсутствии контрольной суммы целостность резервной копии явно проверяется перед восстановлением. Это гарантирует, что файл восстановления идентичен файлу резервной копии и, следовательно, имеет одинаковые данные. Вы можете проверить все файлы резервного копирования, включая имя последнего файла из исходного резервного копирования, используя примененные или восстановленные файлы резервной копии на целевом устройстве, отображаемом на странице мониторинга миграции DMS, и затем проверить их соответствующие контрольные суммы.

• Миграция в режиме онлайн: Во время миграции в режиме онлайн на виртуальную машину в Azure и управляемый экземпляр Azure SQL, время простоя начинается с момента, когда вы инициируете завершение миграции и останавливаете приложение. DMS восстанавливает все файлы резервной копии в целевой объект, если последняя версия файла резервного копирования из источника была передана в сетевое хранилище SMB или в контейнер BLOB-объектов Azure (согласно конфигурации миграции). После нажатия кнопки переключения DMS показывает количество необработанных файлов резервного копирования (если таковые имеются), которые присутствуют в сетевом хранилище SMB или контейнере Azure Blob и ещё не применены или не восстановлены на целевом объекте. Если резервная копия выполняется с параметром CHECKSUM, операция восстановления DMS автоматически выполняет проверку. При отсутствии контрольной суммы целостность резервной копии явно проверяется перед восстановлением. Это гарантирует, что файл восстановления идентичен файлу резервной копии и, следовательно, имеет одинаковые данные. Вы можете проверить все резервные копии, включая имя последнего файла из источника, и убедиться, что применённая резервная копия и восстановление на целевом объекте, отображенные на странице мониторинга миграции DMS, соответствуют контрольным суммам.

Для целевых объектов База данных SQL Azure DMS выполняет логическую миграцию. То есть он копирует данные из таблиц исходной базы данных SQL и записывает его в целевые таблицы базы данных SQL Azure. Так как DMS поддерживает только автономную миграцию в базу данных SQL Azure, время простоя приложения начинается при запуске миграции. Вы можете отслеживать и проверять количество строк, считываемых (из исходной таблицы базы данных) и скопированных (записанных в целевую таблицу базы данных SQL Azure) на странице мониторинга миграции. В качестве дополнительного подтверждения можно использовать следующие варианты, чтобы получить контрольную сумму как в исходных, так и в целевых базах данных, а также убедиться, что исходные и восстанавливаемые данные идентичны.

• Для базовой проверки непосредственно в базе данных:

  SELECT CHECKSUM_AGG(CHECKSUM(*)) FROM <table_name>;
  

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

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

• Azure Monitor
• Azure ВМ
• Хранилище Azure
• Служебная шина Azure
• Фабрика данных Azure

Внутри DMS поддерживает хранилище метаданных, которое содержит сведения о сетевых расположениях, учетных данных, файлах резервного копирования и выполненных задачах. Учетные данные и выбранные поля, такие как ключи учетной записи, шифруются. Данные, такие как имена таблиц, которые могут быть включены в телеметрию, хэшируются. Имена пользователей могут отображаться в виде обычного текста в журналах служб, но пароли никогда не будут. Данные телеметрии разложены по регионам, управляются политиками хранения и доступны только авторизованным сотрудникам корпорации Майкрософт в целях устранения неполадок. Имена ресурсов Azure, такие как имена серверов и баз данных, должны соответствовать правилам для ресурсов Azure.

DmS (классическая модель) использует разделы служебной шины Azure для упрощения взаимодействия между вычислительными слоями. Темы Служебной шины Azure уникальны для каждого экземпляра DMS, и все персональные данные шифруются.

Управляемый экземпляр SQL Azure и SQL Server на виртуальных машинах Azure

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

База данных SQL Azure

Миграция в База данных SQL Azure выполняется двумя шагами. Первым шагом является миграция схемы. DMS (классическая модель) использует объекты управления SQL (SMO) для миграции схемы. Второй шаг — это фактическая миграция данных. SqlBulkCopy используется для переноса данных. DMS не поддерживает миграцию схемы. Данные переносятся с помощью Фабрика данных Azure. Опционально, но настоятельно рекомендуется использовать файл, содержащий данные о производительности Windows, чтобы предоставить рекомендации по размеру рабочей нагрузки.

База данных Azure для PostgreSQL

В этом сценарии конечный пользователь извлекает метаданные, в данном случае схему, с помощью служебных программ командной строки pg_dump и pg_restore. При настройке отслеживания изменений данных для PostgreSQL DMS внутренне использует pg_dump и pg_restore, чтобы выполнить начальное засеяние для CDC. Данные хранятся в зашифрованном временном хранилище, доступном только экземпляру DMS. Файл, содержащий данные о производительности Windows, может использоваться для предоставления необязательных (но настоятельно рекомендуемых) рекомендаций по размеру рабочей нагрузки.

База данных Azure для MySQL

В этом сценарии извлечение схемы и миграция выполняются с помощью DMS (classic) и mysql-net/MySqlConnector. По возможности репликация двоичных журналов MySQL используется для репликации изменений данных и схем. Пользовательский код используется для синхронизации изменений, в которых репликация binlog не может использоваться.

Из MongoDB в Azure Cosmos DB

DMS извлекает и вставляет данные из MongoDB в Cosmos DB. Он также предлагает возможность извлечь данные из дампа BSON или JSON.

Для дампов BSON сервис DMS использует данные в формате bsondump в одной и той же папке внутри контейнера BLOB. DMS ищет только файлы метаданных с помощью формата collection.metadata.json.

Для дампов JSON DMS считывает файлы в папках контейнеров BLOB-объектов с именем содержащихся баз данных. В каждой папке базы данных DMS использует только файлы данных, помещенные в вложенную папку data . DMS проверяет только файлы, помещенные в metadata вложенную папку, имена которых соответствуют формату collection.json для метаданных.

Oracle для базы данных Azure для PostgreSQL

Как и Oracle для базы данных SQL Azure, в этом сценарии отчет AWR или файл Windows perfmon используется для предоставления опциональных (но настоятельно рекомендуемых) рекомендаций по размеру рабочей нагрузки. Библиотека ora2pg используется для извлечения схемы и переноса данных вручную пользователем, выполняющим миграцию.

DMS (классическая модель) зависит от конфигурации сети клиента. Если источник миграции использует частные конечные точки, мы используем частные конечные точки, что является предпочтительной конфигурацией. Мы используем общедоступные конечные точки, если они единственные.

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

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

Все передаваемые данные защищены с помощью шифрования TLS 1.2 по умолчанию. Устаревшие клиенты, требующие более старых версий TLS, нуждаются в необходимых версиях, включенных на странице портала DMS (классическая версия). Для DMS компьютер, на котором установлена локальная среда выполнения интеграции, можно настроить, чтобы разрешить необходимые параметры TLS для размещения устаревших клиентов. Дополнительные сведения о конфигурации TLS для SQL Server см. в статье о поддержке TLS 1.2 для Microsoft SQL Server.

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

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

Все данные при передаче шифруются с помощью шифрования TLS 1.2 по умолчанию. Страница портала DMS (классическая) позволяет использовать старые версии TLS для устаревших клиентов. Для DMS компьютер, на котором установлена локальная среда выполнения интеграции, можно настроить, чтобы разрешить управление параметрами TLS для размещения устаревших клиентов. Дополнительные сведения о конфигурации TLS для SQL Server см. в статье о поддержке TLS 1.2 для Microsoft SQL Server.

Мы не предоставляем возможность использовать управляемые клиентами ключи для шифрования данных на уровне управления или передачи. Все данные клиента удаляются при удалении экземпляра DMS, кроме журналов служб. Журналы служб DMS хранятся только в течение 6 месяцев.

TDE

DMS поддерживает миграцию управляемых клиентом ключей (CMK) в SQL Azure для прозрачного шифрования баз данных (TDE).

Шифрование ячеек

Шифрование уровня ячеек обрабатывается на уровне схемы. Средства миграции схемы переносят все объекты схемы, включая функции и хранимые процедуры, необходимые для реализации шифрования на уровне ячеек.

Всегда зашифровано

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

Мы не реализуем никакого контроля доступа, учитываемого расположением, за пределами того, что уже доступно в Azure. Все данные, связанные с экземпляром DMS, находятся в том же регионе, что и ресурс DMS.

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

Инъекция виртуальной сети — это процесс добавления ресурса Azure, который находится в тенанте Microsoft, в подсеть виртуальной сети в тенанте клиента. Этот подход был принят с DMS, чтобы позволить нам управлять вычислительными ресурсами от имени клиента, сохраняя доступ к ресурсам клиентов. Так как сеть находится в подписке клиента, Microsoft не может управлять виртуальной машиной, за исключением выдачи команд "Запустить", "Остановить", "Удалить" или "Развернуть". Все остальные действия управления, требующие доступа к виртуальной машине, требуют запроса на поддержку и его утверждения, инициированных клиентом.

Есть несколько предварительных требований, которые необходимо выполнить, чтобы служба Azure Database Migration Service работала без проблем при переносе баз данных. Одни предварительные требования применяются во всех сценариях (с парами исходного и целевого объектов), поддерживаемых службой, другие уникальны и используются в определенных сценариях.

Ниже приведены предварительные требования для использования службы Azure Database Migration Service, которые применяются во всех поддерживаемых сценариях миграции.

• Создайте виртуальную сеть Microsoft Azure для Azure Database Migration Service с помощью модели развертывания Azure Resource Manager. Она обеспечивает подключение "сеть — сеть" к локальным исходным серверам через ExpressRoute или VPN.
• Убедитесь, что правила группы безопасности виртуальной сети не блокируют порт 443 для ServiceTags ServiceBus, Storage и AzureMonitor. Для получения дополнительной информации о фильтрации трафика NSG для виртуальных сетей, см. статью Фильтрация сетевого трафика с помощью групп безопасности сети.
• При использовании устройства брандмауэра перед исходными базами данных может потребоваться добавить правила брандмауэра, чтобы разрешить Azure Database Migration Service получить доступ к исходным базам данных для миграции.

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

Возможно, потребуется добавить правила брандмауэра, позволяющие Azure Database Migration Service получить доступ к исходной базе данных для миграции. IP-адрес для этой службы является динамическим, однако при использовании ExpressRoute этот адрес будет в закрытом порядке назначен корпоративной сети. Самый простой способ определить соответствующий IP-адрес — перейти в ту же группу ресурсов, в которой подготовлен ресурс службы Azure Database Migration Service, чтобы найти связанный сетевой интерфейс. Обычно имя ресурса сетевого интерфейса начинается с префикса сетевого адаптера, за которым следует уникальный символ и последовательность чисел, например NIC-jj6tnztnmarpsskr82rbndyp. Выбрав этот ресурс сетевого интерфейса, вы увидите IP-адрес, который необходимо включить в список разрешений на странице обзора ресурсов Azure портале.

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

SELECT DISTINCT
    local_tcp_port
FROM sys.dm_exec_connections
WHERE local_tcp_port IS NOT NULL;

Вы также можете определить порт, который SQL Server прослушивает, запросив журнал ошибок SQL Server:

USE master;
GO
xp_readerrorlog 0, 1, N'Server is listening on';
GO

В нескольких руководствах корпорации Майкрософт приведены пошаговые инструкции по настройке виртуальной сети, а официальную документацию можно найти в этой статье.

Во время обычного переноса базы данных вы:

1. Создание целевых баз данных.
2. Оцените исходные базы данных с помощью SSMA. SSMA также может преобразовать объекты базы данных и перенести схему на целевую платформу.
3. Создайте экземпляр Azure Database Migration Service.
4. Создайте проект миграции, указывающий исходные базы данных, целевые базы данных и таблицы для миграции.
5. Запускаете полную загрузку.
6. Выбираете последующую проверку.
7. Вручную переключаете рабочую среду на использование новой облачной базы данных.

Если при подготовке миграции у вас возникли проблемы с подключением к системе базы данных-источника, создайте виртуальную машину в той же подсети виртуальной сети, где настроен экземпляр DMS. На виртуальной машине вы сможете запустить тест подключения, например с помощью файла UDL, чтобы проверить связь с SQL Server, или скачав Robo 3T для проверки подключений MongoDB. Если проверка подключения завершилась успешно, у вас не должно возникнуть проблем с подключением к базе данных-источнику. Если проверка подключения завершилась ошибкой, обратитесь к администратору сети.

Если пользователь явно останавливает Azure Database Migration Service (DMS) или если служба неактивна в течение 24 часов, служба находится в состоянии остановленной или автоматической приостановки. В каждом случае служба недоступна и в остановленном состоянии. Чтобы возобновить активную миграцию, перезапустите службу.

Вы можете выполнить ряд действий, чтобы ускорить перенос базы данных с использованием службы:

Для DMS (классическая версия):

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

Для DMS:

• Если вы копируете резервные копии из локального файлового хранилища в Хранилище BLOB-объектов Azure или выполняете миграцию в целевую базу данных Azure SQL, DMS использует в качестве вычислительной мощности узел SHIR. Поэтому следите за использованием ресурсов этого узла SHIR.
• Временно масштабируйте целевой экземпляр базы данных SQL Azure до SKU уровня "Премиум" во время операции миграции данных, чтобы свести к минимуму ограничение дисков базы данных SQL Azure, которое может повлиять на операции передачи данных при использовании SKU более низкого уровня.
• Дополнительные сведения см. в статье "Улучшение производительности миграции базы данных SQL— Azure Database Migration Service".

Связанный контент

• Что такое Azure Database Migration Service.