Preparar a execução de teste para migração

Este artigo se concentra na preparação da equipe e na geração de arquivos exigidas pela Ferramenta de Migração de Dados.

Pré-requisitos

Conclua a fase de Validação antes de começar a se preparar para a migração de execução de teste.

Gerar configurações de migração

Gere a especificação de migração e os arquivos relacionados para enfileirar a migração do banco de dados da coleção.

1. Execute o comando de preparação da Ferramenta de Migração de Dados com os seguintes parâmetros:

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

   • Use a opção nome de domínio do locatário como o nome do locatário Microsoft Entra ID da sua empresa.
   • O comando prepare requer acesso à Internet. Se o Azure DevOps Server não tiver conectividade com a Internet, execute o comando de um computador diferente.
   • O termo "região da organização" refere-se ao local em que você planeja migrar sua coleção para Azure DevOps Services. Você selecionou anteriormente uma região e registrou seu código abreviado. Use esse código no comando prepare.

2. Faça login com um usuário do inquilino que tenha permissão para ler informações sobre todos os usuários no tenant Microsoft Entra ID.

Configurar o arquivo de especificação de migração

O arquivo de especificação de migração é um arquivo JSON que instrui a Ferramenta de Migração de Dados como concluir as seguintes ações:

• Configurar sua organização migrada
• Especificar os locais de origem
• Personalizar a migração

Muitos dos campos são preenchidos automaticamente durante a etapa de preparação, mas você deve configurar os seguintes campos:

• Nome da organização: o nome da organização que você deseja criar para migrar seus dados.
• Location: Um backup de seu banco de dados e arquivos de migração para carregar em um contêiner de armazenamento Azure. Esse campo especifica a chave SAS usada pela ferramenta de migração para se conectar com segurança e ler os arquivos de origem do contêiner de armazenamento Azure. A criação do contêiner de armazenamento é abordada posteriormente na Fase 5 e a geração de uma chave SAS é abordada na Fase 6 antes de você enfileirar para uma nova migração.
• DACPAC: um arquivo que empacota o banco de dados SQL da sua coleção.
• Tipo de migração: o tipo de migração: execução de teste ou execução de produção.

Cada arquivo de especificação de migração destina-se a uma única coleção. Se você tentar usar um arquivo de especificação de migração gerado para outra coleção, a migração não será iniciada. Você precisa preparar uma execução de teste para cada coleção que deseja migrar e usar o arquivo de especificação de migração gerado para enfileirar a migração.

Revisar o arquivo de log do mapa de identidade

O log do mapa de identidade é crucial, tão importante quanto os dados reais que você migra. Ao examinar o arquivo de log, entenda como a migração de identidade funciona e os possíveis resultados. Quando você migra uma identidade, ela pode ser ativa ou histórica. As identidades ativas podem entrar nos Serviços Azure DevOps, enquanto as identidades históricas não podem. O serviço decide qual tipo é usado.

Identidades ativas

Identidades ativas referem-se a identidades de usuário no Azure DevOps Services após a migração. No Azure DevOps Services, essas identidades são licenciadas e são exibidas como usuários na organização. As identidades são marcadas como ativas na coluna Status de Importação Esperado no arquivo de log do mapa de identidades.

Identidades históricas

O arquivo de log do mapa de identidade mostra identidades históricas na coluna Status Esperado de Importação. Identidades sem um registro de linha no arquivo também se tornam históricas. Um exemplo de uma identidade sem uma entrada de linha pode ser um funcionário que não trabalha mais em uma empresa.

Ao contrário das identidades ativas, identidades históricas:

• Não tenha acesso a uma organização após a migração.
• Não tem licenças.
• Não apareça como usuários na organização. Tudo o que persiste é a noção do nome dessa identidade na organização, para que seu histórico possa ser pesquisado posteriormente. Use identidades históricas para usuários que não trabalham mais na empresa ou que não precisam de mais acesso à organização.

Licenças

Durante a migração, o processo atribui automaticamente licenças para todos os usuários exibidos como ativos na coluna Status de Importação Esperado do log de mapeamento de identidade. Se a atribuição automática de licença estiver incorreta, você poderá alterá-la editando o nível de acesso de um ou mais usuários após a conclusão da migração.

