Actualizar Apstra en una nueva máquina virtual (VM-VM) (recomendado)

Le recomendamos que actualice Apstra en una nueva máquina virtual (en lugar de in situ en la misma máquina virtual) para que reciba correcciones del sistema operativo Ubuntu Linux, incluidas actualizaciones de vulnerabilidades de seguridad. Para actualizar el servidor de Apstra, necesita privilegios de usuario administrador de Apstra OS y permisos de grupo de usuarios administradores de Apstra.

Paso 1: Validación previa a la actualización

Consulte Rutas de actualización para confirmar que está actualizando a una versión compatible. (Puede encontrar su versión actual de Apstra navegando a Platform > About en la GUI de Apstra. A partir de la versión 4.2.1 de Apstra, la versión de Apstra también se muestra en el menú de navegación izquierdo de la GUI bajo el logotipo de Juniper Apstra).
Inicie sesión en el servidor de Apstra como administrador (por ejemplo, si la dirección IP del servidor de Apstra fuera 10.28.105.3, el comando sería ssh admin@10.28.105.3).

Ejecute el comando service aos status para comprobar que el servidor está activo y no tiene problemas.

Consulte las notas de la versión de la nueva versión de Apstra para conocer los cambios en la representación de la configuración que podrían afectar al plano de datos.
Revise cada plano para confirmar que toda la configuración del servicio está en el estado CORRECTO. Si es necesario, anule la implementación y elimine los dispositivos del plano para resolver cualquier configuración de servicio pendiente o fallida.
Revise cada plano en busca de anomalías de sonda y resuélvalas tanto como sea posible. Tome nota de cualquier anomalía restante.
Consulte la Guía del usuario de Apstra (Referencias > dispositivos > dispositivos calificados y versiones de NOS) para verificar que los modelos de dispositivos y las versiones de NOS estén calificados en la nueva versión de Apstra. Actualice o degrade según sea necesario a una de las versiones compatibles. (A partir de la versión 4.2.0 de Apstra, Apstra dejó de usar EX4300s. A partir de la versión 4.2.1 de Apstra, si los EX4300 están presentes en los planos activos, la actualización está bloqueada).
Si utiliza dispositivos Junos y actualiza a la versión 4.2.1 de Apstra, la configuración prístina debe incluir lo esencial mgmt_junos VRF. Consulte el artículo de la Base de conocimientos de soporte de Juniper KB77094 para obtener más información.

CAUTELA:

Si la configuración prístina no incluye el VRF, se producirá un mgmt_junos error en la implementación.
Elimine cualquier configuración AAA del dispositivo. Durante la actualización del dispositivo, se requieren credenciales de agente de dispositivo configuradas para el acceso SSH.
Quite los configlets utilizados para configurar los firewalls. Si usa filtros de motor de enrutamiento de FW en dispositivos, deberá actualizarlos para incluir la dirección IP del nuevo controlador y las máquinas virtuales de trabajo.
Para actualizar los agentes del sistema de dispositivos, Apstra debe poder usar SSH en todos los dispositivos con las credenciales que se configuraron al crear los agentes. Para verificar esto desde la GUI de Apstra, vaya a Dispositivos > agentes, seleccione las casillas de verificación de los dispositivos que desea verificar y, a continuación, haga clic en el botón Verificar en el menú Agente. Verifique que el estado de todos los trabajos sea CORRECTO. Si algún trabajo de comprobación falla, resuelva el problema antes de continuar con la actualización de Apstra.
Como usuario raíz, ejecute el comando sudo aos_backup para realizar una copia de seguridad del servidor de Apstra.
CAUTELA:

El servidor de Apstra actualizado no incluye ninguna revisión de Time Voyager, por lo que si necesita volver a un estado pasado, se requiere esta copia de seguridad. Los estados anteriores no se incluyen debido al estrecho acoplamiento con los diseños de referencia que pueden cambiar entre las versiones de Apstra.
Copie los archivos de copia de seguridad desde /var/lib/aos/snapshot/<shapshot_name> una ubicación externa.
Asegúrese de que la nueva máquina virtual tenga los recursos de servidor necesarios para el servidor de Apstra.

Paso 2: Implementar el nuevo servidor de Apstra

Nota:

