Descoberta do ambiente Windows - Recomendações da AWS
AvaliarMobilizar

Descoberta do ambiente Windows

Com as tecnologias disponíveis atualmente, como o AWS Application Migration Service, a migração do Windows Server, do Linux e de outros sistemas operacionais baseados em x86 e suas workloads para a AWS é bastante simples. No entanto, fazer com que essas workloads funcionem adequadamente e em grande escala apresenta um conjunto diferente de desafios. Esta seção tem como objetivo identificar as considerações de migração que podem permitir que você migre de forma rápida, segura e tranquila suas workloads da Microsoft.

Avaliar

Embora você possa “forçar” migrações menores (como as que envolvem 100 servidores) com o mínimo de planejamento e automação, não é possível mover 500 ou mais servidores usando essa metodologia. As considerações a seguir são os principais contribuintes para uma migração bem-sucedida em grande escala, e você pode usar a Avaliação de Prontidão para a Migração (MRA) para identificar áreas de consideração em que deseja se concentrar.

Arquitetura corporativa

Quanto mais dívida técnica houver no ambiente, mais difícil será migrar. Organizações que têm programas de arquitetura corporativa íntegra se esforçam para limitar seu ambiente às versões atuais e recentes de software e sistemas (geralmente chamadas de versões N e N -1 das versões principais). Isso não apenas reduz o número de cenários que você deve considerar, mas também aproveita os avanços das versões mais recentes. Por exemplo, o Windows Server 2012, o Windows Server 2008 e as versões anteriores do Windows Server são cada vez mais difíceis de automatizar no ambiente Windows Server do que as versões mais atuais. O licenciamento também é mais difícil para versões mais antigas e sem suporte.

Padronização e gerenciamento de configuração

A padronização do ambiente é outro fator a ser considerado. Organizações que possuem ambientes criados e mantidos manualmente são consideradas mais como animais de estimação. Cada sistema é único e há muito mais combinações de configuração possíveis do que se fossem criadas usando imagens padronizadas, infraestrutura como código (IaC) ou pipelines de integração e entrega contínuas (CI/CD).

Por exemplo, é uma prática recomendada recriar um servidor web típico usando IaC ou CI/CD durante a migração, em vez de migrar manualmente o servidor individual. Também é uma prática recomendada armazenar todos os dados persistentes em um datastore, como banco de dados, compartilhamento de arquivos ou repositório. Se os sistemas não forem recriados usando IaC ou CI/CD, eles devem pelo menos usar ferramentas de gerenciamento de configuração (como Puppet, Chef ou Ansible) para padronizar os servidores que possuem.

Dados bons

Dados bons também são um fator essencial para migrações bem-sucedidas. Dados precisos sobre os servidores atuais e seus metadados são essenciais para automação e planejamento. A falta de bons dados aumenta a dificuldade ao planejar uma migração. Exemplos de bons dados incluem um inventário preciso de servidores, aplicações nos servidores, software nos servidores com versões, o número de CPUs, quantidade de memória e número de discos. Recomendamos que você capture todos os dados de que os planejadores de ondas precisam para o planejamento ou qualquer dado que você planeje usar como parte da automação do processo de migração.

Automação

A automação é essencial para migrações em grande escala. Exemplos de automação incluem a instalação do agente, a atualização das versões de software dos utilitários necessários para automação, como o .NET ou PowerShell, o carregamento ou a atualização de software para a AWS, como o AWS Systems Manager Agent (SSM Agent), o agente do Amazon CloudWatch ou outro software de backup ou gerenciamento necessário para execução na AWS.

Planejamento detalhado

Desenvolver e gerenciar um plano detalhado também é essencial para migrações em grande escala. Você deve ter um plano bem definido para migrar 50 servidores por semana durante várias semanas. Um plano eficaz inclui o seguinte:

  • Use o planejamento de ondas para organizar os servidores em ondas de acordo com suas dependências e prioridades.

  • Use o planejamento semanal (antes da substituição) para se comunicar com as equipes de aplicações e identificar a rede, o DNS, o firewall e outros detalhes que devem ser abordados durante a substituição.

  • Use um planejamento detalhado por hora (em torno da substituição real) para descrever a janela de manutenção da substituição.

  • Use os critérios go/no-go para descrever sob quais circunstâncias uma aplicação será considerada substituída para a AWS ou se deverá retornar ao local de origem.

  • Use as atividades de limpeza como atividades de acompanhamento que devem ser concluídas. Essas atividades podem ocorrer fora da janela de manutenção de substituição ou após a conclusão do hypercare. As atividades de limpeza incluem verificar backups e vários agentes, remover o agente do Application Migration Service de um servidor ou remover o servidor de origem e os recursos associados.

Mobilizar

Durante a fase de mobilização, é importante descobrir o máximo possível de complexidades e variações de sua organização para que elas possam ser consideradas durante o planejamento da migração. De preferência, você pode evitar lidar com essas complexidades e variações durante a janela de manutenção de substituição e evitar failbacks.

Desafios das migrações em grande escala

