Migración de BIG-IP iSeries a rSeries: planificación, ejecución y rollback

User Groups LATAM Users
1

La migración de iSeries a rSeries incluye tres componentes: la plataforma F5OS-A, el tenant BIG-IP y la configuración de los servicios. Restaurar el UCS es una etapa del proceso. El cambio solo puede considerarse completado después de validar la conectividad, las aplicaciones, las políticas de seguridad y el failover.

El procedimiento siguiente contempla la implementación de un nuevo par de tenants en appliances rSeries distintos, manteniendo iSeries disponible para rollback. La formación temporal de un par HA entre plataformas diferentes requiere un análisis específico de compatibilidad y no está incluida en este escenario.

1. Define el hardware, las versiones y el método de migración

Registra los modelos de origen y destino, la versión completa de BIG-IP, el hotfix, la versión de F5OS-A y los módulos aprovisionados. Si el origen utiliza vCMP, identifica el guest responsable de los servicios que se migrarán.

Confirma la combinación de hardware, F5OS y tenant en la K86001294. Una versión compatible con iSeries no es necesariamente compatible con rSeries.

Consulta también la K82540512 para verificar el comportamiento y las restricciones de platform-migrate en la versión seleccionada. No asumas que la compatibilidad de una release se mantiene en otra, especialmente en entornos con Advanced WAF, APM, DNS o integraciones con HSM.

Siempre que sea posible, separa la migración de plataforma de la actualización de software. Cuando el cambio de versión sea obligatorio, incluye pruebas de compatibilidad de iRules, perfiles SSL/HTTP, políticas e integraciones.

2. Dimensiona el entorno para operar durante un fallo

La cantidad de cores de iSeries no debe convertirse directamente en vCPU de rSeries. Considera la arquitectura del modelo, los recursos disponibles para el tenant y la carga de los módulos.

Recopila una línea base con:

  • Throughput, conexiones simultáneas y nuevas conexiones por segundo.
  • Transacciones TLS, versiones de protocolo y cifrados utilizados.
  • Utilización de TMM, plano de administración, memoria y almacenamiento.
  • Carga de WAF, APM, logging y connection mirroring.
  • Latencia y tasa de éxito de las aplicaciones críticas.

El destino debe soportar la carga prevista con un appliance fuera de servicio. Un promedio bajo de CPU puede ocultar picos, presión sobre la memoria o limitaciones en el procesamiento TLS.

3. Documenta la correspondencia de red entre las plataformas

En rSeries, las interfaces físicas, los LAG y la entrega de VLAN al tenant dependen de F5OS. Restaurar el UCS de BIG-IP no sustituye esa configuración.

Documenta la correspondencia de cada interfaz y trunk del origen con las interfaces y los LAG del destino. Comprueba los transceptores ópticos, la velocidad, la MTU, LACP y la configuración de los switches.

Para cada VLAN, registra el tag, la asignación al tenant, las Self IP, el route domain, port lockdown y el traffic group. Revisa también las rutas, los SNAT pools, Automap y las dependencias de los backends respecto a la dirección de origen.

Reserva direcciones de administración propias para F5OS y para cada tenant. Prueba el acceso a la consola antes de iniciar la restauración.

Durante la preparación, mantén el destino aislado de las VLAN de producción. Utilizar direcciones de administración diferentes no evita conflictos con VIP, Self IP o anuncios de enrutamiento restaurados.

4. Prepara las copias de seguridad y Secure Vault

En el origen, ejecuta desde Bash:

tmsh save sys config
tmsh load sys config verify
tmsh save sys ucs pre_migration.ucs
sha256sum /var/local/ucs/pre_migration.ucs

No continúes si la validación presenta errores.

Transfiere el UCS mediante un canal seguro, restringe el acceso al archivo y compara el hash después de la transferencia. En entornos vCMP, utiliza la copia de seguridad del guest correspondiente.

Mantén copias de seguridad separadas de F5OS y de los tenants. Protegen capas distintas de la configuración.