Si personalizó el /etc/aos/aos.conf archivo en el antiguo servidor de Apstra (por ejemplo, si actualizó el metadb campo para usar una interfaz de red diferente), debe volver a aplicar los cambios al mismo archivo en la nueva máquina virtual del servidor de Apstra. No se migra automáticamente.

Como usuario de soporte registrado, descargue la imagen de máquina virtual de Apstra de Descargas de soporte de Juniper (for example, aos_server_4.1.2-269) y transfiérala al nuevo servidor de Apstra.
Instale y configure la nueva imagen de máquina virtual de Apstra con la nueva dirección IP (se puede usar el mismo FQDN o el nuevo).
Si utiliza un clúster de Apstra (agentes externos, sondeos IBA) y va a reutilizar las máquinas virtuales de trabajo, instale el nuevo software ejecutando sudo bash aos_<aos_version>.run. Si usa máquinas virtuales de trabajo nuevas, omita este paso.

Nota:
Ejemplo de reemplazo de todas las máquinas virtuales: si tiene un controlador y 2 nodos de trabajo y desea actualizarlos todos a nuevas máquinas virtuales, debe crear 3 máquinas virtuales con la nueva versión de Apstra y designar una de ellas para que sea el controlador.
Verifique que el nuevo servidor de Apstra tenga acceso SSH al servidor de Apstra antiguo.
Verifique que el nuevo servidor de Apstra pueda comunicarse con los agentes del sistema. (Consulte Puertos de comminicación necesarios.)
Verifique que el nuevo servidor de Apstra pueda llegar a los sistemas externos aplicables (como NTP, DNS, servidor vSphere, servidor LDAP/TACACs+, etc.).

Paso 3: Estado de importación

CAUTELA:

Si realiza alguna operación de escritura de API/GUI en el antiguo servidor de Apstra después de haber comenzado a importar la nueva máquina virtual, esos cambios no se copiarán en el nuevo servidor de Apstra.

Inicie sesión en el nuevo servidor de Apstra como usuario administrador.
Ejecute el comando para importar SysDB desde el servidor antiguo, aplicar las sudo aos_import_state traducciones necesarias e importar la configuración. Incluya los siguientes argumentos, según corresponda:
- --ip-address <old-apstra-server-ip>
- --username <admin-username>
- Para los clústeres de Apstra con nuevas direcciones IP de nodo de trabajo, incluya lo siguiente: --cluster-node-address-mapping <old-node-ip> <new-node-ip>
- Para ejecutar las comprobaciones de condiciones previas de actualización sin ejecutar la actualización real, use lo siguiente:--dry-run-connectivity-validation
- Para no comprobar la validación de conectividad, incluya lo siguiente: --skip-connectivity-validation
- Si las credenciales SSH en su versión anterior de Apstra no son tan estrictas como los requisitos para la nueva versión de Apstra, debe agregar el --override-cluster-node-credentials argumento al aos_import_state comando al importar su base de datos a la nueva versión de Apstra. De lo contrario, se producirá un error en la actualización.
Comando de ejemplo: VM única o clúster de Apstra con los mismos nodos de trabajo
Comando de ejemplo: clúster de Apstra con nuevos nodos de trabajo
En el ejemplo anterior, 10.28.105.4 y 10.28.105.7 son direcciones IP de nodo de trabajo antiguas; 10.28.105.6 y 10.28.105.8 son direcciones IP de nodo de trabajo nuevas.
La raíz es necesaria para importar la base de datos, por lo que se le pedirá la contraseña SSH y la contraseña raíz para la máquina virtual remota de Apstra.

Nota:
Cuando actualiza un clúster de Apstra, la contraseña SSH para el controlador antiguo, el trabajador antiguo y el trabajador nuevo debe ser idéntica; de lo contrario, la actualización no superará la autenticación. En el ejemplo anterior, la contraseña que escriba para 'Contraseña SSH para máquina virtual AOS remota' se usa para máquinas virtuales de control remoto, antiguo trabajador y nuevo trabajador. (AOS-27351)

Si cambia la contraseña SSH de las máquinas virtuales de trabajo después de la actualización, también debe actualizar la contraseña del trabajador en la GUI de Apstra (nodos de > de clúster de plataforma > Apstra).

