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 lift-and-shift migrações a serem AWS usadas AWS Application Migration Service
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 conectado diretamente ao sistema migrado no momento da migração. (Para obter mais informações, consulte as perguntas frequentes do Application Migration Service sobre suporte a SAN/NAS.) Isso limita a aplicabilidade da replicação por meio do Application Migration Service 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 compatíveis com o Application Migration Service). Plataformas não x86 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, HP-UX, Solaris, Linux for PowerPC, 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 Application Migration Service sob estas perguntas:
* Veja as definições de sistema de arquivos, sistema
Vantagens
Para lift-and-shift migrações de qualquer escala, o Application Migration Service 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 pay-as-you-go preços, então você paga pelo serviço somente enquanto o usa, sem contratos de longo prazo ou licenciamento complexo. O Application Migration Service oferece um período gratuito de 90 dias por servidor, o que é suficiente para a maioria das migrações. Para obter detalhes, consulte AWS Application Migration Service os preços
no AWS site.
Desvantagens
Ao usar ferramentas de replicação em nível de bloco, como o Application Migration Service, você pode encontrar os seguintes casos e fatores secundários a serem considerados:
-
O Application Migration Service não oferece suporte a sistemas de arquivos compartilhados montados ou dispositivos de armazenamento compartilhado, como NAS, inclusive CIFS/SMB sistemas 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 Application Migration Service não oferece suporte à maioria das configurações de servidores de arquivos ou clusters 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 Application Migration Service 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 CloudEndure migração
, 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 Application Migration Service 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 o Application Migration Service não oferece uma opção de envio off-line, ao contrário do AWS Snowball
. -
A migração requer uma pequena janela de tempo de inatividade, dentro de um RTO de minutos. O Application Migration Service 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.
Cenários mais adequados
O Application lift-and-shift Migration Service cobre quase todas as migrações, 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:
-
Migração em grande escala com várias ondas de migração
-
Migração de uma única aplicação que requer tempo de inatividade mínimo
Migração em grande escala 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 em nível de bloco do Application Migration Service, 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 Serviço de Migração de Aplicativos 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 Serviço de Migração de Aplicativos, 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 Serviço de Migração de Aplicativos, 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 implantações azul/verde, normalmente trocando endpoints de DNS, usando zonas de DNS ponderadas, usando AWS Global Accelerator
