Бөлісу құралы:

Подготовка к миграции тестового запуска

  • Мақала

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

Схема выделенного этапа подготовки к тестовой стадии выполнения семи этапов миграции.

Необходимые компоненты

Завершите этап проверки перед началом подготовки к миграции тестового запуска.

Создание параметров миграции

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

  1. Выполните команду подготовки средства миграции данных со следующими параметрами:

    /collection:http://localhost:8080/tfs/DefaultCollection/ tenantDomainName:contoso.com /Region:CUS

    • Параметр доменного имени клиента — это имя клиента Microsoft Entra ID вашей компании.
    • Для команды подготовки требуется доступ к Интернету. Если сервер Azure DevOps не имеет подключения к Интернету, выполните команду с другого компьютера.
    • Термин "регион организации" относится к расположению, в котором планируется перенести коллекцию в Azure DevOps Services. Вы ранее выбрали регион и записали его сокращенный код. Используйте этот код в команде подготовки.

  2. Войдите с помощью пользователя из клиента, у которого есть разрешение на чтение сведений обо всех пользователях в клиенте Идентификатора Microsoft Entra ID.

Настройка файла спецификации миграции

Файл спецификации миграции — это JSON-файл, который указывает средству миграции данных, как выполнить следующие действия.

  • Настройка перенесенной организации
  • Указание исходных расположений
  • Настройка миграции

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

  • Название организации: имя организации, которую вы хотите создать для переноса данных.
  • Расположение. Резервное копирование базы данных и файлов миграции для отправки в контейнер хранилища Azure. Это поле указывает ключ SAS, используемый средством миграции для безопасного подключения и чтения исходных файлов из контейнера хранилища Azure. Создание контейнера хранилища рассматривается далее на этапе 5 и создание ключа SAS рассматривается на этапе 6 перед очередью для новой миграции.
  • DACPAC: файл, который упаковывает базу данных SQL коллекции.
  • Тип миграции: тип миграции: тестовое выполнение или выполнение рабочей среды.

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

Просмотр файла журнала карты удостоверений

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

Примечание.

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

Активные удостоверения

Активные удостоверения ссылаются на удостоверения пользователей в Azure DevOps Services после миграции. В Azure DevOps Services эти удостоверения лицензируются и отображаются как пользователи в организации. Удостоверения помечены как активные в столбце "Ожидаемый импорт состояния " в файле журнала карты удостоверений.

Исторические удостоверения

Исторические удостоверения сопоставляются как таковые в столбце "Ожидаемый импорт состояния" в файле журнала карты удостоверений. Удостоверения без записи строки в файле также становятся историческими. Пример удостоверения без записи строки может быть сотрудником, который больше не работает в компании.

В отличие от активных удостоверений, исторические удостоверения:

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

Примечание.

После миграции удостоверения в виде журнала его невозможно сделать активным.

Лицензии

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

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

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

Подписки Azure DevOps

Подписки Visual Studio не назначаются по умолчанию для миграций. Вместо этого пользователи с Подписки Visual Studio автоматически обновляются для использования этой лицензии. Если рабочая организация пользователя связана правильно, Azure DevOps Services автоматически применяет преимущества подписки Visual Studio при первом входе после миграции.

Вам не нужно повторять тестовую миграцию, если пользователи не обновляются автоматически, чтобы использовать свою подписку Visual Studio в Azure DevOps Services. Связывание подписок Visual Studio — это то, что происходит вне области миграции. Если рабочая организация правильно связана до или после миграции, пользователь автоматически обновляет лицензию на следующий вход. После обновления при следующем переходе пользователь автоматически обновляется при первоначальном входе в организацию.

Ограничение доступа только к IP-адресам Azure DevOps Services

Ограничьте доступ к учетной записи служба хранилища Azure только ip-адресам из Azure DevOps Services. Вы можете ограничить доступ, разрешая подключения только из IP-адресов Azure DevOps Services, участвующих в процессе миграции базы данных коллекции. IP-адреса, которым необходимо предоставить доступ к учетной записи хранения, зависят от региона, в который вы переноситесь.