Nota:
El tamaño del plano y de los recursos de máquina virtual del servidor de Apstra determinan cuánto tiempo se tarda en completar la importación. Si la importación de la base de datos supera el valor predeterminado, es posible que se agote el tiempo de espera de la operación. (El valor predeterminado a partir de Apstra 4.1.2 es 40 min o 2400 segundos). Si esto sucede, puede aumentar el valor de tiempo de espera con el AOS_UPGRADE_DOCKER_EXEC_TIMEOUT comando.

Por ejemplo, el siguiente comando aumenta el tiempo antes de que se agote el tiempo de espera a 2 horas (7200 segundos).
admin@aos-server:~$ sudo AOS_UPGRADE_DOCKER_EXEC_TIMEOUT=7200 aos_import_state --ip-address 10.10.10.10 --username admin

El script de actualización presenta una vista resumida de los dispositivos dentro de la estructura que recibirán cambios de configuración durante la actualización. A partir de la versión 4.1.2 de Apstra, aparece una advertencia en la pantalla que recomienda leer la documentación de las notas de la versión y las rutas de actualización antes de continuar. Las notas de la versión incluyen una categoría para Cambios en la representación de la configuración, a partir de la versión 4.1.2 de Apstra. Los cambios en la representación de la configuración se documentan claramente en la parte superior, lo que explica el impacto de cada cambio en la red.
A partir de la versión 4.0.1 de Apstra, el resumen de actualización de Apstra muestra información separada por roles de dispositivo (superspine, spine, leaf, par de hojas y conmutador de acceso, por ejemplo). Si se aplicó una configuración incremental en lugar de una configuración completa, se muestran más detalles sobre los cambios.
Después de revisar el resumen, escriba q para salir del resumen. Aparece el menú interactivo Actualización de AOS: donde puede revisar el cambio de configuración exacto en cada dispositivo. Si usa configlets, compruebe que la nueva configuración implementada por la actualización no entre en conflicto con ninguna de las existentes.
CAUTELA:

Es posible que el diseño de referencia de Apstra de la nueva versión de Apstra haya cambiado de una manera que invalida los configlets. Para evitar resultados inesperados, compruebe que los configlets no entren en conflicto con la configuración recién representada. Si necesita actualizar los configlets, salga de la actualización, actualice los configlets y vuelva a ejecutar la actualización.
Si desea continuar con la actualización después de revisar los cambios pendientes, escriba c.
Si desea detener la actualización, ingrese q para anular el proceso. Si abandona en este punto y luego decide actualizar, debe iniciar el proceso desde el principio.

Nota:
Si la actualización de Apstra falla (o en el caso de algún otro mal funcionamiento), puede apagar correctamente el nuevo servidor de Apstra y reiniciar el antiguo servidor de Apstra para continuar con las operaciones.

Paso 4: Mantener la dirección IP de la máquina virtual antigua (opcional)

Si desea conservar la dirección IP de la máquina virtual antigua, debe realizar los siguientes pasos adicionales antes de cambiar el modo de operación y actualizar el agente del dispositivo.

Apague la máquina virtual antigua o cambie su dirección IP a una dirección diferente para liberar la dirección IP. Esto es necesario para evitar cualquier problema de dirección IP duplicada.
Vaya al menú interactivo de Apstra de la nueva máquina virtual desde la CLI.
Haga clic en Red para actualizar la dirección IP y confirmar los demás parámetros.
Para que la nueva dirección IP surta efecto, reinicie el servicio de red, ya sea desde el mismo menú antes de salir o desde la CLI después de salir del menú.

Paso 5: Cambiar el modo de operación a normal

Cuando inicia una actualización del servidor de Apstra, el modo de operación cambia de Normal a Mantenimiento automáticamente. El modo de mantenimiento evita que los agentes de la bandeja de salida se conecten prematuramente. No se inserta ninguna configuración ni se extrae telemetría. En este punto, si decide continuar usando la versión anterior de Apstra en lugar de actualizar, puede simplemente apagar el nuevo servidor de Apstra. Si decide completar la actualización, vuelva a cambiar el modo a Normal.

