

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

# Planificación de la migración
<a name="plan-migration"></a>

Planificar el proceso de migración es clave para garantizar una migración fluida y exitosa. En las siguientes secciones se explica cómo planificar la migración, así como las principales consideraciones al respecto. 

**Topics**
+ [Decisión sobre qué migrar](migration-decision-process.md)
+ [Desescalada de las configuraciones](descale-configurations.md)
+ [Elección de un tipo de instancia](instance-choice.md)
+ [Puntos clave de decisión](key-decision-points.md)
+ [Descripción general de la migración](high-level-migration-overview.md)

# Decisión sobre qué migrar
<a name="migration-decision-process"></a>

Al migrar, debe decidir qué cargas de trabajo son esenciales; qué cargas de trabajo son “deseables” pero no esenciales; y qué cargas de trabajo no son necesarias y se pueden [retirar una vez que se complete la migración.](https://docs.aws.amazon.com//prescriptive-guidance/latest/migration-retiring-applications/welcome.html)

Una parte importante del proceso de toma de decisiones incluirá los requisitos individuales que tenga en materia de automatización, API, herramientas y otros procesos. También tendrá que tener en cuenta los requisitos funcionales y de rendimiento de su organización.

Por ejemplo, es posible que haya utilizado plataformas de hardware compartidas en un centro de datos existente con particiones de usuario. Sin embargo, la migración puede requerir que los servicios se ejecuten en sistemas que no estén tan ampliamente compartidos debido a las limitaciones de rendimiento que supone pasar de soluciones aceleradas por hardware. Por ejemplo, las transacciones por segundo (TPS) de la capa de conexión segura (SSL) podrían requerir que un determinado servicio no se ejecute en un sistema compartido.

Tras identificar y documentar las aplicaciones que se van a migrar y sus requisitos, debe preparar los sistemas de origen siguiendo las prácticas recomendadas que se enumeran a continuación.
+ Ejecute la misma versión de F5 TMOS que ejecutará en la AWS nube. Se recomienda la [versión 14.1](https://techdocs.f5.com/kb/en-us/products/big-ip_ltm/releasenotes/product/relnote-bigip-14-1-0.html) o posterior, pero también se puede utilizar la [versión 13.1](https://techdocs.f5.com/kb/en-us/products/big-ip_ltm/releasenotes/product/relnote-bigip-ve-13-1-0.html) o posterior. Si bien puede migrar la versión [12.1.x](https://techdocs.f5.com/kb/en-us/products/big-ip_ltm/releasenotes/product/relnote-bigip-12-1-5.html), es posible que tenga problemas de seguridad, automatización y mantenimiento.
+  Tener copias de seguridad válidas de todas las configuraciones de cada dispositivo. Dado que la copia de seguridad de Univention Corporate Server (UCS) contiene atributos y objetos específicos del centro de datos (como direcciones IP, nodos o miembros del grupo), F5 recomienda crear un archivo del intérprete de comandos (SCF) para editar y combinar las configuraciones. 
+  Tener copias de seguridad de todos los certificados de seguridad pertinentes y considerar la posibilidad de pasar del cifrado RSA al cifrado ECC para mejorar el rendimiento.
+ Contar con métricas de rendimiento detalladas a nivel del servidor virtual para planificar el escalamiento y la capacidad.
+ Disponga de una solución [global de equilibrio de carga de servidores (GSLB) de F5](https://www.f5.com/solutions/use-cases/global-server-load-balancing-gslb) para la transición del centro de datos a la nube. AWS 
+ Comprender el impacto de la migración de un modelo de dispositivo de hardware a un modelo virtualizado y de software en términos de rendimiento, escalabilidad y alta disponibilidad.
+  Tenga definidos los requisitos de lo que se migrará a la AWS nube y tenga en cuenta las siguientes consideraciones.
  +  Tenga en cuenta que cualquier migración a la AWS nube requiere decidir si se migrarán las configuraciones completas o parciales. Por lo general, un movimiento parcial a la vez es más eficiente.
  +  Comprender qué rutas y direcciones IP se modificarán.
  +  Identificar qué grupos de SNAT deben reemplazarse por el F5 SNAT Automap.

 También debería considerar la posibilidad de consultar a [socios de AWS](https://partners.amazonaws.com/partners/001E000000Rl12PIAR/F5%20Networks) o al equipo de servicios profesionales de F5. Esto ayudará a garantizar una alta probabilidad de que la migración se lleve a cabo correctamente.

# Desescalada de las configuraciones
<a name="descale-configurations"></a>

“Desescalar” significa pasar de una configuración de F5 BIG-IP a una configuración más baja o más rentable, en función de las características o métricas requeridas tras la detección inicial. Debe evaluar detenidamente todas estas opciones, ya que afectarán a la arquitectura y a la cantidad de instancias necesarias. 

El siguiente diagrama le ayuda a evaluar si la desescalada es adecuada para sus necesidades y requisitos.

 ![\[Process flow for descaling a configuration.\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/migration-f5-big-ip/images/F5-descale.png) 

La migración también generará nuevas consideraciones en las siguientes áreas. 
+ **Topología de red**: actualmente AWS no admite `802.1q ` etiquetas VLANs, por lo que la cantidad de interfaces de instancia (menos una para la administración) limita la cantidad de redes que puede admitir una instancia. Si necesita una topología específica, debe evaluarla comparándola con las distintas instancias que F5 admite en la nube. AWS 
+ **Rendimiento de SSL**: los dispositivos y el chasis de F5 tienen un rendimiento de SSL que supera lo que se puede lograr con `x86`. Debe evaluar los requisitos de SSL agregados y por servidor virtual. 
+ **Rendimiento de la red**: debe evaluar las características de la red agregada, saliente e interna. AWS los tipos de instancias tienen diferentes características de red (baja, media, alta, hasta X o dedicada) que deben tenerse en cuenta. También hay límites en cuanto al tráfico que una sola instancia puede enviar de forma saliente o a través de una conexión directa. 
+ **Densidad VIP**: si tienes un número mayor de direcciones IP virtuales (VIPs), debes tener en cuenta el límite de instancias en cuanto al número de direcciones IP virtuales VIPs que se pueden asignar a las interfaces de red.
+ **Conexión simultánea**: hay límites de flujo en cuanto al número máximo de conexiones que pueden admitir las instancias.
+ **Estado de la sesión**: las distintas aplicaciones utilizan distintos tipos de persistencia. Las aplicaciones con y sin estado cambiarán los métodos utilizados por el estado compartido, y esto puede afectar a la escala de las operaciones. in/out 

# Elección de un tipo de instancia
<a name="instance-choice"></a>

F5 admite varios tipos de instancias y elegir cuál usar puede ser una decisión compleja. Para la mayoría de las `c5n.2xl` migraciones, esta `c5n.4xl` será la opción de instancia más común, ya que ofrece una combinación de rendimiento de red, densidad de CPU, densidad de interfaz y cantidad de IPs instancias compatibles con la instancia. En el siguiente diagrama se brindan ejemplos de las instancias que debe elegir, en función de los productos de F5 que utilice.



 ![\[Process flow for choosing which instance type to use.\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/migration-f5-big-ip/images/F5-instance-choice.png) 

# Puntos clave de decisión
<a name="key-decision-points"></a>

Hay muchos aspectos de la migración que deben tenerse en cuenta, pero antes de comenzar la migración de la carga de trabajo de F5 BIG-IP, hágase las siguientes preguntas para aclarar el proceso de migración. 

**¿Quiénes son los usuarios de las aplicaciones?**

Evalúe si se trata de usuarios internos (que no recorren una dirección IP elástica) o usuarios externos (que recorren una dirección IP elástica). Si los usuarios son internos, evalúe si la aplicación puede usar el DNS para adaptarse al fallo de una zona de disponibilidad o de una implementación activa. También debe comprobar si necesita utilizar un patrón de diseño alternativo que permita que una subred abarque varias zonas de disponibilidad. 

**¿Qué partes de sus aplicaciones migrarán a la AWS nube?**

Evalúe si se está trasladando toda la aplicación o solo el nivel de presentación. También debería tener en cuenta las dependencias adicionales en torno a la seguridad y al espacio de nombres de DNS. La evaluación debe determinar lo que se necesitaría de la topología de la red. Además, determine qué se requiere de un acuerdo de nivel de servicio (SLA) en caso de que se produzca un evento a nivel de zona de disponibilidad, VPC o región. AWS 

**¿Por qué se migra la aplicación?**

Es posible que esté migrando su aplicación porque está cerrando centros de datos o porque desea más elasticidad. Evalúe si la aplicación está migrando para tener una arquitectura por aplicación, en comparación con los patrones monolíticos compartidos comunes en muchos centros de datos. También vale la pena considerar qué esfuerzos de modernización deberían realizarse junto con la migración.

**¿Adónde se migra la aplicación?**

Evalúe si la aplicación debe trasladarse a una sola VPC con una o dos zonas de disponibilidad. Determine si la topología de la VPC es de interconexión o de tránsito, junto con la necesidad de implementaciones en varias regiones. Esto afectará al diseño del patrón de migración. 



# Descripción general de la migración
<a name="high-level-migration-overview"></a>

Antes de comenzar la migración, es útil diseñar todo el proceso de manera general. El siguiente es un ejemplo de los pasos que puede seguir para migrar una carga de trabajo de F5 BIG-IP a la nube. AWS Puede encontrar pasos y procesos más detallados para una migración de F5 BIG-IP en el patrón [Migrar una carga de trabajo de F5 BIG-IP a F5 BIG-IP](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) VE en la nube. AWS 

1.  Implemente el número necesario de en función de sus requisitos individuales. VPCs Esta implementación puede ser manual o automatizada mediante una herramienta como la [zona de aterrizaje de AWS](https://aws.amazon.com//solutions/implementations/aws-landing-zone/). 

1.  Evalúe las licencias, los usos y las configuraciones actuales de F5. 

1. Evalúe las aplicaciones públicas e internas. 

1.  Evalúe las configuraciones actuales de F5. 

1.  Evalúe los requisitos de tamaño y dirección IP y elija la cantidad y el tipo de F5 e AWS instancias necesarios. 

1.  Identifique qué estrategia de migración implementar. Por ejemplo, migrar mediante lift-and-shift; mediante shift-and-modernize; o utilizando una estrategia híbrida. 

1.  Evalúe e identifique el diseño del DNS. 

1.  Evalúe cómo se dirigirá el tráfico a la aplicación si existe tanto en las instalaciones como en la AWS nube. 

1.  Realice las implementaciones iniciales de las instancias de F5 mediante AWS CloudFormation plantillas. 

1.  Modifique las implementaciones para cumplir con los requisitos de topología con tablas de enrutamiento e interfaces de red elásticas adicionales. 

1.  Alinee las direcciones IP elásticas con las propias direcciones IP IPs o de administración IPs y planifique el mapeo de IP elástica a IP virtual (VIP). 

1.  Cree direcciones secundarias en interfaces de red elásticas para VIPs. 

1.  Aplique direcciones secundarias en la AWS nube. 

1.  Asigne direcciones IP elásticas a la dirección secundaria para VIPs. 

1.  Extraiga las configuraciones y compile una lista de objetos para moverlos. 

1.  Implemente las configuraciones en F5 BIG-IP. 

1.  Asigne las direcciones secundarias a VIPs. 

1.  Realice una prueba de tráfico. 

1.  Realice una prueba de conmutación por error. 

1.  Si está creando una estrategia híbrida, asegúrese de incorporar el sistema al DNS de F5. 

**importante**  
 Es necesario acceder a los puntos finales de la AWS API. Las direcciones NAT o IP elásticas también son necesarias para una alta disponibilidad dentro de las zonas de disponibilidad o entre ellas. 

En el siguiente diagrama se muestra el flujo del proceso de alto nivel para una migración a F5 BIG-IP. 

 ![\[High-level process flow for an F5 BIG-IP migration\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/migration-f5-big-ip/images/F5-high-level.png) 