Вариант 1. Использование тегов службы

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

Вариант 2. Использование списка IP-адресов

IpList Используйте команду, чтобы получить список IP-адресов, которым необходимо предоставить доступ, чтобы разрешить подключения из определенного региона Azure DevOps Services.

В документации по справке приведены инструкции и примеры запуска миграции из самого экземпляра Azure DevOps Server и удаленного компьютера. Если вы выполняете команду из одного из уровней приложений экземпляра Azure DevOps Server, ваша команда должна иметь следующую структуру:

Migrator IpList /collection:{CollectionURI} /tenantDomainName:{name} /region:{region}

Список IP-адресов можно добавить в группы безопасности сети или брандмауэры с помощью портала или программно.

Настройка исключений брандмауэра IP для SQL Azure

Этот раздел относится только к настройке исключений брандмауэра для SQL Azure. Сведения о миграции DACPAC см. в разделе "Настройка служба хранилища Azure брандмауэров и виртуальных сетей".

Для средства миграции данных требуется, чтобы IP-адреса Azure DevOps Services настраивались только для входящих подключений через порт 1433.

Выполните следующие действия, чтобы предоставить исключения для необходимых IP-адресов, обрабатываемых на сетевом уровне Azure для виртуальной машины SQL Azure.

  1. Войдите на портал Azure.
  2. Перейдите на виртуальную машину SQL Azure.
  3. В разделе Параметры выберите Сеть.
  4. Выберите Добавить правило входящего порта. Снимок экрана: кнопка
  5. Выберите "Дополнительно ", чтобы настроить правило входящего порта для определенного IP-адреса. Снимок экрана: кнопка
  6. В раскрывающемся списке "Источник" выберите IP-адреса, введите IP-адрес, которому необходимо предоставить исключение, задайте диапазон 1433 портов назначения и в поле "Имя" введите имя, которое лучше всего описывает настраиваемое исключение.

В зависимости от других настроенных правил входящего порта может потребоваться изменить приоритет по умолчанию для исключений Azure DevOps Services, поэтому они не игнорируются. Например, если у вас есть правило "запретить все входящие подключения к 1433" с более высоким приоритетом, чем исключения Azure DevOps Services, средство миграции данных может оказаться не в состоянии сделать успешное подключение к базе данных.

Снимок экрана: завершенная конфигурация правила входящего порта.

Повторите добавление правил входящего порта до тех пор, пока не будут предоставлены все необходимые IP-адреса Служб Azure DevOps Services. Отсутствие одного IP-адреса может привести к сбою запуска миграции.

Перенос больших коллекций

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

Определите, можно ли уменьшить размер коллекции.

Проверьте, можно ли очистить старые данные. Со временем коллекции могут создавать большие объемы данных. Этот рост является естественной частью процесса DevOps, но вы можете найти, что вам не нужно хранить все данные. Некоторые распространенные примеры устаревших данных являются старыми рабочими областями и результатами сборки.

Средство миграции данных сканирует коллекцию и сравнивает ее с ограничениями, упомянутыми ранее. Затем он сообщает о том, подходит ли ваша коллекция для метода DACPAC или SQL migration. Как правило, идея заключается в том, что если ваша коллекция достаточно мала, чтобы соответствовать ограничениям DACPAC, вы можете использовать более быстрый и простой подход DACPAC. Однако если коллекция слишком велика, необходимо использовать метод миграции SQL, который включает настройку виртуальной машины SQL Azure и перенос базы данных вручную.

Ограничения размера

