[Partage d'initiés] Dépannage d'un problème de commutation iStack.
F-coins comme récompense：
0
(Non résolu)Salut les gars,
Récemment, j'ai rencontré un problème lié à la fonctionnalité de basculement iStack. Comme vous le savez, iStack est une fonctionnalité très répandue de la fiabilité d’entreprise largement utilisée dans les réseaux d’entreprise, aussi je voudrais profiter de cette occasion pour la partager avec vous. Afin de nous assurer que nous sommes sur la même page, je vais d'abord présenter quelques concepts de base d'iStack, puis nous irons plus loin dans cette affaire.
Les commutateurs ayant rejoint une pile sont des commutateurs membres. Chaque commutateur membre d'une pile joue l'un des rôles suivants:
- Commutateur principal
- Commutateur de veille
Le commutateur de veille est une sauvegarde du commutateur principal. Lorsque le commutateur principal échoue, le commutateur de veille reprend tous les services du commutateur principal. Une pile n'a qu'un seul commutateur de veille.
- Commutateur esclave
Un commutateur esclave transfère le trafic de service. Plus le nombre de commutateurs esclaves dans une pile est élevé, meilleures sont les performances de transfert que la pile peut offrir. Hormis les commutateurs maître et de secours, tous les autres commutateurs de la pile sont des commutateurs esclaves.
Maintenant, je vais revenir à l'affaire. L'objectif principal étant d'effectuer une mise à niveau sans nuire au réseau. Le client a donc planifié de redémarrer chaque membre de la pile séparément. Le système était composé de 2x maître CE7850-32Q-EI et en attente.
La première opération, redémarrer le périphérique de secours a été effectuée sans interruption. Mais la deuxième étape, le redémarrage du maître, génère une panne totale car le système de pile entier redémarre de manière inattendue. Qu'est-ce qui pourrait mal se passer?
Afin de comprendre ce qui se passe réellement, nous devons faire un bref retour en arrière et vérifier la journalisation de l'opération telle qu'elle était à ce moment précis. Je partagerai avec vous le meilleur moyen de collecter tous les journaux possibles que le système Cloud Engine peut générer afin de revenir en arrière sur un problème.
<HUAWEI> save logfile //Collect common user log file log.log.
<HUAWEI> system-view
[~HUAWEI] diagnose
[~HUAWEI-diagnose] save logfile diagnose-log //Collect diagnostic log file
diag.log generated when the device is running.
[~HUAWEI-diagnose] collect diagnostic information
Après avoir exécuté les commandes ci-dessus, vous téléchargez par FTP tous les fichiers contenus dans le dossier logfile à partir du flash des deux périphériques (sur le maître, le chemin est flash: / logfile / et sur l'esclave, le chemin est slave: / flash: / logfile /).
Exemple:
<R7_U18_CE6850>dir
Directory of flash:/
Idx Attr Size(Byte) Date Time FileName
0 drwx - Oct 01 2015 19:52:00 $_checkpoint
13 drwx - Oct 05 2015 03:17:30 logfile
<R7_U18_CE6850>cd logfile
<R7_U18_CE6850>dir
Directory of flash:/logfile/
Idx Attr Size(Byte) Date Time FileName
0 -rw- 6,128,295 Oct 05 2015 03:17:30 diag.log
1 -rw- 470,275 Jul 17 2015 14:39:48 diaglog_1_20150717153947.log.zip
2 -rw- 563,056 Sep 05 2015 03:25:46 diaglog_1_20150905032545.log.zip
3 -rw- 526,418 Aug 12 2015 21:28:27 diaglog_2_20150812212827.log.zip
4 -rw- 167,785 Oct 05 2015 03:17:30 diagnostic_information.zip
5 -rw- 2,420,941 Oct 05 2015 03:21:16 log.log
Temps de réinitialisation de l'emplacement 1:
Jan 7 2016 18:57:35 xxxxx %CLI/5/CMDRECORD(s):CID=0x80ca2716;Recorded command information. (Task=VTY0, Ip=x.x.x.x VpnName=_public_, User=xxxxx, AuthenticationMethod="Local-user", Command="reset slot 1".)
Temps de réinitialisation de l'emplacement 2:
Jan 7 2016 19:02:16 xxxxx %CLI/5/CMDRECORD(s):CID=0x80ca2713;Recorded command information. (Task=VTY0, Ip=x.x.x.x, VpnName=_public_, User=xxxxx AuthenticationMethod="Local-user", Command="reset slot 2".
De plus, dans le journal de session, nous avons constaté que le client ne vérifiait pas l'état de la permutation. En règle générale, si l'état de la commutation n'est pas prêt, la commutation échouera et le caractère de fiabilité de cette fonction ne pourra pas être utilisé en conséquence. Vérifiez ci-dessous à quoi devrait ressembler le statut:
<HUAWEI> display switchover state
Switchover State : Ready
Switchover Policy : Board Switchover
MainBoard : 1
SlaveBoard : 2
En fait, le système vous avertit avant de le redémarrer:
Jan 7 2016 18:57:37 xxxxx%CLI/5/INTER_CMDRECORD(s):CID=0x80ca2716;Recorded command information. (Task=VTY0, Ip=s.s.s.s, VpnName=_public_, User=xxxxx Command="reset slot 1", PromptInfo="Warning: Resetting the board in slot 1 may cause system reboot while the switchover state is not ready. Continue? [Y/N]:", UserInput="Y".)
La conclusion de ce cas est de toujours lire attentivement le guide de mise à niveau / la documentation avant de commencer toute opération. Si vous rencontrez des problèmes pour comprendre certaines opérations, n'hésitez pas à contacter TAC pour obtenir de l'aide.
J'espère que vous trouverez ce document utile. Au revoir!
- x
- Standard：
|
|
|
|
Commentaire