A atribuição pode nem sempre ser perfeita, portanto, você tem até o primeiro dia do mês seguinte para reatribuir as licenças conforme necessário. Se até o primeiro do mês seguinte você não vincular uma assinatura à sua organização e comprar o número correto de licenças, todas as licenças de período de carência serão revogadas. Como alternativa, se a atribuição automática atribuir mais licenças do que você comprou para o próximo mês, você não será cobrado pelas licenças extras, mas todas as licenças não pagas serão revogadas.

Para evitar perder o acesso, vincule uma assinatura e compre as licenças necessárias antes do primeiro mês, pois a cobrança é executada mensalmente. Para todas as execuções de teste, as licenças são gratuitas enquanto a organização estiver ativa.

Azure DevOps assinaturas

Assinaturas do Visual Studio não são atribuídas por padrão nas migrações. Em vez disso, os usuários com Assinaturas do Visual Studio são atualizados automaticamente para usar essa licença. Os serviços do Azure DevOps aplicam automaticamente os benefícios da assinatura do Visual Studio na primeira vez que o usuário fizer login após a migração, desde que a organização de trabalho do usuário esteja corretamente vinculada.

Você não precisa repetir uma migração de execução de teste se os usuários não forem atualizados automaticamente para usar a assinatura Visual Studio no Azure DevOps Services. A vinculação de assinaturas do Visual Studio é algo que acontece fora do escopo de uma migração. Se a organização de trabalho for vinculada corretamente antes ou depois da migração, o usuário terá sua licença atualizada automaticamente na próxima entrada. Assim que eles forem atualizados, na próxima migração, o usuário será atualizado automaticamente ao fazer o login inicial na organização.

Restringir o acesso somente a IPs de serviços de Azure DevOps

• Opção 1: usar tags de serviço
• Opção 2: usar lista de IPs

Restrinja o acesso à sua conta Armazenamento do Azure a apenas IPs do Azure DevOps Services. Você pode restringir o acesso permitindo apenas conexões de IPs dos serviços Azure DevOps que estão envolvidos no processo de migração do banco de dados de coleção. Os IPs que precisam de acesso à sua conta de armazenamento dependem da região para a qual você está migrando.

Opção 1: usar tags de serviço

Você pode facilmente permitir conexões de todas as regiões do Azure DevOps Services adicionando a marca de serviço azuredevops a seus grupos de segurança de rede ou firewalls por meio do portal ou programaticamente.

Opção 2: usar lista de IPs

Use o comando IpList para obter a lista de IPs que precisam de acesso para permitir conexões de uma região específica dos Serviços Azure DevOps.

A documentação de ajuda inclui instruções e exemplos para executar o Migrator da própria instância do Azure DevOps Server e de um computador remoto. Se você estiver executando o comando de uma das camadas de aplicativo da instância Azure DevOps Server, o comando deverá ter a seguinte estrutura:

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

Você pode adicionar a lista de IPs aos seus grupos de segurança de rede ou firewalls por meio do portal ou programaticamente.

Configurar exceções de firewall de IP para o SQL Azure

Esta seção aborda a configuração de exceções de firewall para o SQL Azure. Para migrações da DACPAC, consulte Configure Armazenamento do Azure firewalls e redes virtuais.

A Ferramenta de Migração de Dados exige que você configure os IPs dos Serviços Azure DevOps para conexões de entrada somente na porta 1433.

Para conceder exceções para os IPs necessários que a camada de rede Azure manipula para sua VM Azure SQL, conclua as seguintes etapas:

1. Entre no portal do Azure.
2. Vá para sua VM do SQL Azure.
3. Em Configurações, selecione Rede.
4. Selecione Adicionar regra de porta de entrada.
5. Selecione Avançado para configurar uma regra de porta de entrada para um IP específico.
6. Na lista suspensa Origem, selecione Endereços IP. Insira um endereço IP que precise de uma exceção. Defina o intervalo de portas de destino como 1433. Na caixa Nome , insira um nome que melhor descreva a exceção que você está configurando.

Dependendo de outras regras de porta de entrada configuradas, talvez seja necessário alterar a prioridade padrão para as exceções dos Serviços Azure DevOps, para que elas não sejam ignoradas. Por exemplo, se você tiver uma regra "negar todas as conexões de entrada com 1433" com uma prioridade maior do que as exceções dos Serviços Azure DevOps, a Ferramenta de Migração de Dados poderá não conseguir fazer uma conexão bem-sucedida com seu banco de dados.

Repita a adição de regras de porta de entrada até que todos os IPs de serviços Azure DevOps necessários tenham uma exceção. A falta de um IP pode resultar na falha do início da migração.

