Mettre à niveau Apstra sur une nouvelle VM (VM-VM) (recommandé)

Nous vous recommandons de mettre à niveau Apstra sur une nouvelle machine virtuelle (plutôt que sur place sur la même machine virtuelle) afin de recevoir les correctifs du système d'exploitation Linux Ubuntu, y compris les mises à jour des vulnérabilités de sécurité. Pour mettre à niveau le serveur Apstra, vous devez disposer des droits d’utilisateur administrateur du système d’exploitation Apstra et des autorisations de groupe d’utilisateurs administrateurs Apstra.

Étape 1 : Validation préalable à la mise à niveau

Reportez-vous à la section Chemins de mise à niveau pour confirmer que vous effectuez une mise à niveau vers une version prise en charge. (Vous pouvez trouver votre version actuelle d’Apstra en accédant à Platform > About dans l’interface graphique d’Apstra. À partir de la version 4.2.1 d’Apstra, la version d’Apstra est également affichée dans le menu de navigation gauche de l’interface graphique sous le logo Juniper Apstra.)
Connectez-vous au serveur Apstra en tant qu’administrateur (par exemple, si l’adresse IP de votre serveur Apstra est 10.28.105.3, la commande serait ssh admin@10.28.105.3).

Exécutez la commande service aos status pour vérifier que le serveur est actif et qu’il n’y a pas de problèmes.

Consultez les notes de mise à jour de la nouvelle version d’Apstra pour connaître les modifications de rendu de la configuration qui pourraient avoir un impact sur le plan de données.
Passez en revue chaque blueprint pour confirmer que toutes les configurations de service sont à l’état SUCCEEDED. Si nécessaire, annulez le déploiement et supprimez les périphériques du blueprint pour résoudre toute configuration de service en attente ou défaillante.
Examinez chaque blueprint pour détecter les anomalies de la sonde et résolvez-les autant que possible. Prenez note de toute anomalie restante.
Référez-vous au Guide de l’utilisateur d’Apstra (Références > équipements > équipements qualifiés et versions de NOS) pour vérifier que les modèles d’équipements et les versions de NOS sont qualifiés sur la nouvelle version d’Apstra. Effectuez si nécessaire une mise à niveau ou une rétrogradation vers l’une des versions prises en charge. (À partir de la version 4.2.0 d’Apstra, Apstra a abandonné les EX4300. À partir de la version 4.2.1 d’Apstra, si des EX4300 sont présents dans des blueprints actifs, la mise à niveau est bloquée.)
Si vous utilisez des équipements Junos et que vous effectuez une mise à niveau vers Apstra 4.2.1, la configuration parfaite doit inclure les éléments essentiels mgmt_junos VRF. Pour plus d’informations, consultez l’article KB77094 de la base de connaissances d’assistance Juniper.

PRUDENCE:

Si la configuration vierge n'inclut pas le mgmt_junos VRF, le déploiement échouera.
Supprimez toute configuration AAA de l’appareil. Lors de la mise à niveau de l’appareil, les informations d’identification de l’agent d’appareil configurées sont requises pour l’accès SSH.
Supprimez tous les configlets utilisés pour configurer les pare-feu. Si vous utilisez les filtres du moteur de routage du micrologiciel sur des appareils, vous devez les mettre à jour pour inclure l'adresse IP du nouveau contrôleur et des machines virtuelles de travail.
Pour mettre à niveau les agents système des périphériques, Apstra doit être en mesure d’utiliser un SSH sur tous les périphériques à l’aide des informations d’identification configurées lors de la création des agents. Pour le vérifier à partir de l’interface graphique d’Apstra, accédez à Appareils > agents, cochez la ou les cases correspondant au(x) appareil(s) à cocher, puis cliquez sur le bouton Vérifier dans le menu Agent. Vérifiez que l’état de toutes les tâches est SUCCESS. En cas d’échec d’une tâche de vérification, résolvez le problème avant de procéder à la mise à niveau d’Apstra.
En tant qu’utilisateur root, exécutez la commande sudo aos_backup pour sauvegarder le serveur Apstra.
PRUDENCE:

Le serveur Apstra mis à niveau n'inclut aucune révision de Time Voyager, donc si vous avez besoin de revenir à un état antérieur, cette sauvegarde est nécessaire. Les états précédents ne sont pas inclus en raison du couplage étroit avec les conceptions de référence, qui peut changer entre les versions d’Apstra.
Copiez les fichiers de sauvegarde à partir d’un /var/lib/aos/snapshot/<shapshot_name> emplacement externe.
Assurez-vous que la nouvelle machine virtuelle dispose des ressources serveur requises pour le serveur Apstra.

Étape 2 : Déployer un nouveau serveur Apstra