El cifrado del archivo UCS y la protección de secretos mediante Secure Vault son mecanismos diferentes. Incluso sin una passphrase de archivo, el UCS puede contener contraseñas y otros valores cifrados con la master key del origen.

Define el procedimiento de migración de claves según la K9420. Cuando corresponda, configura en el destino la misma master-key passphrase utilizada durante la preparación del origen:

tmsh modify sys crypto master-key prompt-for-password
tmsh save sys config

Esta passphrase no es la contraseña del administrador ni la passphrase del archivo UCS.

Si es necesario cambiar la master key en el origen, evalúa previamente el impacto sobre HA y genera un nuevo UCS después de la preparación. No cambies la clave durante el cutover sin un procedimiento definido.

Los entornos con HSM o FIPS requieren una validación específica. La restauración del UCS, por sí sola, no garantiza que las claves privadas estén disponibles en el destino.

5. Prepara el tenant y ensaya la importación

Configura F5OS, valida el licenciamiento y prepara la red. Después, despliega el tenant con una imagen compatible y los recursos definidos en el dimensionamiento.

Confirma:

  • Acceso mediante la interfaz de administración y la consola.
  • Disponibilidad de los módulos necesarios.
  • Asignación correcta de las VLAN.
  • CPU, memoria y almacenamiento.
  • Copia de seguridad del estado inicial del destino.

La licencia del tenant se hereda de la plataforma. Comprueba que las funcionalidades necesarias estén disponibles antes de importar la configuración.

En BIG-IP 21.1.0 o posterior, cuando la release lo permita, ejecuta el dry run:

tmsh load sys ucs /var/local/ucs/pre_migration.ucs platform-migrate validate

Examina el informe:

/var/log/platform_migrate_validate.log

Revisa especialmente ignored_objects e ignored_properties. Un resultado satisfactorio puede incluir objetos o propiedades descartados. Cada exclusión debe evaluarse antes de entrar en producción.

Esta opción de validación se introdujo en BIG-IP 21.1.0. No asumas que está disponible en versiones anteriores.

En releases anteriores, ensaya la restauración en un tenant aislado y examina la salida completa. Existen limitaciones documentadas relacionadas con trunks y otras configuraciones incompatibles con tenants F5OS.

Si necesitas adaptar el UCS, conserva el original, trabaja sobre una copia y sigue el procedimiento de F5 correspondiente a la versión. Registra exactamente qué se eliminó o modificó.

6. Carga el UCS y comprueba el resultado

Después de preparar Secure Vault, ejecuta en el tenant de destino:

tmsh load sys ucs /var/local/ucs/pre_migration.ucs platform-migrate

La carga sustituye la configuración del destino. Contempla también posibles cambios de hostname y credenciales procedentes de la copia de seguridad.

La opción platform-migrate omite determinados objetos específicos de la plataforma e implica no-license y no-platform-check. Ejecutar únicamente no-platform-check no realiza las mismas adaptaciones.

Después de la importación:

tmsh show sys mcp-state

Comprueba los valores esperados:

Running Phase: running
Last Configuration Load Status: full-config-load-succeeded

Si se produce un fallo, examina la salida de la importación y el archivo:

/var/log/ltm

No pongas en producción un tenant con una carga parcial de la configuración.

Compara la configuración resultante con el inventario: VLAN, Self IP, rutas, SNAT, virtual servers, pools, monitores, perfiles, certificados, iRules y políticas. Revisa también los scripts, archivos externos e integraciones que puedan requerir un tratamiento separado.

7. Configura y prueba el nuevo HA

El HA debe establecerse entre tenants ubicados en appliances rSeries distintos. La relación se establece a nivel de los tenants; la plataforma F5OS no sincroniza su configuración mediante el DSC de estos.

Utiliza recursos equivalentes de CPU y memoria en los tenants correspondientes.

Revisa las identidades de los dispositivos, los certificados, device trust y device group. Define qué dispositivo será el origen del primer ConfigSync.

