Часто задаваемые вопросы о службе 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 Data Studio с расширением миграции SQL, поддерживаются источники SQL Server 2008 по SQL Server 2022.

При использовании 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 перенесены все данные из исходной базы данных в целевые объекты SQL Azure?

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

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

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

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

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 (классической) с помощью 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). Пошаговые инструкции по переносу ключей TDE см. в руководстве по переносу баз данных с поддержкой TDE (предварительная версия) в SQL Azure в Azure Data Studio.

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

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

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

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

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

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

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

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

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

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

Настройка

Каковы предварительные требования для использования 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. См. дополнительные сведения о фильтрации трафика, предназначенного для виртуальной сети, с помощью групп безопасности сети.
• При использовании устройства брандмауэра перед исходными базами данных может потребоваться добавить правила брандмауэра, чтобы разрешить 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. Оцените исходные базы данных.
   • Для однородных миграций оцените существующие базы данных с помощью расширения миграции SQL Azure для Azure Data Studio.
   • Для разнородных миграций (из конкурирующих источников) оцените существующие базы данных с помощью 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 (классический):

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

Для DMS:

• Если вы копируете резервные копии из локального файлового ресурса в хранилище BLOB-объектов Azure или выполняете миграцию в целевую базу данных SQL Azure, 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 Data Studio с расширением миграции SQL, поддерживаются источники SQL Server 2008 по SQL Server 2022.

Вы можете использовать службу 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 и управляемый экземпляр SQL Azure время простоя начинается после запуска миграции наряду с остановкой приложения. DMS восстанавливает все файлы резервной копии в целевой объект, если последняя версия файла резервного копирования из источника была передана в сетевое хранилище SMB или в контейнер BLOB-объектов Azure (согласно конфигурации миграции). После нажатия кнопки переключения DMS показывает количество ожидающих файлов резервного копирования (если таковые имеются), которые присутствуют в сетевом хранилище SMB или контейнере BLOB-объектов Azure и еще не будут применены или восстановлены на целевом объекте. Если резервная копия выполняется с параметром CHECKSUM, операция восстановления DMS автоматически выполняет проверку. При отсутствии контрольной суммы целостность резервной копии явно проверяется перед восстановлением. Это гарантирует, что файл восстановления идентичен файлу резервной копии и, следовательно, имеет одинаковые данные. Вы можете проверить все файлы резервного копирования, включая последнее имя файла резервного копирования из источника, с помощью файла резервного копирования, примененного к целевому объекту, показанного на странице мониторинга миграции DMS, и проверить соответствующую контрольную сумму.

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

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 (классической) с помощью 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). Пошаговые инструкции по переносу ключей TDE см. в руководстве по переносу баз данных с поддержкой TDE (предварительная версия) в SQL Azure в Azure Data Studio.

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

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

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

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

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

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

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

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

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

• Создайте виртуальную сеть Microsoft Azure для Azure Database Migration Service с помощью модели развертывания Azure Resource Manager. Она обеспечивает подключение "сеть — сеть" к локальным исходным серверам через ExpressRoute или VPN.
• Убедитесь, что правила группы безопасности сети виртуальной сети не блокируют порт 443 для serviceTags ServiceBus, storage и AzureMonitor. См. дополнительные сведения о фильтрации трафика, предназначенного для виртуальной сети, с помощью групп безопасности сети.
• При использовании устройства брандмауэра перед исходными базами данных может потребоваться добавить правила брандмауэра, чтобы разрешить 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. Оцените исходные базы данных.
   • Для однородных миграций оцените существующие базы данных с помощью расширения миграции SQL Azure для Azure Data Studio.
   • Для разнородных миграций (из конкурирующих источников) оцените существующие базы данных с помощью 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 (классический):

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

Для DMS:

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

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

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