Mise à niveau d’Apstra sur une nouvelle VM (VM-VM)

Étape 1 : Validation avant 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. Pour trouver votre version actuelle d’Apstra dans l’interface graphique d’Apstra, regardez dans le coin supérieur gauche du menu de navigation de gauche, 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 sera 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 aucun problème.

Consultez les notes de mise à jour de la nouvelle version d’Apstra pour connaître les modifications de rendu de configuration qui pourraient avoir un impact sur le plan de données.
Passez en revue chaque blueprint pour confirmer que toute la configuration de service est à l’état SUCCEEDED. Si nécessaire, annulez le déploiement et supprimez les équipements du blueprint pour résoudre toute configuration de service en attente ou défaillante.
Examinez chaque plan pour détecter les anomalies de la sonde et résolvez-les autant que possible. Prenez note de toutes les anomalies restantes.
Reportez-vous au Guide de l’utilisateur d’Apstra (Références > équipements > les versions d’équipements et de NOS qualifiés) pour vérifier que les modèles d’équipements et les versions de NOS sont compatibles avec la nouvelle version d’Apstra. Effectuez une mise à niveau ou une rétrogradation selon vos besoins vers l’une des versions prises en charge.
Si vous utilisez des équipements Junos, 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 parfaite n’inclut pas le mgmt_junos VRF, le déploiement échoue.
Supprimez toute configuration AAA de l’appareil. Lors de la mise à niveau de l’appareil, les informations d’identification configurées de l’agent de l’appareil 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 appareils, Apstra doit être en mesure de fournir un SSH à tous les appareils à 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 à Périphériques > Périphériques gérés, cochez la ou les cases correspondant au(x) périphérique(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 interface réseau différente), 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 du service d’assistance enregistré, téléchargez l’image de la machine virtuelle Apstra depuis Juniper Support Downloads (for example, aos_server_5.0.0-63) 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 hors boîtier, 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 atteindre les 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 : Importer l’état

PRUDENCE:

Si vous effectuez des opérations d’écriture d’API/GUI sur l’ancien serveur Apstra après avoir commencé à importer la nouvelle VM, 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>
Entrez le nom d’utilisateur de l’administrateur :
- --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 conserver l’ancien serveur Apstra, ajoutez l’argument keep à la --disable-original-apstra-server {prompt,disable,keep} commande.
  
  Par exemple: --disable-original-apstra-server keep
- 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.
- Pour effectuer un processus de mise à niveau sans échec lorsque des équipements Junos sont présents sans VRF de gestion configuré, ajoutez l’argument --skip-junos-mgmt-vrf-check .
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, il vous sera donc demandé 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 télécommande, de travail ancienne et 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 > nœuds de cluster > Apstra).

Note:
La taille du blueprint et les ressources de la machine virtuelle du serveur Apstra déterminent le temps nécessaire pour effectuer l’importation. Si l’importation de la base de données dépasse la valeur par défaut (40 min ou 2400 secondes), l’opération peut expirer. 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 appareils de la structure qui recevront des modifications de configuration lors de la mise à niveau. 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. Les modifications apportées au rendu de la configuration sont clairement documentées en haut, ce qui explique l’impact de chaque modification sur le réseau.
Le récapitulatif de la mise à niveau Apstra affiche des informations séparées par rôles d’équipement (superspine, spine, leaf, leaf pair 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ésumé. Le menu interactif Mise à niveau d’AOS s’affiche et vous permet de vérifier le changement de configuration exact sur chaque appareil. Si vous utilisez des configlets, vérifiez que la nouvelle configuration poussé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 été modifiée d’une manière qui invalide les configlets. Pour éviter des 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 relancez 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 interrompre 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 en cas de dysfonctionnement), vous pouvez arrêter le nouveau serveur Apstra et redémarrer l’ancien pour poursuivre les opérations.

Étape 4 : Importer l’état pour les analyses basées sur l’intention

Note:

Depuis Apstra 5.0.0, nous n’affectons plus de balises aux sondes et aux étages, et nous ne prenons plus en charge le service de evpn-host-flap-count télémétrie.

Pour supprimer ou désactiver des widgets ou des sondes pour les analyses basées sur l’intention, ajoutez les arguments suivants à la sudo aos_import_state commande.

Pour supprimer les widgets qui ne sont utilisés dans aucun tableau de bord, ajoutez l’argument --iba-remove-unused widgets .
Depuis Apstra 5.0.0, nous n’attribuons plus de balises aux sondes et aux étapes. Pour supprimer les balises des sondes et des étapes, ajoutez l’argument --iba-remove-probe-and-stage-tags .
Pour ajouter un numéro de série aux étiquettes de sonde non uniques, ajoutez l’argument --iba-number-non-unique-probe-labels .
Pour ajouter un numéro de série aux étiquettes de tableau de bord non uniques, ajoutez l’argument --iba-number-non-unique-dashboard-labels .
Depuis Apstra 5.0.0, nous ne prenons plus en charge le evpn-host-flap-count service. Pour désactiver les sondes non prédéfinies qui utilisent ce service, ajoutez l’argument --iba-disable-probe-with-evpn-host-flap-count-service .
Pour supprimer les espaces de début et/ou de fin des étiquettes de tableau de bord et de leurs étiquettes de widget, ajoutez l’argument --iba-strip-dashboard-labels-widget-labels .
Pour supprimer les espaces de début et/ou de fin des étiquettes de sonde et de leurs noms de processeur, ajoutez l’argument --iba-strip-probe-labels-processor-names .

Étape 5 : 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 de duplication d’adresse IP.
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 l’interface de ligne de commande après avoir quitté le menu.

Étape 6 : 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 de configuration de 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 Modifier le mode de fonctionnement, sélectionnez Normal, puis cliquez sur Mettre à jour. Tous les agents hors boîte, qu’ils soient sur le contrôleur ou sur les machines virtuelles de travail, se connectent automatiquement, reconnectent les appareils et publient 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 partie 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 Modifier le mode de fonctionnement , sélectionnez Normal, puis cliquez sur Mettre à jour.

Étape 7 : Mise à niveau des 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 dorsale, ou d’une dorsale vers une superdorsale, il est possible que le routage passe temporairement d’une feuille à l’autre, puis redescende vers une autre branche et remonte vers une autre dorsale. Pour réduire les risques, 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 à Périphériques > Équipements 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 (Périphérique ) et Agent ( Agent ) s’affichent 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 précédente du logiciel Apstra, ils sont automatiquement mis à niveau vers la nouvelle version. Ils se connectent ensuite au serveur et transmettent les modifications de configuration en attente aux appareils. La télémétrie reprend également, et les états de tâche passent à SUCCESS.
Dans la section Activité du tableau de bord du blueprint, vérifiez qu’il n’y a pas d’anomalie de 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 8 : 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 l’ancien serveur Apstra avec élégance. Il vous aura été demandé si vous souhaitez que l’ancien serveur Apstra soit fermé ; si vous avez répondu oui, la commande s’exécute service aos stop automatiquement pour arrêter l’ancien serveur Apstra pour vous.
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 compatibles avec la nouvelle version d’Apstra, mettez-les à niveau vers une version qualifiée. (Consultez le Guide de l’utilisateur Juniper Apstra pour plus de détails.)

SUR CETTE PAGE