Inicie sesión en la GUI de Apstra.
Si desea ver los cambios pendientes en la configuración del servicio, vaya al panel del plano y haga clic en PENDIENTE para ver los dispositivos afectados.
En el menú de navegación izquierdo, vaya a Platform > Apstra Cluster > Cluster Management.
Haga clic en el botón Cambiar modo de operación, seleccione Normal y, a continuación, haga clic en Actualizar. Todos los agentes externos, ya sea que estén en el controlador o en las máquinas virtuales de trabajo, se conectan automáticamente y vuelven a conectar dispositivos y envían cualquier cambio de configuración pendiente. Después de unos momentos, las anomalías temporales en el panel se resuelven y la sección de configuración del servicio muestra que la operación se ha REALIZADO CORRECTAMENTE.

También puede acceder a la página Administración de clústeres desde la sección inferior izquierda de cualquier página. También tiene una visibilidad continua del estado de la plataforma desde aquí, basada en colores.

En la parte inferior del menú de navegación izquierdo, haga clic en uno de los puntos y, a continuación, haga clic en Modo de operación para ir a Administración de clústeres. Haga clic en el botón Cambiar modo de operación , seleccione Normal y, a continuación, haga clic en Actualizar.

Paso 6: Actualizar los agentes de la bandeja de entrada

El servidor de Apstra y los agentes de la bandeja de entrada deben ejecutar la misma versión de Apstra. Si las versiones son diferentes, los agentes no se conectarán al servidor de Apstra.

Si está ejecutando un plano de varios estados, especialmente de 5 etapas, le recomendamos que actualice los agentes por etapas: primero actualice superspines, luego spines, luego leafs. Recomendamos este orden debido a la búsqueda de rutas. En lugar de enrutar todo hasta una columna vertebral, o de una columna vertebral a una superespina, es posible que el enrutamiento vaya temporalmente de hoja a columna vertebral hacia abajo a otra hoja y de vuelta a otra columna vertebral. Para minimizar las posibilidades de que esto suceda, recomendamos actualizar los dispositivos por etapas.

Inicie sesión en la GUI de Apstra como usuario administrador.
En el menú de navegación izquierdo, vaya a Dispositivos > dispositivos administrados y seleccione las casillas de verificación de los dispositivos que desea actualizar (hasta 100 dispositivos a la vez). Puede actualizar varios agentes de la bandeja de entrada al mismo tiempo, pero el orden de actualización del dispositivo es importante.
- Actualice primero los agentes para superspines.
- Agentes de actualización para espinas en segundo lugar.
- Agentes de actualización para hojas de tercero.
Al seleccionar uno o más dispositivos, los menús Dispositivo y Agente aparecen encima de la tabla.
Haga clic en el botón Instalar para iniciar el proceso de instalación.

El estado del trabajo cambia a EN CURSO. Si los agentes utilizan una versión anterior del software de Apstra, se actualizan automáticamente a la nueva versión. Luego se conectan al servidor y envían cualquier cambio de configuración pendiente a los dispositivos. La telemetría también se reanuda y los estados de trabajo cambian a CORRECTO.
En la sección Liveness del panel de control del plano, confirme que no hay anomalías en el dispositivo.

Nota:
Si necesita revertir a la versión anterior de Apstra después de iniciar la actualización del agente, debe crear una nueva máquina virtual con la versión anterior de Apstra y restaurar la configuración en esa máquina virtual. Para obtener ayuda, comuníquese con el Soporte técnico de Juniper.

Paso 7: Apagar el antiguo servidor de Apstra

Actualice las entradas DNS para usar la nueva IP/FQDN del servidor de Apstra según su configuración.
Si utiliza un proxy para el servidor de Apstra, asegúrese de que apunte al nuevo servidor de Apstra.
Apague correctamente el antiguo servidor de Apstra. A partir de la versión 4.2.1 de Apstra, se le habrá preguntado si desea que se cierre el antiguo servidor de Apstra; si respondió que sí, el service aos stop comando se ejecuta automáticamente para apagar el antiguo servidor de Apstra.
Si está actualizando un clúster de Apstra y ha reemplazado los nodos de trabajo por máquinas virtuales nuevas, cierre también las antiguas máquinas virtuales de trabajo.

Próximos pasos:

Si las versiones NOS de sus dispositivos no están calificadas en la nueva versión de Apstra, actualícelas a una versión calificada. (Consulte la Guía del usuario de Juniper Apstra para obtener más información).