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 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 prepare 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 previamente uma região e gravou seu código taquigráfico. Use este 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 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 resultados potenciais. 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.
Nota
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 nos Serviços de DevOps do Azure após a migração. Nos Serviços de DevOps do Azure, essas identidades são licenciadas e 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. As 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, as 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 a sua história possa ser pesquisada mais tarde. 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.
Nota
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 mês seguinte você não vincular uma assinatura à sua organização e tiver comprado o número correto de licenças, todas as licenças do seu período de carência serão revogadas. Como alternativa, se a atribuição automática atribuiu mais licenças do que as que comprou para o próximo mês, não cobramos as licenças extras, mas revogamos todas as licenças não pagas.
Para evitar perder o acesso, recomendamos que você vincule uma assinatura e compre as licenças necessárias antes do primeiro dia do mês, já que a cobrança é executada 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 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 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 apenas aos IPs dos Serviços de DevOps do Azure
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 coleta. 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 facilmente permitir conexões de todas as regiões dos Serviços de DevOps do Azure adicionando a azuredevops Etiqueta 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 ter 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 Migrator a partir da própria instância do Azure DevOps Server e de uma máquina remota. Se você estiver executando o comando de uma das camadas de aplicativo da instância do Azure DevOps Server, seu 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 através 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 de armazenamento do Azure e redes virtuais.
A Ferramenta de Migração de Dados requer 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.
- Inicie sessão no portal do Azure.
- Vá para sua VM do SQL Azure.
- Em Definições, selecione Redes.
- 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 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 maior 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 grandes coleções
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 os Serviços de DevOps do Azure. Se 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 saber se você precisa usar o método de VM do SQL Azure para migração.
Determinar se é possível reduzir o tamanho da coleção
Verifique se é possível 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 achar que não precisa reter todos os dados. Alguns exemplos comuns de dados que não são mais relevantes são espaços de trabalho mais antigos e resultados de compilação.
A Ferramenta de Migração de Dados verifica a sua coleção e compara-a com os limites mencionados anteriormente. Em seguida, ele informa se sua coleção é 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 os seguintes:
- 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 de 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ê se mantenha abaixo desse 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ê 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 de 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 de 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 seguintes etapas de alto nível 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 seu banco de dados na VM
- [Configure sua coleção para migração
- Configurar o arquivo de especificação de migração para direcionar a VM
Configurar uma VM do 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 de VM no nível igual
D8s_v5_*ou superior. - Use discos gerenciados.
- Consulte o desempenho da máquina virtual e do disco. Certifique-se de que sua infraestrutura esteja configurada para que as IOPS da 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 anexados à sua VM é suficiente para suportar as 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 compatível. 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. Não é possível migrar seus dados para outras regiões do Azure dos EUA agora.
Nota
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 do 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 SQL para usar uma unidade diferente da unidade C. Idealmente, a unidade deve ter amplo espaço livre; pelo menos equivalente à maior tabela do seu banco de dados.
- Se o banco de dados de origem ainda tiver mais de 1 terabyte (TB) depois que você reduzir 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, 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 instalar e configurar uma VM do Azure, você precisa levar o backup desanexado da instância do Servidor de DevOps do Azure 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 o Servidor de DevOps do Azure seja instalado 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 os Serviços de DevOps do Azure se conectem ao banco de dados para migrar os dados. Este início de sessão permite apenas acesso de leitura a uma única base 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 seguinte exemplo 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 seu 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 início de sessão 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 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, veja Criar uma conta de armazenamento.
Configurar a faturação
Um período de carência é 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óximos passos
Artigos relacionados
Comentários
Brevemente: Ao longo de 2024, vamos descontinuar progressivamente o GitHub Issues como mecanismo de feedback para conteúdos e substituí-lo por um novo sistema de feedback. Para obter mais informações, veja: https://aka.ms/ContentUserFeedback.
Submeter e ver comentários