Comprueba las direcciones de ConfigSync, network failover y mirroring, además del propietario esperado de cada traffic group. Reevalúa los HA groups que dependían de trunks o interfaces de la plataforma anterior.

Evita la comunicación o sincronización accidental con el par antiguo durante la preparación.

El estado In Sync confirma la sincronización de la configuración. No demuestra que el tráfico se reenvíe correctamente, que las aplicaciones funcionen ni que las sesiones se conserven durante un failover.

8. Organiza la ventana de cambio

El plan debe identificar los responsables, la secuencia de ejecución, los criterios de aceptación y la hora límite para iniciar el rollback.

Antes del cutover:

  • Resuelve los problemas pendientes detectados durante el ensayo.
  • Congela los cambios en el origen.
  • Genera e identifica el UCS final.
  • Aplica en el destino las diferencias respecto al ensayo.
  • Valida la carga de configuración, la red y HA mientras el entorno continúa aislado.

Durante el cutover, retira la ruta antigua de producción antes de permitir que el nuevo entorno asuma las mismas direcciones o anuncios.

Comprueba el reaprendizaje de MAC, ARP/ND y la convergencia del enrutamiento. Mantén iSeries aislado y en condiciones de volver a operar.

No asumas que las conexiones existentes se conservarán al transferir el tráfico entre dos pares independientes. Ese impacto debe contemplarse en la ventana de cambio.

9. Valida mediante transacciones de aplicación

Un pool disponible solo confirma el resultado de los monitores configurados. La aceptación debe incluir operaciones reales.

Prueba el inicio de sesión, la persistencia, la carga y descarga de archivos y las transacciones críticas. Valida el certificado presentado al cliente, la cadena de confianza, SNI y la conexión TLS con el backend, cuando se utilice.

Desde una estación de pruebas:

curl --resolve app.example.com:443:192.0.2.100 \
  --connect-timeout 5 --max-time 15 \
  -sS -D - -o /dev/null https://app.example.com/health

Sustituye el hostname, la dirección y la ruta por los valores del entorno. La opción --resolve dirige la conexión a la IP seleccionada, conservando el hostname de la URL y SNI.

No utilices -k para demostrar que la validación de confianza TLS funciona. Para una CA interna, configura la confianza correspondiente en la estación de pruebas.

Valida también:

  • Rutas de ida y vuelta, SNAT y MTU.
  • Políticas WAF/APM y el enforcement esperado.
  • Autenticación externa y envío de logs.
  • Latencia, errores y consumo de recursos comparados con la línea base.
  • Failover controlado y comportamiento de las aplicaciones después del cambio.

Una prueba satisfactoria de /health no sustituye la aceptación de la transacción de negocio.

10. Ejecuta el rollback cuando se cumplan los criterios

Define de antemano los motivos para iniciar el rollback: indisponibilidad de una aplicación crítica, inestabilidad de HA, conflicto de direccionamiento, pérdida de enforcement o degradación superior al límite acordado.

La secuencia de retorno debe ser concreta:

  1. Retirar rSeries de la ruta de producción y detener sus anuncios.
  2. Restablecer la conectividad y los anuncios de iSeries.
  3. Confirmar ARP/ND, las rutas y la propiedad de las direcciones.
  4. Volver a ejecutar las transacciones críticas.
  5. Conservar los logs y las evidencias del destino.

El retorno del tráfico no recupera automáticamente las sesiones cerradas ni revierte las operaciones realizadas en las aplicaciones. Cuando existan transacciones sensibles, coordina la recuperación con los responsables de los sistemas.

Después de la aceptación definitiva, genera nuevas copias de seguridad de F5OS y de los tenants y actualiza la documentación. Mantén el entorno anterior disponible durante el período de contingencia acordado.

Referencias oficiales

En tu migración, ¿qué componente necesitó más ajustes: red, Secure Vault, políticas o HA? Comparte los modelos y las versiones para contextualizar el comportamiento encontrado.