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á.
# Planejar a migração
Planejar seu processo de migração é fundamental para garantir uma migração tranquila e bem-sucedida. As seções a seguir descrevem como planejar sua migração, bem como as principais considerações sobre ela.
**Topics**
+ [Como decidir o que migrar](migration-decision-process.md)
+ [Retroceder suas configurações](descale-configurations.md)
+ [Escolha o tipo de instância](instance-choice.md)
+ [Pontos-chave de decisão](key-decision-points.md)
+ [Visão geral da migração de alto nível](high-level-migration-overview.md)
# Como decidir o que migrar
Ao migrar, você precisa decidir quais workloads são essenciais; quais são “boas de ter”, mas não essenciais; e quais workloads não são necessárias e podem ser [retiradas quando a migração for concluída.](https://docs.aws.amazon.com//prescriptive-guidance/latest/migration-retiring-applications/welcome.html)
Uma parte significativa do seu processo de tomada de decisão envolverá requisitos individuais de automação, API, ferramentas e outros processos. Você também precisará considerar os requisitos funcionais e de desempenho da sua organização.
Por exemplo, você pode ter utilizado plataformas de hardware compartilhadas em um datacenter existente com partições de usuário. No entanto, sua migração pode exigir que os serviços sejam executados em sistemas que não sejam tão amplamente compartilhados devido às limitações de desempenho da migração de soluções aceleradas por hardware. Por exemplo, transações por segundo (TPS) de Secure Sockets Layer (SSL) podem exigir que um determinado serviço não seja executado em um sistema compartilhado.
Após identificar e documentar quais aplicativos migrarão e seus requisitos, você precisa preparar seus sistemas de origem utilizando as melhores práticas a seguir.
+ Execute a mesma versão do F5 TMOS que você executará na AWS nuvem. A [versão 14.1](https://techdocs.f5.com/kb/en-us/products/big-ip_ltm/releasenotes/product/relnote-bigip-14-1-0.html) ou posterior é recomendada, mas a [versão 13.1](https://techdocs.f5.com/kb/en-us/products/big-ip_ltm/releasenotes/product/relnote-bigip-ve-13-1-0.html) ou posterior também pode ser utilizada. Embora você possa migrar a versão [12.1.x](https://techdocs.f5.com/kb/en-us/products/big-ip_ltm/releasenotes/product/relnote-bigip-12-1-5.html), você pode encontrar problemas de segurança, automação e manutenção.
+ Tenha backups válidos de todas as configurações de cada dispositivo. Como o backup do Univention Corporate Server (UCS) contém atributos e objetos específicos do datacenter (como endereços IP, nós ou membros do grupo), a F5 recomenda que você crie um arquivo de comando shell (SCF) para editar e mesclar as configurações.
+ Faça backups de todos os certificados de segurança relevantes e considere mudar da criptografia RSA para ECC visando melhorar o desempenho.
+ Tenha métricas de desempenho detalhadas no nível do servidor virtual para planejamento de escalabilidade e capacidade.
+ Tenha uma solução [F5 Global Server Load Balancing (GSLB)](https://www.f5.com/solutions/use-cases/global-server-load-balancing-gslb) para a transição do data center para a nuvem. AWS
+ Entenda o impacto da migração de um modelo de dispositivo de hardware para um modelo virtualizado e de software em termos de desempenho, escalabilidade e alta disponibilidade.
+ Defina os requisitos do que será migrado para a AWS nuvem e esteja ciente das seguintes considerações.
+ Saiba que qualquer migração para a AWS nuvem exige decisões sobre se as configurações inteiras ou parciais serão migradas. Normalmente, um movimento parcial por vez é mais eficiente.
+ Entenda quais rotas e endereços IP serão alterados.
+ Identifique quais grupos SNAT devem ser substituídos pelo F5 SNAT Automap.
Você também deve considerar a consultoria de [Parceiros AWS](https://partners.amazonaws.com/partners/001E000000Rl12PIAR/F5%20Networks) ou da equipe de serviços profissionais da F5. Isso ajudará a garantir uma alta probabilidade de uma migração bem-sucedida.
# Retroceder suas configurações
“Retroceder” significa mover uma configuração F5 BIG-IP para uma configuração menor ou mais econômica, com base nos atributos ou métricas necessários após as descobertas iniciais da descoberta. Você deve avaliar cuidadosamente todas essas opções, pois elas afetarão a arquitetura e o número de instâncias necessárias.
O diagrama a seguir ajudará você a avaliar se retroceder é adequado às suas necessidades e exigências.
![\[Process flow for descaling a configuration.\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/migration-f5-big-ip/images/F5-descale.png)
A migração também criará novas considerações nas seguintes áreas.
+ **Topologia de rede** — atualmente AWS não oferece suporte a `802.1q ` tags VLANs, portanto, o número de interfaces de instância (menos uma para gerenciamento) apresenta um limite para o número de redes que uma instância pode suportar. Se você precisar de uma topologia específica, precisará avaliá-la em comparação com as diferentes instâncias que o F5 suporta na AWS nuvem.
+ **Desempenho SSL** — os dispositivos e chassis F5 possuem um desempenho SSL que excede o que pode ser realizado em `x86`. Você deve avaliar os requisitos de SSL agregados e por servidor virtual.
+ **Desempenho da rede** — Você deve avaliar as características da rede agregada, externa e interna. AWS os tipos de instância têm características de rede diferentes (baixa, média, alta, até X ou dedicada) que devem ser consideradas. Também há limites para a quantidade de tráfego que uma única instância pode enviar de saída ou por meio de uma conexão direta.
+ **Densidade VIP** — Se você tiver um número maior de endereços IP virtuais (VIPs), deverá considerar o limite de instâncias para o número VIPs que pode ser mapeado para as interfaces de rede.
+ **Conexão simultânea** — há limites de fluxo para o número máximo de conexões que as instâncias podem suportar.
+ **Estado da sessão** — aplicativos diferentes utilizam tipos diferentes de persistência. Aplicativos com e sem estado mudarão os métodos usados para o estado compartilhado, e isso pode afetar a escala das operações. in/out
# Escolha o tipo de instância
O F5 oferece suporte a vários tipos de instância e escolher qual delas utilizar pode ser uma decisão complexa. Para a maioria das migrações, `c5n.2xl` e `c5n.4xl` serão as opções de instância mais comuns, pois oferecem uma combinação de desempenho de rede, densidade de CPU, densidade de interface e o número de instâncias IPs que podem ser suportadas na instância. O diagrama a seguir fornece exemplos de quais instâncias escolher, com base nos produtos F5 que você está utilizando.
![\[Process flow for choosing which instance type to use.\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/migration-f5-big-ip/images/F5-instance-choice.png)
# Pontos-chave de decisão
Há muitos aspectos da migração que precisam ser considerados, mas antes de iniciar a migração de workload do F5 BIG-IP, faça as seguintes perguntas para esclarecer o processo de migração.
**Quem são os usuários dos seus aplicativos?**
Avalie se são usuários internos (sem atravessar um endereço IP elástico) ou externos (atravessando um endereço IP elástico). Se os usuários forem internos, avalie se o aplicativo pode utilizar o DNS para acomodar a falha de uma zona de disponibilidade ou implantação ativa. Você também deve verificar se precisa utilizar um padrão de design alternativo que permita que uma sub-rede abranja várias zonas de disponibilidade.
**Quais partes de seus aplicativos migrarão para a AWS nuvem?**
Avalie se o aplicativo inteiro está migrando ou apenas o nível da apresentação. Você também deve considerar dependências adicionais relacionadas à segurança e ao namespace DNS. Sua avaliação precisa determinar o que seria exigido da topologia da rede. Além disso, determine o que é exigido de um contrato de nível de serviço (SLA) caso um evento ocorra no nível da zona de disponibilidade, VPC ou região. AWS
**Por que o aplicativo está sendo migrado? **
Talvez você esteja migrando seu aplicativo porque está fechando datacenters ou porque deseja mais elasticidade. Avalie se o aplicativo está sendo migrado para ter uma arquitetura por aplicativo, em comparação com os padrões monolíticos compartilhados comuns em muitos datacenters. Também vale a pena considerar quais esforços de modernização devem ser realizados junto com a migração.
**Para onde o aplicativo está sendo migrado? **
Avalie se o aplicativo precisa ser migrado para uma única VPC com uma zona de disponibilidade ou duas zonas de disponibilidade. Determine a topologia de VPC de mesmo nível ou de trânsito, juntamente com a necessidade de implantações em várias regiões. Isso afetará o design do padrão de migração.
# Visão geral da migração de alto nível
Antes de começar a migração, é útil definir todo o processo a partir de um alto nível. Veja a seguir um exemplo das etapas que você pode seguir para migrar uma carga de trabalho F5 BIG-IP para a nuvem. AWS Etapas e processos mais detalhados para uma migração F5 BIG-IP podem ser encontrados no padrão [Migrar uma carga de trabalho F5 BIG-IP para F5 BIG-IP VE](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/migrate-an-f5-big-ip-workload-to-f5-big-ip-ve-on-the-aws-cloud.html?did=pg_card&trk=pg_card) na nuvem. AWS
1. Implante o número necessário de VPCs com base em seus requisitos individuais. Isso pode ser manual ou automatizado por meio de uma ferramenta como a [Zona de pouso AWS](https://aws.amazon.com//solutions/implementations/aws-landing-zone/).
1. Avalie as licenças, utilizações e configurações atuais do F5.
1. Avalie aplicativos públicos e internos.
1. Avalie as configurações atuais do F5.
1. Avalie os requisitos de tamanho e endereço IP e escolha o número e o tipo necessários de F5 e AWS instâncias.
1. Identifique qual estratégia de migração implantar. Por exemplo, mover sem alterações (lift-and-shift), mover e modernizar, ou híbrido.
1. Avalie e identifique o design do DNS.
1. Avalie como o tráfego será direcionado para o aplicativo se ele existir tanto no local quanto na AWS nuvem.
1. Execute implantações iniciais de instâncias F5 usando AWS CloudFormation modelos.
1. Modifique as implantações para atender aos requisitos de topologia com interfaces de rede elástica e tabelas de rotas adicionais.
1. Alinhe endereços IP elásticos ao autogerenciamento IPs ou ao gerenciamento IPs e planeje o mapeamento de IP elástico para IP virtual (VIP).
1. Crie endereços secundários em interfaces de rede elástica para VIPs.
1. Aplique endereços secundários na AWS nuvem.
1. Mapeie endereços IP elásticos para o endereço secundário do VIPs.
1. Extraia as configurações e compile uma lista de objetos para mover.
1. Implante as configurações no F5 BIG-IP.
1. Mapeie os endereços secundários para VIPs.
1. Teste o tráfego.
1. Teste o failover.
1. Se você estiver criando um híbrido, certifique-se de incorporar o sistema ao DNS F5.
**Importante**
O acesso aos endpoints AWS da API é necessário. Endereços IP NAT ou elásticos também são necessários para alta disponibilidade dentro ou entre as zonas de disponibilidade.
O diagrama a seguir mostra o fluxo de processo de alto nível para uma migração F5 BIG-IP.
![\[High-level process flow for an F5 BIG-IP migration\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/migration-f5-big-ip/images/F5-high-level.png)