As falhas de migração ocorrem quando uma aplicação ou aplicações são substituídas para seus novos ambientes e os requisitos funcionais ou de performance não podem ser atendidos dentro da janela de manutenção da migração. Isso força a aplicação ou as aplicações a fazerem o failback para o local original. Além disso, todas as outras aplicações que dependem dessa aplicação ou aplicações também precisam fazer o failback. Migrações fracassadas tendem a impactar não apenas a onda atual, mas também as futuras, pois as aplicações devem ser reprogramadas.

Dependências sensíveis à latência

Um dos principais motivos para a falha nas migrações são as dependências sensíveis à latência. Deixar de identificar as dependências sensíveis à latência pode causar problemas de performance que resultam em tempos de resposta ou tempos de transação inaceitáveis.

Por exemplo, normalmente uma aplicação move seus servidores de banco de dados e aplicações para a nuvem ao mesmo tempo porque eles se comunicam com frequência e precisam do tempo de resposta inferior a um milissegundo que têm quando estão no mesmo data center. É provável que mover apenas o banco de dados para a nuvem introduza muitos segundos de latência nessas transações, resultando em um impacto significativo na performance da aplicação. Isso também se aplica a aplicações que dependem de forma intensiva umas das outras e precisam estar no mesmo data center para funcionar adequadamente.

Compreender e lidar com as dependências da aplicação é, portanto, de fundamental importância ao planejar migrações. Aplicações e serviços que dependem uns dos outros devem ser identificados para que possam ser migrados juntos.

Serviços de TI compartilhados

Depois que uma workload está na nuvem, ela precisa de uma variedade de serviços para funcionar e ser mantida de forma adequada e segura. Isso inclui uma zona de pouso, perímetro de rede e segurança, autenticação, aplicação de patches, scanners de segurança, ferramentas de gerenciamento de serviços de TI, backups, bastion hosts e outros recursos. Sem esses serviços, as workloads podem não funcionar adequadamente e serão forçadas a fazer failback para o local original.

Atualizações da configuração

Na maioria dos casos, você deve fazer várias alterações na configuração para que uma workload funcione adequadamente depois que a workload for movida para a nuvem. Essas alterações de configuração geralmente estão associadas às seguintes dependências da workload:

  • Regras de firewall

  • Listas de permissões

  • Registros de DNS

  • Strings de conexão

Se você não fizer as atualizações de configuração adequadas, a workload, seus usuários e seus sistemas dependentes poderão não se comunicar entre si. É possível resolver esses problemas dentro da janela de interrupção, mas as alterações nesse momento podem ser demoradas ou exigir registros de alterações que não podem ser atendidos a tempo.

Testes funcionais das aplicações

Outro desafio para migrações em grande escala é a necessidade de testes funcionais das aplicações. Isso é particularmente importante, pois muitas organizações dependem de equipes de aplicações para identificar dependências sensíveis à latência, serviços compartilhados de TI ou atualizações de configuração necessárias. O ideal é que uma equipe de aplicações forneça um plano escrito ou automatizado de testes que possa ser executado durante a janela de manutenção de substituição para validar se a aplicação está totalmente funcional com performance aceitável. Para reduzir ao mínimo a janela de manutenção de substituição, o teste deve poder ser concluído em até 30 minutos.

Ferramentas para a descoberta de dependências de aplicações

Determinar dependências entre aplicações é fundamental para migrações bem-sucedidas, tanto para detectar dependências sensíveis à latência quanto para itens de configuração de conectividade. Existem várias ferramentas disponíveis no marketplace para descobrir dependências, como o AWS Application Discovery Service (ferramenta com e sem agente) e o Cloudamize (ferramenta baseada em agente).

Ao escolher uma ferramenta para a descoberta de dependências de aplicações, considere o seguinte:

  • Duração: recomendamos que você execute as ferramentas de descoberta por tempo suficiente para capturar eventos específicos da aplicação, como picos conhecidos, fim de mês e outros eventos. O mínimo recomendado é de 30 dias.

  • Ativo (baseado em agente): as ferramentas ativas de descoberta de dependências geralmente são incorporadas ao kernel do sistema operacional e capturam todas as transações. No entanto, este geralmente é o método mais caro e demorado.

  • Passivo (sem agente) : as ferramentas passivas de descoberta de dependências são muito mais baratas e rápidas de implementar, mas correm o risco de perder algumas conexões menos usadas.

  • Conhecimento institucional: embora as ferramentas de descoberta de aplicações forneçam informações mais detalhadas e precisas, a maioria das organizações conta com suas equipes de aplicações e com seu conhecimento institucional para descobrir dependências de aplicações. As equipes de aplicações geralmente conhecem as dependências sensíveis à latência, mas não é incomum que percam alguns detalhes, como configurações de conectividade, regras de firewall ou requisitos da lista de permissões de um parceiro. Você pode usar o conhecimento institucional para aprimorar a descoberta de dependências de aplicações, mas recomendamos que você também considere e reduza os riscos envolvidos. Por exemplo, existe o risco de perder itens de configuração de conectividade ou dependências sensíveis à latência se você depender apenas do conhecimento de suas equipes de aplicações. Isso pode resultar em interrupções ou em migrações malsucedidas. Para mitigar esse risco, recomendamos que você faça testes funcionais de aplicações detalhado.