Note:

Si vous avez personnalisé le /etc/aos/aos.conf fichier dans l’ancien serveur Apstra (par exemple, si vous avez mis à jour le metadb champ pour utiliser une autre interface réseau), vous devez réappliquer les modifications au même fichier dans la nouvelle machine virtuelle du serveur Apstra. La migration n'est pas automatique.

En tant qu’utilisateur d’assistance enregistré, téléchargez l’image de la machine virtuelle Apstra depuis Juniper Support Downloads (for example, aos_server_4.1.2-269) et transférez-la sur le nouveau serveur Apstra.
Installez et configurez la nouvelle image de machine virtuelle Apstra avec la nouvelle adresse IP (le même nom de domaine complet ou un nouveau nom de domaine complet peut être utilisé).
Si vous utilisez un cluster Apstra (agents offbox, sondes IBA) et que vous comptez réutiliser vos machines virtuelles de travail, installez le nouveau logiciel en exécutant sudo bash aos_<aos_version>.run. Si vous utilisez de nouvelles machines virtuelles de travail, ignorez cette étape.

Note:
Exemple de remplacement de toutes les machines virtuelles : si vous disposez d’un contrôleur et de 2 nœuds de travail et que vous souhaitez tous les mettre à niveau vers de nouvelles machines virtuelles, vous devez créer 3 machines virtuelles avec la nouvelle version d’Apstra et désigner l’une d’entre elles comme contrôleur.
Vérifiez que le nouveau serveur Apstra dispose d’un accès SSH à l’ancien serveur Apstra.
Vérifiez que le nouveau serveur Apstra peut accéder aux agents système. (Voir Ports de communication requis.)
Vérifiez que le nouveau serveur Apstra peut accéder aux systèmes externes applicables (tels que NTP, DNS, serveur vSphere, serveur LDAP/TACACs+, etc.).

Étape 3 : État de l’importation

PRUDENCE:

Si vous effectuez des opérations d'écriture d'API/GUI sur l'ancien serveur Apstra après avoir commencé à importer la nouvelle machine virtuelle, ces modifications ne seront pas copiées sur le nouveau serveur Apstra.

Connectez-vous au nouveau serveur Apstra en tant qu’administrateur utilisateur.
Exécutez la sudo aos_import_state commande pour importer SysDB à partir de l’ancien serveur, appliquer les traductions nécessaires et importer la configuration. Incluez les arguments suivants, le cas échéant :
- --ip-address <old-apstra-server-ip>
- --username <admin-username>
- Pour les clusters Apstra avec de nouvelles adresses IP de nœud de travail, incluez les éléments suivants : --cluster-node-address-mapping <old-node-ip> <new-node-ip>
- Pour exécuter les vérifications des conditions préalables de mise à niveau sans exécuter la mise à niveau proprement dite, procédez comme suit :--dry-run-connectivity-validation
- Pour ne pas vérifier la validation de la connectivité, incluez les éléments suivants : --skip-connectivity-validation
- Si les informations d’identification SSH de votre ancienne version d’Apstra ne sont pas aussi strictes que celles de la nouvelle version d’Apstra, vous devez ajouter l’argument --override-cluster-node-credentials à la aos_import_state commande lors de l’importation de votre base de données dans la nouvelle version d’Apstra. Dans le cas contraire, la mise à niveau échouera.
Exemple de commande : VM unique ou cluster Apstra avec les mêmes nœuds de travail
Exemple de commande : cluster Apstra avec de nouveaux nœuds de travail
Dans l’exemple ci-dessus, 10.28.105.4 et 10.28.105.7 sont les anciennes adresses IP des nœuds de travail ; 10.28.105.6 et 10.28.105.8 sont les nouvelles adresses IP des nœuds de travail.
La racine est requise pour l'importation de la base de données, vous serez donc invité à saisir le mot de passe SSH et le mot de passe root de la machine virtuelle Apstra distante.

Note:
Lorsque vous mettez à niveau un cluster Apstra, le mot de passe SSH de l’ancien contrôleur, de l’ancien et du nouveau worker doit être identique, sinon l’authentification de la mise à niveau échoue. Dans l'exemple ci-dessus, le mot de passe que vous entrez pour « Mot de passe SSH pour la machine virtuelle AOS distante » est utilisé pour les machines virtuelles de travail distantes, les anciennes et les nouvelles machines virtuelles de travail. (AOS-27351)

Si vous modifiez le mot de passe SSH des machines virtuelles de travail après la mise à niveau, vous devez également mettre à jour le mot de passe du travailleur dans l'interface graphique d'Apstra (plate-forme > cluster Apstra > nœuds).

