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.

Suposições sobre avaliação

A maior parte do conteúdo que discute os princípios na Estrutura de Adoção de Nuvem para Azure é independente da 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 Preparação .

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 de 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 determina 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ências no Azure Migrate and Modernize para identificar dependências.
• Dependências de grupo: use o agrupamento de dependências quando estiver lidando com 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 o posicionamento de ativos e os esquemas de endereço IP para identificar ativos que residem em um datacenter secundário.
• Você precisa avaliar dependências downstream e clientes na visualização para entender 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 Migrate and Modernize

A orientação a seguir pressupõe 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 no Azure Migrate and Modernize.

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

Documente discrepâncias na configuração de host, configuração de VM replicada, requisitos de armazenamento ou 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 antecedem uma versão.
• Desvio ou taxa de alteração: calcule o desvio ou a taxa de alteração do armazenamento 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 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.

Observação

O armazenamento total afeta diretamente os requisitos de largura de banda durante a replicação inicial. No entanto, o descompasso de armazenamento continua do ponto de replicação até o lançamento. Isso significa que i descompasso tem um efeito cumulativo na largura de banda disponível.

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

Atividades comuns de avaliação de banco 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.

• Documentar RPOs e RTOs: documente os RPOs (Recovery Point Objectives, objetivos de ponto de recuperação) e os RTOs (Recovery Time Objectives, 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 de 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 compatíveis do Azure, 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 de PaaS sem correção: Quando a compatibilidade de PaaS for 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 de nuvem.
  • Compatibilidade de PaaS quando a correção é necessária: consulte as equipes responsáveis pelas atividades de arquitetura e correção . Em muitos cenários, as vantagens das migrações de PaaS para soluções de banco de dados superam o aumento no 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 dependências de aplicativos e bancos de dados: quando possível, documente quaisquer aplicativos ou outros ativos que façam chamadas para cada banco de dados.

Observação

A sincronização de qualquer ativo 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. Os bancos de dados são consumidores comuns de largura de banda durante os ciclos de lançamento e os bancos de dados com grandes volumes 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 do lançamento. Nesses cenários, as 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óxima etapa

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

Arquitetar cargas de trabalho antes da migração