As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Migração com o AWS Application Migration Service
A maioria das grandes migrações de elevação e troca de marchas a serem usadas. AWS AWS Transform MGN
Esse método de replicação em nível de bloco não suporta armazenamento conectado à rede (NAS), unidades compartilhadas, como compartilhamentos do Sistema de Arquivos de Rede (NFS) ou compartilhamentos Common Internet File System (CIFS) /Server Message Block (SMB). Ele suporta somente o armazenamento em nível de bloco que está diretamente conectado ao sistema migrado no momento da migração. (Para obter mais informações, consulte as perguntas frequentes sobre SAN/NAS suporte do MGN.) Isso limita a aplicabilidade da replicação por meio do MGN para a maioria dos sistemas em cluster, porque a maioria dos clusters depende do armazenamento compartilhado de várias implementações. Para obter mais informações, consulte as seções Vantagens e Desvantagens nesta página.
O método de replicação em nível de bloco exige que você instale um Agente de AWS Replicação no nível do sistema operacional (SO), e esse agente suporta somente plataformas x86 baseadas no sistema operacional Windows ou Linux (consulte Sistemas operacionais suportados pelo MGN). Non-x86 as plataformas estão fora do escopo desse método de migração. Isso inclui ARM, RISC/CISC sistemas, variações do PowerPC, sistemas IBM como pSeries, iSeries, zSeries e seus respectivos sistemas operacionais, como AIX, Solaris, Linux for PowerPC HP-UX, zLinux em mainframes e outras arquiteturas não x86.
O Agente de AWS Replicação funciona no nível de um driver de dispositivo de sistema de arquivos virtual* na pilha do sistema operacional, capturando todos os blocos de dados a serem gravados nos dispositivos subjacentes em nível de bloco (incluindo unidades, discos rígidos e dispositivos SAN conectados diretamente), conforme explicado na página de perguntas frequentes do MGN com estas perguntas:
* Veja as definições de sistema de arquivos, sistema
Vantagens
Para migrações de elevação e troca de marchas de qualquer escala, a MGN tem muitos benefícios:
-
A replicação é fácil de configurar (não requer uma curva de aprendizado acentuada).
-
É rápido escalar, implementando agentes nas máquinas de origem.
-
Você pode usar o Cloud Migration Factory
para automatizar a maioria das tarefas manuais, gerenciar várias máquinas e orquestrar ondas de migração. -
Ele oferece suporte a uma ampla variedade de arquiteturas de sistemas operacionais x86.
-
Ele suporta qualquer tipo de ambiente de origem (data center local, qualquer outra nuvem ou outra Região da AWS).
-
É independente de aplicativos, portanto, oferece suporte a qualquer aplicativo executado nos servidores de origem.
-
Nenhuma licença ou compra é necessária. AWS oferece preços pré-pagos, para que você pague pelo serviço somente enquanto o usa, sem contratos de longo prazo ou licenciamento complexo. O MGN fornece um período gratuito de 90 dias por servidor, o que é suficiente para a maioria das migrações. Para obter detalhes, consulte AWS Transform MGN os preços
no AWS site.
Desvantagens
Ao usar ferramentas de replicação em nível de bloco, como o MGN, você pode encontrar os seguintes casos e fatores secundários a serem considerados:
-
O MGN não oferece suporte a sistemas de arquivos compartilhados montados ou dispositivos de armazenamento compartilhado, como NAS, incluindo sistemas CIFS/SMB de arquivos NFS. Para obter mais informações sobre métodos de replicação para NAS ou sistemas de arquivos compartilhados, consulte Agente de replicação MGN para migrar o NFS Share
(artigo AWS re:POST) e Migrar sistemas de arquivos compartilhados em uma AWS grande migração (padrão de orientação prescritiva).AWS -
O MGN não suporta a maioria das configurações de servidores de arquivos em cluster ou cluster de banco de dados com armazenamento compartilhado devido às limitações na forma como esse armazenamento compartilhado é representado no nível do sistema operacional por meio das camadas do driver do dispositivo. Por exemplo, clusters do Microsoft SQL Server com a opção Storage Space Direct (S2D) não são suportados. No entanto, você ainda pode usar o MGN para replicar outros tipos de sistemas em cluster com armazenamento em bloco compartilhado, como armazenamento compartilhado em configurações de instância de cluster de failover (FCI) no Windows Server Failover Cluster (WSFC), conforme descrito na postagem do blog Migrando seus clusters do Microsoft Windows para o AWS uso da migração CloudEndure,
armazenamento exposto de matrizes SAN externas (conexões iSCSI) e alguns grupos de disponibilidade do Microsoft SQL Server Always On (AAG) agrupamentos em casos extremos específicos. Em geral, o MGN suporta a replicação de um dispositivo em nível de bloco a partir de um servidor em que o dispositivo de armazenamento está totalmente presente no servidor durante a migração. (O Agente AWS de Replicação deve estar instalado no servidor e o dispositivo deve estar visível para o agente para replicação.) No entanto, todos esses cenários exigem procedimentos muito específicos e resultam em janelas de transferência mais longas. -
Sistemas que têm uma alta taxa de alterações de dados (como bancos de dados OLTP) podem ter requisitos maiores de performance ou de rede, o que complica os esforços de migração.
-
A largura de banda da rede deve ser suficiente para a quantidade de dados a ser transferida dentro da janela planejada de tempo de migração e substituição. Isso ocorre porque a MGN não oferece uma opção de envio off-line, ao contrário AWS Snowball
. -
A migração requer uma pequena janela de tempo de inatividade, dentro de um RTO de minutos. O MGN usa snapshots do EBS como parte do processo de migração, e os novos discos do EBS criados a partir desses snapshots inicialmente têm pior desempenho. Com alguns padrões de leitura do banco de dados, isso pode aumentar a janela efetiva de substituição até que o banco de dados migrado atinja a performance máxima.
Best-fit cenários
O MGN cobre quase todas as migrações de elevação e mudança de marcha, com poucas desvantagens, conforme discutido nas duas seções anteriores. Essa ferramenta pode lidar com a maioria dos casos extremos, como clusters de banco de dados, desde que a maior janela de substituição necessária para esses sistemas satisfaça seus requisitos de migração.
As seções a seguir abordam dois cenários em mais detalhes:
-
Large-scale migração com várias ondas de migração
-
Migração de uma única aplicação que requer tempo de inatividade mínimo
Large-scale migração com várias ondas de migração
Um exemplo de migração em grande escala é a saída de um data center caracterizada pelos requisitos de tamanho e velocidade. Geralmente, também envolve uma restrição de tempo específica, como o fim do contrato de locação do data center. Nesse caso, a escala determina a abordagem. As ondas de migração são determinadas e agrupadas por aplicações, incluindo bancos de dados, e cada onda tem uma fase planejada de preparação, migração e substituição final com requisitos específicos de tempo de inatividade.
Dentro de cada onda de migração, é melhor mover os servidores de banco de dados em grande escala usando a replicação MGN em nível de bloco, exceto por algumas exceções nos seguintes casos especiais que podem exigir uma abordagem de migração separada:
-
A maioria dos sistemas de banco de dados em cluster
-
Sistemas de banco de dados em que a taxa de alteração excede a throughput da rede disponível (o que pode resultar em um atraso na replicação)
Para cada caso especial, considere a compensação entre seus requisitos de tempo de inatividade e o nível de esforço envolvido no uso de outra ferramenta de migração. Em alguns casos, é muito mais fácil usar a mesma abordagem de migração para todos os sistemas em vez de usar ferramentas separadas e criar processos diferentes para sistemas específicos. Se o MGN não suportar os requisitos de tempo de inatividade de um sistema específico, recomendamos que você use um dos métodos descritos na seção Migração com ferramentas de banco de dados nativas.
Migração de uma única aplicação
O cenário de aplicação única representa uma abordagem granular para migrar uma única aplicação essencial aos negócios que requer tempo de inatividade mínimo ou quase zero durante a migração, ou algumas dessas aplicações. O escopo da migração pode variar, dependendo da importância dos negócios e dos requisitos de tempo de inatividade, em contraste com os requisitos de velocidade e escala do cenário anterior (migração em grande escala). Se o aplicativo permitir tempo de inatividade dentro do RTO do MGN, ele deverá ser tratado da mesma forma que qualquer migração em grande escala descrita anteriormente.
No entanto, nos casos em que o tempo de transição deve ser o mais próximo possível, por exemplo, quando o banco de dados migrado tem padrões de leitura que exigem muito tempo para operar com desempenho total e as janelas de transição precisam permanecer pequenas, você deve considerar uma abordagem mais detalhada e granular. Em geral, essa abordagem envolve etapas e requisitos adicionais que exigem mais esforço e tempo. Uma das etapas é separar a migração do banco de dados da migração do servidor de aplicações e usar as ferramentas de migração do banco de dados descritas na próxima seção para manter os bancos de dados de origem e de destino sincronizados. É possível usar vários métodos para realizar a sincronização. Cada método tem vantagens e desvantagens e envolve diferentes compensações entre a quantidade de tempo de inatividade e a complexidade da sincronização. No entanto, manter o banco de dados sincronizado entre os ambientes de origem e de destino permite que você desvincule a camada do banco de dados da camada de aplicação. Supondo que os servidores de aplicativos não armazenem dados persistentes localmente, mas passem tudo para a camada do banco de dados, a sincronização também remove as restrições de tempo de inatividade da camada do aplicativo.
A dissociação das camadas do banco de dados e do aplicativo permite migrar servidores de aplicativos usando o MGN como no cenário anterior. Os servidores de aplicações de destino podem ser iniciados no ambiente de destino enquanto os sistemas de origem ainda estão funcionando, processando os dados e armazenando-os na camada do banco de dados. Como a camada do banco de dados já está sincronizada com o destino, o tempo de transição é mínimo, pois envolve apenas a troca de redes e o redirecionamento das solicitações dos clientes do sistema de origem antigo para o ambiente de destino. Você pode usar vários métodos para fazer isso, seguindo as orientações para blue/green implantações, geralmente trocando pontos de extremidade DNS, usando zonas DNS ponderadas, usando AWS Global Accelerator