Note:
La taille du blueprint et les ressources de la machine virtuelle du serveur Apstra déterminent le temps nécessaire pour terminer l’importation. Si l'importation de la base de données dépasse la valeur par défaut, l'opération peut expirer. (La valeur par défaut à partir d’Apstra 4.1.2 est de 40 min ou 2400 secondes). Si cela se produit, vous pouvez augmenter la valeur du délai d’expiration à l’aide de la AOS_UPGRADE_DOCKER_EXEC_TIMEOUT commande.

Par exemple, la commande suivante augmente le délai avant le délai d’expiration à 2 heures (7200 secondes).
admin@aos-server:~$ sudo AOS_UPGRADE_DOCKER_EXEC_TIMEOUT=7200 aos_import_state --ip-address 10.10.10.10 --username admin

Le script de mise à niveau présente une vue récapitulative des équipements de la structure qui recevront des modifications de configuration lors de la mise à niveau. À partir de la version 4.1.2 d’Apstra, un avertissement s’affiche à l’écran vous recommandant de lire les notes de mise à jour et la documentation sur les chemins de mise à niveau avant de continuer. Les notes de mise à jour incluent une catégorie pour les modifications du rendu de la configuration, à partir de la version 4.1.2 d’Apstra. Les modifications apportées au rendu de la configuration sont clairement documentées en haut, expliquant l’impact de chaque modification sur le réseau.
À partir de la version 4.0.1 d’Apstra, le récapitulatif de mise à niveau d’Apstra affiche des informations séparées par rôles d’équipement (superspine, spine, leaf, paire de feuilles et commutateur d’accès, par exemple). Si une configuration incrémentielle a été appliquée au lieu d’une configuration complète, plus de détails s’affichent sur les modifications.
Une fois que vous avez examiné le récapitulatif, entrez q pour quitter le récapitulatif. Le menu interactif Mise à niveau d’AOS s’affiche et vous permet de vérifier la modification exacte de la configuration sur chaque appareil. Si vous utilisez des configlets, vérifiez que la nouvelle configuration envoyée par la mise à niveau n'entre pas en conflit avec les configlets existants.
PRUDENCE:

La conception de référence d’Apstra dans la nouvelle version d’Apstra peut avoir changé d’une manière qui invalide les configlets. Pour éviter les résultats inattendus, vérifiez que vos configlets n’entrent pas en conflit avec la configuration nouvellement rendue. Si vous devez mettre à jour vos configlets, quittez la mise à niveau, mettez à jour vos configlets, puis exécutez à nouveau la mise à niveau.
Si vous souhaitez poursuivre la mise à niveau après avoir examiné les modifications en attente, entrez c.
Si vous souhaitez arrêter la mise à niveau, entrez q pour abandonner le processus. Si vous quittez à ce stade et décidez plus tard de mettre à niveau, vous devez recommencer le processus depuis le début.

Note:
En cas d’échec de la mise à niveau d’Apstra (ou de dysfonctionnement), vous pouvez arrêter le nouveau serveur Apstra et redémarrer l’ancien pour poursuivre les opérations.

Étape 4 : Conserver l'adresse IP de l'ancienne VM (facultatif)

Si vous souhaitez conserver l'adresse IP de l'ancienne machine virtuelle, vous devez effectuer les étapes supplémentaires suivantes avant de modifier le mode de fonctionnement et de mettre à niveau l'agent des périphériques.

Arrêtez l’ancienne machine virtuelle ou remplacez son adresse IP par une autre adresse pour libérer l’adresse IP. Ceci est nécessaire pour éviter tout problème d’adresse IP dupliquée.
Accédez au menu interactif Apstra de la nouvelle machine virtuelle à partir de l'interface de ligne de commande.
Cliquez sur Réseau pour mettre à jour l’adresse IP et confirmer les autres paramètres.
Pour que la nouvelle adresse IP prenne effet, redémarrez le service réseau, soit à partir du même menu avant de quitter, soit à partir de la CLI après avoir quitté le menu.

Étape 5 : Changez le mode de fonctionnement en mode normal

Lorsque vous lancez une mise à niveau du serveur Apstra, le mode de fonctionnement passe automatiquement de Normal à Maintenance . Le mode de maintenance empêche les agents hors boîtier de se connecter prématurément. Aucune configuration n’est envoyée et aucune télémétrie n’est extraite. À ce stade, si vous décidez de continuer à utiliser la version précédente d’Apstra au lieu de la mettre à niveau, vous pouvez simplement arrêter le nouveau serveur Apstra. Si vous décidez de terminer la mise à niveau, revenez au mode Normal.