Сейчас действуют такие ограничения:

  • 150 ГБ общего размера базы данных (метаданные и большие двоичные объекты базы данных) для DACPAC, если превышено это ограничение, необходимо выполнить метод миграции SQL.
  • 30 ГБ отдельного размера таблицы (метаданные базы данных и большие двоичные объекты) для DACPAC, если любая отдельная таблица превышает это ограничение, необходимо выполнить метод миграции SQL.
  • Размер метаданных базы данных 1536 ГБ для метода миграции SQL. Превышение этого ограничения выдает предупреждение, мы советуем сохранить этот размер для успешной миграции.
  • Размер метаданных базы данных размером 2048 ГБ для метода миграции SQL. Превышение этого ограничения приводит к ошибке, поэтому невозможно выполнить миграцию.
  • Нет ограничений для размеров БОЛЬШИХ двоичных объектов для метода миграции SQL.

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

Внимание

После удаления старых данных его нельзя восстановить, если вы не восстановите старую резервную копию коллекции.

Если вы находитесь под пороговым значением DACPAC, следуйте инструкциям по созданию DACPAC для миграции. Если база данных по-прежнему не удается получить под пороговым значением DACPAC, необходимо настроить виртуальную машину SQL Azure для миграции в Azure DevOps Services.

Настройка виртуальной машины SQL Azure для миграции в Azure DevOps Services

