Preparar para a migração de execução de teste
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 Validar antes de começar a se preparar para a migração de execução de teste.
Gerar configurações de migração
Execute as etapas a seguir para gerar a especificação de migração e os arquivos relacionados para enfileirar a migração do banco de dados de coleção.
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- A opção de nome de domínio do locatário é o nome do locatário da ID do Microsoft Entra da sua empresa.
- O comando prepare requer acesso à Internet. Se o Azure DevOps Server não tiver conectividade com a Internet, execute o comando em 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.
Entre com um usuário do locatário que tenha permissão para ler informações sobre todos os usuários no locatário da ID do Microsoft Entra.
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 sobre como executar as ações a seguir.
- 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.
- Local: um backup do banco de dados e dos arquivos de migração a serem carregados em um contêiner de armazenamento do Azure. Esse campo especifica a chave SAS usada pela ferramenta de migração para se conectar e ler com segurança os arquivos de origem do contêiner de armazenamento do 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 no Azure DevOps Services, enquanto as identidades históricas não. O serviço decide qual tipo é usado.
Observação
Depois que uma identidade é migrada como uma identidade histórica, não há como convertê-la em uma identidade ativa.
Identidades ativas
As identidades ativas referem-se às identidades de usuário no Azure DevOps Services após a migração. Em 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 identidade.
Identidades históricas
As identidades históricas são mapeadas como tal na coluna Status de Importação Esperado no arquivo de log do mapa de identidade. Identidades sem uma entrada 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. Recomendamos que você use identidades históricas para usuários que não trabalham mais na empresa ou que não precisam mais de acesso à organização.
Observação
Depois que uma identidade migra como histórica, você não pode torná-la ativa.
Licenças
Durante a migração, as licenças são atribuídas automaticamente 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 dia do mês seguinte você não vincular uma assinatura à sua organização e comprar o número correto de licenças, todas as suas licenças de período de carência serão revogadas. Como alternativa, se a atribuição automática atribuiu mais licenças do que você comprou para o próximo mês, não cobraremos pelas licenças extras, mas revogaremos todas as licenças não pagas.
Para evitar a perda de acesso, recomendamos que você vincule uma assinatura e compre as licenças necessárias antes do primeiro dia do mês, pois a cobrança é mensal. Para todas as execuções de teste, as licenças são gratuitas enquanto a organização estiver ativa.
Assinaturas do Azure DevOps
As assinaturas do Visual Studio não são atribuídas por padrão para migrações. Em vez disso, os usuários com Assinaturas do Visual Studio são atualizados automaticamente para usar essa licença. Se a organização de trabalho de um usuário estiver vinculada corretamente, Azure DevOps Services aplicará automaticamente seus benefícios de assinatura do Visual Studio em sua primeira entrada após a migração.
Você não precisará repetir uma migração de execução de teste se os usuários não forem atualizados automaticamente para usar sua assinatura do Visual Studio em Azure DevOps Services. A vinculação de assinatura 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. Depois que eles forem atualizados, na próxima vez que você migrar, o usuário será atualizado automaticamente após a entrada inicial na organização.
Restringir o acesso somente a IPs Azure DevOps Services
Restrinja o acesso à sua conta de Armazenamento do Azure apenas a IPs de Azure DevOps Services. Você pode restringir o acesso permitindo apenas conexões de Azure DevOps Services IPs envolvidos no processo de migração do banco de dados de coleção. Os IPs que precisam receber 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 permitir facilmente conexões de todas as regiões do Azure DevOps Services adicionando a azuredevops Marca de Serviço aos seus grupos de segurança de rede ou firewalls por meio do portal ou programaticamente.
Opção 2: usar lista de IPs
Use o IpList comando para obter a lista de IPs que precisam receber acesso para permitir conexões de uma região específica do Azure DevOps Services.
Incluídos na documentação de ajuda estão instruções e exemplos para executar o Migrador 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 IP para o SQL Azure
Esta seção se aplica apenas à configuração de exceções de firewall para o SQL Azure. Para migrações DACPAC, consulte Configurar firewalls e redes virtuais do Armazenamento do Azure.
A Ferramenta de Migração de Dados requer que os IPs do Azure DevOps Services sejam configurados para conexões de entrada somente na porta 1433.
Execute as etapas a seguir para conceder exceções para os IPs necessários tratados na camada de rede do Azure para sua VM do SQL Azure.
- Entre no portal do Azure.
- Vá para sua VM do SQL Azure.
- Em Configurações, selecione Rede.
- Selecione Adicionar regra de porta de entrada.
- Selecione Avançado para configurar uma regra de porta de entrada para um IP específico.
- Na lista suspensa Origem, selecione Endereços IP, insira um endereço IP que precisa receber uma exceção, defina o Intervalo de portas de destino como
1433e, 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 do Azure DevOps Services, para que elas não sejam ignoradas. Por exemplo, se você tiver uma regra "negar em todas as conexões de entrada para 1433" com uma prioridade mais alta do que as exceções do Azure DevOps Services, a Ferramenta de Migração de Dados poderá não conseguir fazer uma conexão bem-sucedida com o banco de dados.
Repita a adição de regras de porta de entrada até que todos os IPs necessários do Azure DevOps Services recebam uma exceção. A falta de um IP pode resultar no início da migração.
Migrar coleções grandes
Para bancos de dados que a Ferramenta de Migração de Dados avisa que são 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 do SQL Azure para migração.
Determinar se você pode reduzir o tamanho da coleção
Verifique se você pode limpar dados antigos. Ao longo do tempo, as coleções podem compilar 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 workspaces mais antigos e resultados de build.
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, a ideia é que, se sua coleção for pequena o suficiente para caber dentro dos 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 SQL.
- Tamanho de tabela individual de 30 GB (metadados de banco de dados + blobs) para DACPAC, se alguma tabela única exceder esse limite, você precisará executar o método de migração SQL.
- Tamanho de metadados de banco de dados de 1.536 GB para o método de migração SQL. Exceder esse limite emite um aviso, recomendamos que você mantenha esse tamanho para ter uma migração bem-sucedida.
- Tamanho de metadados de banco de dados de 2.048 GB para o método de migração 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, isso pode remover muito mais espaço do que você pode esperar e pode determinar se você usa o método de migração DACPAC ou uma VM do SQL Azure.
Importante
Depois de excluir dados mais antigos, você não poderá recuperá-los, a menos que restaure um backup mais antigo da coleção.
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 colocar o banco de dados no limite 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
Execute as etapas de alto nível a seguir para configurar uma VM (máquina virtual) do SQL Azure para migrar para Azure DevOps Services.
- Configurar uma VM do SQL Azure
- Configurar exceções de firewall IP
- Restaurar seu banco de dados na VM
- [Configurar sua coleção para migração
- Configurar o arquivo de especificação de migração para direcionar a VM
Configurar uma VM SQL Azure
Você pode configurar uma VM do SQL Azure no portal do Azure rapidamente. Para obter mais informações, consulte Usar o portal do Azure para provisionar uma máquina virtual do Windows com o SQL Server.
O desempenho da VM do SQL Azure e dos discos de dados anexados tem um impacto significativo no desempenho da migração. Por esse motivo, é altamente recomendável realizar as seguintes tarefas:
- Selecione um Tamanho da 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 do 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.
Importante
A VM do Azure requer um endereço IP público.
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 nos Estados Unidos (EUA), somente a região Central dos Estados Unidos aceita novas organizações. Você não pode migrar seus dados para outras regiões do Azure dos EUA agora.
Observação
Os clientes do DACPAC devem consultar a tabela de regiões na seção "Etapa 3: Carregar o arquivo DACPAC](migration-test-run.md#)". As diretrizes anteriores são apenas para VMs SQL Azure. Se você for um cliente DACPAC, confira regiões do Azure com suporte para migração.
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 do Azure, você precisará levar o backup desanexado da instância do Azure DevOps Server para a VM do Azure. O banco de dados de coleção precisa ser restaurado em sua instância sql e não exige que Azure DevOps Server sejam instalados na VM.
Configurar sua coleção para migração
Depois que o banco de dados de coleção for restaurado em sua VM do Azure, configure uma entrada SQL para permitir que Azure DevOps Services se conecte ao banco de dados para migrar os dados. Essa entrada permite apenas acesso de leitura a um único banco de dados.
Abra o SQL Server Management Studio na VM e abra uma nova janela de consulta no banco de dados a ser migrado.
Defina a recuperação do banco de dados como simples:
ALTER DATABASE [<Database name>] SET RECOVERY SIMPLE;Crie uma entrada SQL para o banco de dados e atribua a essa entrada o 'TFSEXECROLE', como 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'
Importante
Habilite o modo de autenticação do SQL Server e do Windows no SQL Server Management Studio na VM. Se você não habilitar o modo de autenticação, a migração falhará.
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 do SQL Server. Abra o arquivo de especificação de migração e faça as seguintes atualizações:
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.
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 a entrada SQL ou girar a senha. A 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
O uso da 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 do Azure DevOps Services. Por exemplo, se você pretende que sua organização Azure DevOps Services seja criada no data center dos Estados Unidos Central, crie o contêiner de 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
Um período de carência é colocado na organização Azure DevOps Services recém-migrada para permitir que sua equipe conclua todas as etapas necessárias e corrija as atribuições de licença. Se você antecipar que talvez queira comprar mais planos de usuário, pipelines de build ou implantação, serviços de build hospedados, serviços de teste de carga hospedados, por exemplo, é altamente recomendável que você tenha 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.
Lembramos você novamente na fase Pós-migração(link) para quando você precisar fazer a vinculação. Esta etapa de preparação é mais sobre como garantir que você saiba qual assinatura do Azure você usa nessa etapa posterior. Para obter mais informações, consulte Configurar a cobrança para sua organização.