Preparar-se para a migração de execução de teste
Este artigo se concentra na preparação da equipe e na geração de arquivos exigidos 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 da 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 do Microsoft Entra ID da sua empresa.
- O comando prepare requer acesso à Internet. Se o Servidor de DevOps do Azure 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 onde você planeja migrar sua coleção para os Serviços de DevOps do Azure. 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 tem permissão para ler informações sobre todos os usuários no locatário do 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 executar 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.
- Local: um backup do banco de dados e dos arquivos de migração a serem carregados em um contêiner de armazenamento do Azure. Este 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 entrar na fila 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.
Revise 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 de DevOps do Azure, enquanto as identidades históricas não podem. O serviço decide qual tipo será usado.
Observação
Uma vez 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 nos Serviços de DevOps do Azure 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 de mais 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, então você tem até o primeiro dia do mês seguinte para reatribuir licenças conforme necessário. Se até o primeiro dia do próximo mês você não vincular uma assinatura à sua organização e tiver comprado o número correto de licenças, todas as suas licenças de período de cortesia 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, 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, já que o faturamento é executado mensalmente. 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, os Serviços de DevOps do Azure aplicarão automaticamente seus benefícios de assinatura do Visual Studio em sua primeira pós-migração de entrada.
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 nos Serviços de DevOps do Azure. 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 no próximo login. Depois de atualizados, da próxima vez que você migrar o usuário será atualizado automaticamente após o login 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 dos Serviços de DevOps do Azure. Você pode restringir o acesso permitindo apenas conexões de IPs dos Serviços de DevOps do Azure envolvidos no processo de migração do banco de dados de coleção. Os IPs que precisam ter 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 dos Serviços de DevOps do Azure adicionando a azuredevops Tag 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 IP
Use o IpList comando para obter a lista de IPs que precisam receber acesso para permitir conexões de uma região específica dos Serviços de DevOps do Azure.
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 grupos de segurança ou firewalls da rede por meio do portal ou programaticamente.
Configurar exceções de firewall IP para o SQL Azure
Esta seção só se aplica à configuração de exceções de firewall para o SQL Azure. Para migrações de DACPAC, consulte Configurar firewalls e redes virtuais do Armazenamento do Azure.
A Ferramenta de Migração de Dados exige que os IPs dos Serviços de DevOps do Azure 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 manipulados 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 precise receber uma exceção, defina o intervalo de portas de destino e
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 de DevOps do Azure, 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 suas exceções dos Serviços de DevOps do Azure, a Ferramenta de Migração de Dados talvez não consiga 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 necessários dos Serviços de DevOps do Azure recebam uma exceção. A falta de um IP pode resultar na falha 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 os Serviços de DevOps do Azure. 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 você 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 achar 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 informa 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 do 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 do banco de dados + blobs) para DACPAC, se qualquer tabela 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, ele pode remover muito mais espaço do que você poderia 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 obter o banco de dados abaixo do limite do DACPAC, precisará configurar uma VM do SQL Azure para migrar para os Serviços de DevOps do Azure.
Configurar uma VM do SQL Azure para migrar para os Serviços de DevOps do Azure
Execute as etapas de alto nível a seguir para configurar uma máquina virtual (VM) do SQL Azure para migrar para os Serviços de DevOps do Azure.
- Configurar uma VM do SQL Azure
- Configurar exceções de firewall IP
- Restaurar o 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 têm um impacto significativo no desempenho da migração. Por esse motivo, é altamente recomendável executar as seguintes tarefas:
- Selecione um Tamanho de VM no nível ou
D8s_v5_*maior. - Usar discos gerenciados.
- Consulte o desempenho da máquina virtual e do disco. Verifique se sua infraestrutura está configurada para que as IOPS de VM (entrada/saída por segundo) e as 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 conectados à sua VM é suficiente para oferecer suporte às IOPS da VM.
Os Serviços de DevOps do Azure estão disponíveis em várias regiões do Azure em todo o mundo. Para garantir que a migração seja iniciada com êxito, é fundamental colocar os 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 os Serviços de DevOps do Azure estejam disponíveis em várias regiões nos Estados Unidos (EUA), apenas 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, consulte 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 terabyte (TB) depois que você reduziu seu tamanho, será necessário anexar mais discos de 1 TB e combiná-los em uma única partição para restaurar o banco de dados na VM.
- Se os bancos de dados de coleção tiverem mais de 1 TB de tamanho, 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 o uso de 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 coleta for restaurado em sua VM do Azure, configure uma entrada SQL para permitir que os Serviços de DevOps do Azure se conectem ao banco de dados para migrar os dados. Esse login 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 essa entrada a '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>'
Consulte o exemplo a seguir do comando SQL:
ALTER DATABASE [Foo] SET RECOVERY SIMPLE;
USE [Foo]
CREATE LOGIN fabrikam WITH PASSWORD = 'fabrikamimport1!'
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 se parece com o código de exemplo a seguir.
A especificação de migração após a alteração se parece com o código de exemplo a seguir.
Insira os parâmetros necessários e adicione o seguinte objeto de propriedades 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, exclua a entrada SQL ou gire 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
Usar a Ferramenta de Migração de Dados para DevOps do Azure requer ter um contêiner de Armazenamento do Azure no mesmo data center do Azure que a organização final dos Serviços de DevOps do Azure. Por exemplo, se você pretende que sua organização dos Serviços de DevOps do Azure seja criada no data center Central dos Estados Unidos, 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 cortesia é colocado na organização dos Serviços de DevOps do Azure 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 compilação ou implantação, serviços de compilação hospedados, serviços de teste de carga hospedados, por exemplo, é altamente recomendável que você tenha certeza de que 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.
Lembramos novamente na fase Pós-migração (link) para quando você precisa 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 o faturamento para sua organização.
Próximas etapas
Artigos relacionados
Comentários
Em breve: Ao longo de 2024, eliminaremos os problemas do GitHub como o mecanismo de comentários para conteúdo e o substituiremos por um novo sistema de comentários. Para obter mais informações, consulte https://aka.ms/ContentUserFeedback.
Enviar e exibir comentários de