Migrar coleções grandes

Para bancos de dados que a Ferramenta de Migração de Dados avisa serem muito grandes, uma abordagem de empacotamento de dados diferente é necessária para migrar para Azure DevOps Services. Se você não tiver certeza se sua coleção excede o limite de tamanho, execute uma validação da Ferramenta de Migração de Dados na coleção. A validação permite que você saiba se precisa usar o método de VM Azure SQL para migração.

Determinar se você pode reduzir o tamanho da coleção

Verifique se você pode limpar dados antigos. Com o tempo, as coleções podem acumular grandes volumes de dados. Esse crescimento é uma parte natural do processo de DevOps, mas você pode descobrir que não precisa reter todos os dados. Alguns exemplos comuns de dados não mais relevantes são ambientes de trabalho mais antigos e resultados de compilação.

A Ferramenta de Migração de Dados verifica sua coleção e a compara com os limites mencionados anteriormente. Em seguida, ele relata se sua coleção está qualificada para o método de migração DACPAC ou SQL. Em geral, se sua coleção for pequena o suficiente para se ajustar aos limites do DACPAC, você poderá usar a abordagem DACPAC mais rápida e simples. No entanto, se sua coleção for muito grande, você precisará usar o método de migração sql, que envolve a configuração de uma VM do SQL Azure e a migração manual do banco de dados.

Limites de tamanho

Os limites atuais são:

• Tamanho total do banco de dados de 150 GB (metadados de banco de dados + blobs) para DACPAC. Se você exceder esse limite, precisará executar o método de migração do SQL.
• Tamanho da tabela individual de 30 GB (metadados de banco de dados + blobs) para DACPAC. Se qualquer tabela única exceder esse limite, você precisará executar o método de migração do SQL.
• Tamanho de metadados de banco de dados de 1.536 GB para o método de migração do SQL. Exceder esse limite emite um aviso. Mantenha o tamanho abaixo desse limite para ter uma migração bem-sucedida.
• Tamanho dos metadados de banco de dados de 2.048 GB para o método de migração do SQL. Exceder esse limite resulta em um erro, portanto, você não pode executar uma migração.
• Não há limite para tamanhos de blob para o método de migração SQL.

Quando você limpa artefatos mais antigos e não mais relevantes, você pode remover mais espaço do que o esperado. Essa limpeza pode determinar se você usa o método de migração DACPAC ou uma VM do SQL Azure.

Se você estiver abaixo do limite do DACPAC, siga as instruções para gerar um DACPAC para migração. Se você ainda não conseguir obter o banco de dados sob o limite da DACPAC, precisará configurar uma VM do SQL Azure para migrar para Azure DevOps Services.

Configurar uma VM do SQL Azure para migrar para Azure DevOps Services

Conclua as etapas de alto nível a seguir para configurar uma VM (máquina virtual) Azure SQL para migrar para Azure DevOps Services.

1. Set up a SQL Azure VM
2. Configurar exceções de firewall IP
3. Restaurar seu banco de dados na VM
4. Configurar sua coleção para migração
5. Configurar o arquivo de especificação de migração para direcionar a VM

Configurar uma VM do SQL Azure

Você pode configurar rapidamente uma VM do SQL Azure no portal do Azure. Para obter mais informações, consulte Use o portal Azure para provisionar uma máquina virtual Windows com SQL Server.

O desempenho do SQL Azure VM e discos de dados anexados afeta significativamente o desempenho da migração. Por esse motivo, conclua as seguintes tarefas:

• Selecione um tamanho de VM no nível de D8s_v5_* ou superior.
• Usar discos gerenciados.
• Consulte o desempenho da máquina virtual e do disco. Verifique se a infraestrutura está configurada para que o IOPS da VM (entrada/saída por segundo) e o IOPS de armazenamento não se tornem um gargalo no desempenho da migração. Por exemplo, verifique se o número de discos de dados anexados à VM é suficiente para dar suporte ao IOPS da VM.

Azure DevOps Services está disponível em várias regiões Azure em todo o mundo. Para garantir que a migração seja iniciada com êxito, é fundamental colocar seus dados na região correta. Se você configurar sua VM do SQL Azure em um local errado, a migração não será iniciada.

Se você estiver usando esse método de migração, crie sua VM em uma região com suporte. Embora Azure DevOps Services esteja disponível em várias regiões no Estados Unidos (EUA), apenas a região do Estados Unidos Central aceita novas organizações. Você não pode migrar seus dados para outras regiões Azure dos EUA agora.

