Puede migrar clústeres y bases de NCP del modo Manager al modo Directiva.

Tras la actualización de NCP, los recursos del modo NSX Manager se pueden migrar a Directiva de NSX, lo que permite que NCP funcione en modo Directiva. El proceso de migración también se denomina "importar" en la documentación. Significan lo mismo. Esta función para migrar bases de TAS está disponible a partir de NCP 4.1.2. La función para migrar clústeres de TKGI y clústeres de Kubernetes Vanilla está disponible a partir de NCP 4.0).

Requisitos previos

  1. La migración de un clúster de Kubernetes o base de TAS puede tardar algún tiempo y requiere un tiempo de inactividad del plano de control (no se permiten operaciones de creación, actualización o eliminación) en NSX. El tiempo de inactividad durará en función de la estrategia de migración utilizada, de dos posibles:
    1. Estrategia 1: (recomendada y requerida para TAS) Programar un tiempo de inactividad del plano de control en todos los clústeres (que se ejecuten en modo Manager o en modo Directiva) simultáneamente. El periodo de inactividad durará hasta que todos los clústeres se migren a Directiva. Su ventaja es que permite usar la función de copia de seguridad y restauración de NSX durante el error y la recuperación.
    2. Estrategia 2: Programar un periodo de inactividad del plano de control en un clúster a la vez. Después de migrar un clúster, NCP se iniciará en modo Directiva en ese clúster. Con esta estrategia no se puede usar la función de copia de seguridad y restauración de NSX, ya que otros clústeres podrían crear nuevas cargas de trabajo en NSX mientras se migra el clúster actual. Este método se puede usar si es aceptable descartar el clúster en caso de que se produzca un error en la migración y en la reversión.
  2. Las instancias de NSX Manager pueden compartirse entre varios clústeres o bases, respectivamente. Solo se puede migrar un clúster o una base a Directiva a la vez que comparten los mismos NSX Manager.
  3. Todas las secciones de DFW creadas manualmente que estén entre las secciones creadas por NCP se deben mover fuera del rango de secciones de DFW creadas por NCP. Consulte Trabajar con secciones de DFW creadas por el usuario admin de NSX.
  4. Todas las reglas creadas por el usuario que estén dentro de las secciones creadas por NCP se deben mover fuera de las secciones creadas por NCP. Consulte Trabajar con secciones de DFW creadas por el usuario admin de NSX.
  5. Los servidores virtuales del equilibrador de carga creados por NCP en el modo Manager no deben tener más de 255 reglas. Eso significa que Kubernetes no debe tener más de 255 reglas de entrada en el equilibrador de carga predeterminado. Si hay más de 255 reglas de entrada, deberá dividir la entrada en varias CRD del equilibrador de carga mientras NCP se ejecuta en modo Manager.
  6. Si utiliza el equilibrador de carga frente a UA de NSX, debe asociar un perfil de persistencia de IP de origen en el equilibrador de carga para que todas las llamadas de API realizadas durante la migración por el script lleguen al mismo dispositivo NSX. Este perfil de persistencia debe eliminarse después de migrar todas las bases o los clústeres a la API de Directiva

Limitaciones y advertencias

  1. Aún no se admiten los escenarios en los que los NSX Manager se comparten entre los clústeres de TAS, TKGI y la versión básica de Kubernetes (Vanilla). Por ejemplo, cuando se utilizan los mismos nodos de NSX Manager para ejecutar 1 o más bases y 1 o más clústeres de TKGI.
  2. Después de migrar y reiniciar NCP en el modo Directiva, NCP conciliará la carga de trabajo existente en la base de TAS o el clúster de TKGI con NSX. El tiempo de reconciliación es proporcional al tamaño de carga de trabajo existente. Durante la reconciliación, es posible que se produzcan errores en operaciones como la creación de una instancia de aplicación o un pod, y que también se produzcan retrasos significativos en la creación o la eliminación de recursos de NSX asignados a entidades de TAS y TKGI. Para bases o clústeres muy grandes, donde el uso de recursos de NCP está cerca de los límites de escala, se recomienda agregar al menos 45 minutos a la ventana de mantenimiento para permitir que NCP se concilie con el back-end. NCP volverá a intentar automáticamente sincronizar las operaciones fallidas después de que se complete la reconciliación.

Detalles del proceso

Existen dos categorías de recursos de NSX que se migran cuando se migra un clúster de Kubernetes/TKGI o una base de TAS al modo Directiva:
  1. Recursos de NSX compartidos: el administrador crea manualmente estos recursos de NSX y se proporcionan a NCP a través de la interfaz de usuario de Ops Manager en TAS/TKGI o el mapa de configuración de Kubernetes nsx-ncp-config en la versión básica de Kubernetes (Vanilla). Pueden compartirse entre las bases y los clústeres. Deben especificarse manualmente antes de que comience la migración de la base o el clúster en un archivo YAML denominado user-spec (consulte Ejemplo user-spec.yaml)
  2. Recursos de NSX creados por NCP: NCP crea estos recursos de NSX en respuesta a las cargas de trabajo de base/clúster. Se deducen automáticamente durante la migración

NOTA: El pod de NCP puede funcionar en modo Manager solo cuando todos los recursos de NSX creados por NCP estén en modo Manager. Del mismo modo, el pod de NCP puede funcionar en modo Directiva solo cuando todos los recursos de NSX creados por NCP estén en modo Directiva.