Connectez-vous à l’interface graphique d’Apstra.
Si vous souhaitez afficher les modifications apportées à la configuration du service en attente, accédez au tableau de bord du blueprint et cliquez sur EN ATTENTE pour afficher les appareils concernés.
Dans le menu de navigation de gauche, accédez à Platform > Apstra Cluster > Cluster Management.
Cliquez sur le bouton Changer le mode de fonctionnement, sélectionnez Normal, puis cliquez sur Mettre à jour. Tous les agents offbox, qu'ils se trouvent sur le contrôleur ou sur les machines virtuelles de travail, se connectent automatiquement et reconnectent les appareils et transmettent toutes les modifications de configuration en attente. Après quelques instants, les anomalies temporaires sur le tableau de bord se résolvent et la section de configuration du service indique que l’opération a réussi.

Vous pouvez également accéder à la page Gestion des clusters à partir de la section inférieure gauche de n’importe quelle page. À partir de là, vous bénéficiez également d’une visibilité continue sur l’état de la plate-forme, en fonction des couleurs.

En bas du menu de navigation de gauche, cliquez sur l’un des points, puis cliquez sur Mode de fonctionnement pour accéder à Gestion du cluster. Cliquez sur le bouton Changer le mode de fonctionnement , sélectionnez Normal, puis cliquez sur Mettre à jour.

Étape 6 : Mettre à niveau les agents Onbox

Le serveur Apstra et les agents locaux doivent exécuter la même version d’Apstra. Si les versions sont différentes, les agents ne se connecteront pas au serveur Apstra.

Si vous exécutez un blueprint à plusieurs états, en particulier à 5 étapes, nous vous recommandons de mettre à niveau les agents par étapes : d'abord les superépines, puis les épines, puis les branches. Nous recommandons cet ordre en raison de la recherche de chemins. Au lieu de tout router vers une colonne vertébrale, ou d'une colonne vertébrale vers une superdorsale, il est possible que le routage passe temporairement d'une branche à l'autre, puis redescend vers une autre branche et remonte vers une autre dorsale. Pour minimiser les risques que cela se produise, nous vous recommandons de mettre à niveau les appareils par étapes.

Connectez-vous à l’interface graphique d’Apstra en tant qu’administrateur utilisateur.
Dans le menu de navigation de gauche, accédez à Équipements > Appareils gérés et cochez les cases correspondant au(x) appareil(s) à mettre à niveau (jusqu’à 100 appareils à la fois). Vous pouvez mettre à niveau plusieurs agents onbox en même temps, mais l’ordre de mise à niveau de l’appareil est important.
- Mettez d’abord à niveau les agents pour les superspines.
- Mettez à niveau les agents pour les épines en second.
- Agents de mise à niveau pour les branches en troisième position.
Lorsque vous sélectionnez un ou plusieurs périphériques, les menus Device et Agent apparaissent au-dessus du tableau.
Cliquez sur le bouton Installer pour lancer le processus d’installation.

L’état de la tâche passe à EN COURS. Si les agents utilisent une version antérieure du logiciel Apstra, ils sont automatiquement mis à niveau vers la nouvelle version. Ensuite, ils se connectent au serveur et transmettent les modifications de configuration en attente aux appareils. La télémétrie reprend également et les états de travail passent à SUCCESS.
Dans la section Activité du tableau de bord du blueprint, vérifiez qu’il n’y a pas d’anomalies sur l’appareil.

Note:
Si vous devez revenir à la version précédente d’Apstra après avoir lancé la mise à niveau de l’agent, vous devez créer une nouvelle machine virtuelle avec la version précédente d’Apstra et restaurer la configuration sur cette machine virtuelle. Pour obtenir de l’aide, contactez l’assistance technique de Juniper.

Étape 7 : Arrêtez l’ancien serveur Apstra

Mettez à jour toutes les entrées DNS pour utiliser la nouvelle adresse IP/FQDN du serveur Apstra en fonction de votre configuration.
Si vous utilisez un proxy pour le serveur Apstra, assurez-vous qu'il pointe vers le nouveau serveur Apstra.
Arrêtez gracieusement l’ancien serveur Apstra À partir de la version 4.2.1 d’Apstra, il vous sera demandé si vous souhaitez fermer l’ancien serveur Apstra ; si vous avez répondu oui, la commande s’exécute service aos stop automatiquement pour arrêter l’ancien serveur Apstra à votre place.
Si vous mettez à niveau un cluster Apstra et que vous avez remplacé vos nœuds de travail par de nouvelles machines virtuelles, arrêtez également les anciennes machines virtuelles de travail.

Prochaines étapes :

Si les versions NOS de vos équipements ne sont pas qualifiées sur la nouvelle version d’Apstra, mettez-les à niveau vers une version qualifiée. (Reportez-vous au Guide de l’utilisateur Juniper Apstra pour plus de détails.)