Подготовка к миграции пробного тестового прогона

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Активные идентификации

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

Исторические идентичности

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

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

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

Лицензии

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

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

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

подписки Azure DevOps

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

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

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

• Вариант 1. Использование тегов службы
• Вариант 2. Использование списка IP-адресов

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

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

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

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

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

Справочная документация предоставляет инструкции и примеры для запуска Migrator с экземпляра 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 для входящих подключений только через порт 1433.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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. Откройте файл спецификации миграции и выполните следующие обновления:

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 или смените пароль. Microsoft не сохраняет сведения о входе после завершения миграции.

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

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

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

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

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

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

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

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

• Миграция на Azure DevOps Services
• Выполнение задач после миграции