Use as seguintes configurações de VM do SQL Azure:

• Configure o banco de dados temporário do SQL para usar uma unidade diferente da unidade C. Idealmente, a unidade deve ter amplo espaço livre, pelo menos equivalente à maior tabela do banco de dados.
• Se o banco de dados de origem ainda tiver mais de 1 TB (terabyte) depois de reduzir seu tamanho, você precisará anexar mais discos de 1 TB e combiná-los em uma única partição para restaurar seu banco de dados na VM.
• Se os bancos de dados de coleção tiverem mais de 1 TB, considere o uso de um SSD (discos rígidos de estado sólido) para o banco de dados temporário e o banco de dados de coleção. Além disso, considere usar VMs maiores com 16 CPUs virtuais (vCPUs) e 128 GB (gigabytes) de RAM (memória de acesso aleatório).

Restaurar seu banco de dados na VM

Depois de configurar e configurar uma VM Azure, você precisará levar o backup desanexado da instância de Azure DevOps Server para sua VM Azure. O banco de dados de coleção precisa ser restaurado na instância do SQL e não requer que o Azure DevOps Server seja instalado na VM.

Configurar sua coleção para migração

Depois de restaurar o banco de dados de coleção em sua VM Azure, configure uma autenticação SQL para permitir que Azure DevOps Services se conectem ao banco de dados e migrem os dados. Essa autenticação concede acesso de leitura a apenas um banco de dados.

1. Abra SQL Server Management Studio na VM e abra uma nova janela de consulta para o banco de dados que você deseja migrar.

2. Defina o modelo de recuperação do banco de dados como simples:

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

3. Crie uma autenticação SQL para o banco de dados e atribua essa autenticação à TFSEXECROLE função, conforme mostrado no exemplo a seguir.

   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>'
   

Veja o exemplo a seguir do comando 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'

Configurar o arquivo de especificação de migração para direcionar a VM

Atualize o arquivo de especificação de migração para incluir informações sobre como se conectar à instância SQL Server. Abra o arquivo de especificação de migração e faça as seguintes atualizações:

1. Remova o parâmetro DACPAC do objeto de arquivos de origem. A especificação de migração antes da alteração é semelhante ao código de exemplo a seguir.

   

   A especificação de migração após a alteração é semelhante ao código de exemplo a seguir.

   

2. Insira os parâmetros necessários e adicione o objeto properties a seguir dentro do objeto de origem no arquivo de especificação.

   "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"  
   }
   

Depois de aplicar as alterações, a especificação de migração se parece com o exemplo a seguir.

Sua especificação de migração agora está configurada para usar uma VM do SQL Azure para migração. Prossiga com o restante das etapas de preparação para a migração. Após a conclusão da migração, certifique-se de excluir o login SQL ou alterar a senha. Microsoft não retém as informações de entrada após a conclusão da migração.

Criar um contêiner de Armazenamento do Azure no data center escolhido

Usar a Ferramenta de Migração de Dados para Azure DevOps requer ter um contêiner de Armazenamento do Azure no mesmo data center do Azure que a organização final dos Serviços do Azure DevOps. Por exemplo, se você pretende que sua organização Azure DevOps Services seja criada no data center do Central Estados Unidos, crie o contêiner Armazenamento do Azure nesse mesmo data center. Essa ação acelera drasticamente o tempo necessário para migrar o banco de dados SQL, já que a transferência ocorre dentro do mesmo data center.

Para obter mais informações, consulte Criar uma conta de armazenamento.

Configurar cobrança

Quando você migra uma organização do Azure DevOps Services, a nova organização obtém um período de carência. Use este tempo para concluir quaisquer etapas e corrigir atribuições de licença. Se você acha que pode querer comprar mais planos de usuário, criar ou implantar pipelines ou serviços de build hospedados, verifique se você tem uma assinatura do Azure pronta para vincular à sua organização migrada. O período de carência termina no primeiro dia do mês seguinte após a conclusão da migração.

A fase pós-migração serve como um lembrete de quando realizar a vinculação. Esta etapa de preparação é mais sobre garantir que você saiba qual assinatura Azure você usa nessa etapa posterior. Para obter mais informações, consulte Configurar a cobrança para sua organização.

Próximas etapas

Conteúdo relacionado

• Migre para Azure DevOps Services
• Concluir tarefas pós-migração