Выполните следующие высокоуровневые действия, чтобы настроить виртуальную машину SQL Azure для миграции в Azure DevOps Services.

  1. Настройка виртуальной машины SQL Azure
  2. Настройка исключений брандмауэра IP
  3. Восстановление базы данных на виртуальной машине
  4. [Настройка коллекции для миграции
  5. Настройка файла спецификации миграции для целевой виртуальной машины

Настройка виртуальной машины SQL Azure

Вы можете быстро настроить виртуальную машину SQL Azure из портал Azure. Дополнительные сведения см. в статье "Использование портал Azure для подготовки виртуальной машины Windows с помощью SQL Server".

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

  • Выберите размер виртуальной машины на уровне D8s_v5_* или больше.
  • Использовать управляемые диски.
  • Ознакомьтесь с производительностью виртуальной машины и диска. Убедитесь, что инфраструктура настроена таким образом, чтобы операции ввода-вывода в секунду (входные и выходные данные) и операции ввода-вывода в хранилище не стали узким местом для производительности миграции. Например, убедитесь, что количество дисков данных, подключенных к виртуальной машине, достаточно для поддержки операций ввода-вывода в секунду из виртуальной машины.

Azure DevOps Services доступна в нескольких регионах Azure по всему миру. Чтобы обеспечить успешное выполнение миграции, важно разместить данные в правильном регионе. Если вы настроили виртуальную машину SQL Azure в неправильном расположении, миграция не запускается.

Внимание

Для виртуальной машины Azure требуется общедоступный IP-адрес.

Если вы используете этот метод миграции, создайте виртуальную машину в поддерживаемом регионе. Хотя Azure DevOps Services доступна в нескольких регионах в США (США), только центральный регион США принимает новые организации. Теперь вы не можете перенести данные в другие регионы США Azure.

Примечание.

Клиенты DACPAC должны обратиться к таблице регионов в разделе "Шаг 3. Отправка ФАЙЛА DACPAC](migration-test-run.md#)". Приведенные выше рекомендации предназначены только для виртуальных машин SQL Azure. Если вы являетесь клиентом DACPAC, ознакомьтесь с поддерживаемыми регионами Azure для миграции.

Используйте следующие конфигурации виртуальной машины SQL Azure:

  • Настройте временную базу данных SQL для использования диска, отличного от диска C. В идеале диск должен иметь достаточно свободное место; по крайней мере эквивалентна самой большой таблице базы данных.
  • Если исходная база данных по-прежнему превышает 1 терабайт (ТБ) после уменьшения его размера, необходимо подключить более 1 ТБ-дисков и объединить их в одну секцию, чтобы восстановить базу данных на виртуальной машине.
  • Если объем баз данных коллекции превышает 1 ТБ, рассмотрите возможность использования SSD (жестких дисков с твердым состоянием) для временной базы данных и базы данных коллекции. Кроме того, рекомендуется использовать более крупные виртуальные машины с 16 виртуальными ЦП (виртуальными ЦП) и 128 ГБ (гигабайтами) ОЗУ (память случайного доступа).

Восстановление базы данных на виртуальной машине

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

Настройка коллекции для миграции

После восстановления базы данных коллекции на виртуальной машине Azure настройте вход SQL, чтобы разрешить Azure DevOps Services подключаться к базе данных для переноса данных. Этот вход разрешает доступ только для чтения к одной базе данных.

  1. Откройте СРЕДУ SQL Server Management Studio на виртуальной машине и откройте новое окно запроса к базе данных для переноса.

  2. Задайте для восстановления базы данных простое значение:

    ALTER DATABASE [<Database name>] SET RECOVERY SIMPLE;

  3. Создайте вход SQL для базы данных и назначьте этот вход в TFSEXECROLE, как показано в следующем примере.

    USE [<database name>] 
CREATE LOGIN <pick a username> WITH PASSWORD = '<pick a password>' 
CREATE USER <username> FOR LOGIN <username> WITH DEFAULT_SCHEMA=[dbo] 
EXEC sp_addrolemember @rolename='TFSEXECROLE', @membername='<username>'

См. следующий пример команды SQL:

    ALTER DATABASE [Foo] SET RECOVERY SIMPLE; 
     
    USE [Foo] 
    CREATE LOGIN fabrikam WITH PASSWORD = 'fabrikampassword' 
    CREATE USER fabrikam FOR LOGIN fabrikam WITH DEFAULT_SCHEMA=[dbo] 
    EXEC sp_addrolemember @rolename='TFSEXECROLE', @membername='fabrikam'

Внимание

Включите SQL Server и режим проверка подлинности Windows в SQL Server Management Studio на виртуальной машине. Если режим проверки подлинности не включен, миграция завершается сбоем.

Настройка файла спецификации миграции для целевой виртуальной машины

Обновите файл спецификации миграции, чтобы включить сведения о подключении к экземпляру SQL Server. Откройте файл спецификации миграции и выполните следующие обновления:

  1. Удалите параметр DACPAC из объекта исходных файлов. Спецификация миграции перед изменением выглядит следующим примером кода.

    Снимок экрана: спецификация миграции перед изменением.

    Спецификация миграции после изменения выглядит следующим примером кода.

    Снимок экрана: спецификация миграции после изменения.

  2. Введите необходимые параметры и добавьте следующий объект свойств в исходный объект в файл спецификации.

    "Properties": 
{ 
    "ConnectionString": "Data Source={SQL Azure VM Public IP};Initial Catalog={Database Name};Integrated Security=False;User ID={SQL Login Username};Password={SQL Login Password};Encrypt=True;TrustServerCertificate=True"  
}

После применения изменений спецификация миграции выглядит следующим образом.

Снимок экрана: спецификация миграции, ссылающаяся на виртуальную машину SQL Azure.

Теперь спецификация миграции настроена на использование виртуальной машины SQL Azure для миграции. Выполните остальные действия по подготовке к миграции. После завершения миграции обязательно удалите вход SQL или смените пароль. Корпорация Майкрософт не сохраняет сведения о входе после завершения миграции.

Создание контейнера служба хранилища Azure в выбранном центре обработки данных

Использование средства миграции данных для Azure DevOps требует наличия контейнера служба хранилища Azure в том же центре обработки данных Azure, что и окончательная организация Azure DevOps Services. Например, если вы планируете создать организацию Azure DevOps Services в Центре обработки данных центрального США, создайте контейнер служба хранилища Azure в том же центре обработки данных. Это действие значительно ускоряет время, необходимое для переноса базы данных SQL, так как передача происходит в одном центре обработки данных.

Дополнительные сведения см. в разделе Создание учетной записи хранения.

Настройка выставления счетов

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

Мы напоминаем вам еще раз на этапе после миграции (ссылка), когда необходимо выполнить связывание. Этот шаг подготовки больше о том, чтобы убедиться, что вы знаете, какую подписку Azure вы используете на этом шаге. Дополнительные сведения см. в разделе "Настройка выставления счетов для организации".

Следующие шаги

Выполнение тестовой миграции