Avaliar a preparação da carga de trabalho

Este artigo se concentra em como avaliar a prontidão de uma carga de trabalho para migrar para a nuvem.

Quando você deseja migrar uma carga de trabalho, a equipe de adoção de nuvem garante que todos os ativos e dependências associadas sejam compatíveis com seu modelo de implantação e provedor de nuvem. A equipe documenta todos os esforços necessários para corrigir problemas de compatibilidade.

Pressupostos de avaliação

A maioria do conteúdo que discute os princípios do Cloud Adoption Framework for Azure é agnóstica em relação à nuvem. No entanto, o processo de avaliação de prontidão deve ser específico para cada plataforma de nuvem e para as ferramentas de migração selecionadas na fase Preparar .

As ferramentas de avaliação selecionadas devem fornecer informações sobre quaisquer bloqueadores para migração. Os bloqueadores comuns incluem suporte ao sistema operacional, tamanho do servidor e taxas de alteração de dados que podem afetar a replicação.

Algumas organizações também enfrentam problemas com configurações de máquinas virtuais (VMs) que aproveitam a plataforma do hipervisor de origem. Essas configurações incluem segurança baseada em virtualização, discos dinâmicos, licenças de aplicativos que não são da Microsoft, configurações de fonte de dados e certificados.

Este artigo não captura todas as atividades de avaliação possíveis porque cada ambiente e resultado de negócios dita requisitos específicos. Para ajudá-lo a determinar quais são esses requisitos, aqui estão algumas atividades de avaliação comuns relacionadas à infraestrutura, bancos de dados e redes.

Avaliar dependências entre datacenters

Se você estiver migrando cargas de trabalho de vários datacenters, deverá avaliar quaisquer dependências entre esses datacenters.

Considere os seguintes recursos para avaliar suas dependências entre datacenters:

• Visualizar dependências: use o recurso de visualização de dependência no Azure Migrar e Modernizar para identificar dependências.
• Dependências de grupo: use o agrupamento de dependências quando estiver lidando com a complexidade global. Esse recurso ajuda a identificar os endereços IP e as portas de quaisquer ativos necessários para dar suporte à carga de trabalho.

Importante

• Você precisa de um especialista no assunto que entenda de posicionamento de ativos e esquemas de endereço IP para identificar ativos que residem em um datacenter secundário.
• Você precisa avaliar as dependências downstream e os clientes na visualização para entender as dependências bidirecionais.

Cenários de exemplo

As seções a seguir fornecem orientação para avaliar a prontidão para migrar cargas de trabalho e bancos de dados para a nuvem.

Atividades de avaliação comuns para o Azure Migrar e Modernizar

As diretrizes a seguir pressupõem que você pretende migrar uma carga de trabalho para o Azure. Ele também pressupõe que você esteja usando o Azure Migrate and Modernize para atividades de replicação.

Você pode usar seu projeto Azure Migrate and Modernize para avaliar cargas de trabalho e calcular o custo de operação no Azure. Para obter mais informações, consulte Avaliações de VM do Azure em Migrar e Modernizar do Azure.

Você também pode usar seu projeto Azure Migrate and Modernize para avaliar a prontidão para a migração, traduzir o tamanho do servidor para assinaturas do Azure com base no uso real e calcular custos. Refine ainda mais seus cálculos de custos criando um business case.

Garanta que documenta quaisquer discrepâncias na configuração do anfitrião, na configuração de VMs replicadas, nos requisitos de armazenamento ou na configuração de rede. Use essas informações para estimar as considerações de largura de banda para sua migração. Os componentes comuns da estimativa de largura de banda incluem:

• Armazenamento total: calcule o armazenamento total de que as VMs replicadas precisam durante as iterações que levam a uma versão.
• Desvio ou taxa de alteração: calcule a taxa de desvio ou alteração de armazenamento de que as VMs replicadas precisam durante as iterações que levam a uma versão.
• Requisitos de largura de banda: calcule os requisitos de largura de banda de que cada iteração precisa somando o armazenamento total e o desvio.
• Largura de banda não utilizada: calcule a largura de banda não utilizada disponível na rede atual para validar o alinhamento por iteração.
• Largura de banda da velocidade de migração: documente a largura de banda necessária para atingir a velocidade de migração prevista. Se você precisar de alguma correção para fornecer a largura de banda necessária, notifique a equipe responsável pelas atividades de correção.

Nota

O armazenamento total afeta diretamente os requisitos de largura de banda durante a replicação inicial. No entanto, o desvio de armazenamento continua a partir do ponto de replicação até à versão. Tal significa que o desvio tem um efeito cumulativo na largura de banda disponível.

Para obter orientação sobre como avaliar os requisitos de largura de banda, consulte Perguntas comuns sobre ferramentas de migração e modernização.

Atividades comuns de avaliação da base de dados

Como parte da migração do servidor, você também pode examinar a migração de instâncias do SQL Server ou outros servidores de banco de dados.

• Documente RPOs e RTOs: documente os RPOs (Recovery Point Objetives, objetivos de ponto de recuperação) e os RTOs (Recovery Time Objetives, objetivos de tempo de recuperação) da implantação atual do banco de dados. Use essas informações para ajudá-lo a tomar decisões durante as atividades de arquitetura.
• Documente os requisitos de alta disponibilidade: documente os requisitos de configuração de alta disponibilidade. Para obter mais informações sobre os requisitos do SQL Server, consulte o guia de soluções de alta disponibilidade do SQL Server.
• Avaliar PaaS: avalie a compatibilidade da plataforma como serviço (PaaS). Os guias do Serviço de Migração de Banco de Dados do Azure mapeiam bancos de dados locais para soluções PaaS do Azure compatíveis, como o Azure Cosmos DB, o Banco de Dados SQL do Azure, o Banco de Dados do Azure para MySQL, o Banco de Dados do Azure para PostgreSQL ou o Banco de Dados do Azure para MariaDB.
  • Compatibilidade PaaS sem remediação: Quando a compatibilidade PaaS é uma opção sem a necessidade de qualquer correção, consulte a equipe responsável pelas atividades de arquitetura. As migrações de PaaS podem economizar tempo e reduzir o custo total de propriedade (TCO) da maioria das soluções em nuvem.
  • Compatibilidade de PaaS quando a correção é necessária: consulte as equipes responsáveis pelas atividades de arquitetura e remediação . Em muitos cenários, as vantagens das migrações de PaaS para soluções de banco de dados superam o aumento do tempo de correção.
• Tamanho do documento e taxa de alteração: documente o tamanho e a taxa de alteração de cada banco de dados que você planeja migrar.
• Documente as dependências de aplicativos e bancos de dados: sempre que possível, documente quaisquer aplicativos ou outros ativos que façam chamadas para cada banco de dados.

Nota

A sincronização de qualquer recurso consome largura de banda durante os processos de replicação. Uma armadilha comum é ignorar quanta largura de banda você precisa para manter os ativos sincronizados entre os pontos de replicação e liberação. As bases de dados são consumidoras comuns de largura de banda durante os ciclos da versão e as bases de dados com grandes quantidades de armazenamento ou uma alta taxa de alteração são especialmente preocupantes.

Considere replicar a estrutura de dados com atualizações controladas antes do teste de aceitação do usuário (UAT) e da liberação. Nesses cenários, alternativas ao Azure Site Recovery podem ser mais apropriadas. Para obter mais informações, consulte Guias do Serviço de Migração de Banco de Dados do Azure.

Próximo passo

Depois de avaliar um sistema, as saídas alimentam o desenvolvimento de uma nova arquitetura de nuvem.

Cargas de trabalho de arquitetura antes da migração