La migración de clústeres de la versión básica de Kubernetes (Vanilla) se basa en el trabajo de Kubernetes denominado "nsx-ncp-migrate-mp2p", y los clústeres de TKGI y las bases de TAS se basan en la tarea denominada "migrate-mp2p". Este trabajo o tarea ejecuta un programa de Python para migrar los recursos de NSX compartidos o creados por NCP. El programa de Python se ejecuta en dos modos: migración (consulte la sección "Fases de migración") y reversión (consulte la sección "Modo de reversión"). Antes de que se active la tarea o el trabajo, primero debe detener NCP en todos los clústeres que compartan la red NSX (clústeres de Manager y Directiva) y, a continuación, crear una copia de seguridad NSX. Se proporcionan pasos detallados para migrar un clúster de Kubernetes o una base de TAS.

Modo de migración

El modo de migración se ejecuta en 4 fases separadas lógicamente.

Fase 1

Recupere todos los recursos de NSX de la API de Manager mediante la API de búsqueda. Filtre los recursos en función de la etiqueta de clúster (al migrar recursos creados por NCP) o los recursos compartidos especificados en el archivo de especificación de usuario (al migrar recursos compartidos). Comience a hacer que los cuerpos de solicitud se envíen al servidor de migración. Si no se puede generar ninguna solicitud, no se migra ningún recurso de NSX.

Posibles problemas:
  • Problemas de conectividad con NSX
  • El servidor de API de Kubernetes no contiene un recurso necesario para migrar un recurso de NSX Manager

Fase 2

Comience a enviar las solicitudes de migración creadas en la fase 1 al servicio coordinador de migración que se ejecuta en NSX. Una vez que NSX haya procesado correctamente una solicitud, almacene los identificadores de MP de los recursos de NSX que se migraron a través de la solicitud en el disco local (se denominan "registros de migración"). Si ocurre un problema, el programa revierte todos los recursos de NSX que se migraron durante la ejecución actual al modo Manager mediante sus identificadores de MP almacenados en el disco local.

Posibles problemas:
  • Problemas de conectividad con NSX
  • Error en la API de migración

Fase 3

Deduzca las actualizaciones que se deben realizar en los recursos de NSX migrados en la ejecución actual. Solo abarcan las actualizaciones en etiquetas o nombres para mostrar de los recursos de NSX. Si no se puede deducir una actualización (el motivo podría ser que falte el recurso de Kubernetes correspondiente), se revierten todos los recursos de NSX.

Posibles problemas:
  • Problemas de conectividad con NSX.
  • El servidor de API de Kubernetes no contiene un recurso necesario para actualizar un recurso de directiva de NSX.

Fase 4

Actualice los recursos de Directiva de NSX con la información inferida en la fase 3. Si no se puede actualizar un recurso de NSX en ese momento, almacene el cuerpo del recurso de directiva y la URL del recurso de directiva actualizados en el disco local.

Posibles problemas:
  • Problemas de conectividad con NSX.

Consulte la sección "Errores y recuperación" si se produce algún problema durante la migración.

Modo de reversión

En este modo, el programa de Python intenta revertir todos los recursos de NSX cuyos identificadores de MP están presentes en los registros de migración en el almacenamiento local (consulte la fase 2 de la migración). Eliminará los registros de migración de los recursos de NSX una vez que se reviertan correctamente. Si se produce un error durante la reversión, la ejecución se detendrá y se deberá volver a ejecutar la tarea o el trabajo.

Tan pronto como se inicie el programa, se ejecutará automáticamente en modo de reversión si encuentra registros de migración en el almacenamiento local (consulte la fase 2 de la migración).

Error y recuperación

Es posible que el proceso de migración no pueda completarse correctamente debido a un problema externo, como un fallo de alimentación, un agotamiento del disco, problemas de conectividad, problemas funcionales, etc. En esos casos, existen formas de recuperación.

Le recomendamos que primero compruebe los registros de la migración de la tarea o el trabajo. Es probable que indiquen la siguiente acción que se debe realizar. Puede ser una de los siguientes:
  • (Resolución predeterminada si los registros no lo indican) Vuelva a ejecutar el trabajo o la tarea de migración.
    • Si se produjo el error anterior en las fases 1, 2 o 3, el trabajo o la tarea de migración intentarán revertir los recursos de NSX mediante los registros de migración (consulte la fase 2). Se debe realizar hasta que se reviertan todos los recursos de NSX.
    • Si se produjo el error anterior en la fase 4, el trabajo o la tarea de migración volverán a intentar actualizar los recursos de NSX en el modo Directiva. Esto se debe realizar hasta que todos los recursos de NSX se actualicen correctamente.
  • Ejecute NCP en el modo Manager y, a continuación, vuelva a intentar la migración. Si el trabajo o la tarea de migración no pueden migrar el clúster, NCP debe volver a ejecutarse en este clúster/base en modo Manager. Sin embargo, se anulará la copia de seguridad de NSX. Por lo tanto, omita temporalmente la migración de este clúster. Una vez que los demás clústeres se migren al modo Directiva, inicie NCP en modo Manager en este clúster y el modo Directiva en los demás. Espere al menos 60 minutos y, a continuación, vuelva a seguir los pasos de migración desde el principio para volver a intentar la migración del clúster.

En caso de que la recuperación no sea posible con los pasos anteriores, restaure NSX Manager al punto de copia de seguridad anterior creado antes de migrar cualquier clúster a Directiva, reinicie NCP en todos los clústeres en el mismo modo cuando se realizó la copia de seguridad de NSX e intente migrar de nuevo.