Некрофилия для начинающих или: реанимация Cisco Fabric Interconnect

На днях к нам в компанию приехала кучка железа для демо и среди прочего там была блейд-система Cisco UCS с одной неработающей Fabric Interconnect.

image.axd

Собсна, несколько последних дней я провел в попытках расшевелить мертвую фабрику, а т.к. я не часто участвую в порнухе с элементами сексуальных извращений, в процессе данного действа я получил некий интересный опыт работы с цисковскими железками.

Желающие интимных подробностей — прошу читать ниже, опытных сисьководов — просьба не кидаться помидорами.

Итак, симптомы следующие:

После включения, железка долго и нудно сыпет на консоль какие-то диагностические сообщения типа результата стартап-тестирования оборудования или что-то в этом роде, после чего вываливается в оболочку loader> и дальше грузиться отказывается.

Здесь предлагаю немного вспомнить теорию.

Насколько мы знаем, Cisco Fabric Interconnect работает под управлением NX-OS, да и физически почти идентична коммутатору Cisco Nexus 5K Series. Собственно сама NX-OS состоит из двух образов — kickstart и system, при чем для успешного запуска NX-OS, эти 2 образа должны быть идентичной версии. Конкретно для фабрики, в отличии от нексуса, требуется еще 1 образ — ucsmanager.

На практике, эти файлы выглядят как-то так:

ucs-6100-k9-kickstart.5.2.3.N2.2.21b.bin
ucs-6100-k9-system.5.2.3.N2.2.21b.bin
ucs-manager-k9.2.2.1b.bin

В зависимости от версии, имя файлов будет отличаться.

По умолчанию, все эти образы хранятся на внутренней хранилке в папке:

bootflash:/installables/switch/

Из оболочки лоадера (loader>) загрузить вручную, фабрику можно командой:

loader> boot /installables/switch/ucs-6100-k9-kickstart.5.2.3.N2.2.21b.bin /installables/switch/ucs-6100-k9-system.5.2.3.N2.2.21b.bin

Здесь есть один очень тонкий момент: что бы загрузить железку, нам нужно заранее четко знать имена файлов с указанием нужной версии, потому что посмотреть содержимое директории из оболочки loader> не получится (команда dir там работает как-то очень странно и может показать только содержимое текущей директории) и добить <Tab>-ом тоже.

Вообще, из собственного небольшого опыта могу сказать, что некоторые вещи в Cisco сделаны «немножко по-дебильному», и совсем не потому, что у циски инженеры криворукие, а просто потому, что так исторически сложилось, к сожалению, никуда от этого не денешься.

В общем экспериментальным путем (не помню как у меня это получилось), все же удалось определить, что в папке /installables/switch у меня валяются файлы:

Possible files are:
ucs-6100-k9-kickstart.5.0.3.N2.2.11.2a.bin
ucs-6100-k9-system.5.0.3.N2.2.11.2a.bin
ucs-manager-k9.2.2.1b.bin
ucs-6100-k9-kickstart.5.0.3.N2.2.11.3b.bin
ucs-6100-k9-system.5.0.3.N2.2.11.3b.bin
ucs-manager-k9.2.1.3b.bin

С помощью вышеприведенной команды была успешно загружена версия 5.0.3.N2.2.11.3b.

На этом приключения не закончились. В процессе инициализации фабрики в кластере, мы получили сообщение о том, что прошивка у нас старая и настойчивое предложение перепрошиться на более новую версию — 5.2.3.N2.2.21b (что бы соответствовать версии соседней фабрики).

Ничего не подозревая, мы легким движением ноги руки пнули «yes» и стали ждать чудо, но чуда не произошло, после успешной прошивки фабрика ушла в вечный ребут…

Выглядело это как-то так — устройство долго и нудно загружает БИОС с его километровыми диагностическими сообщениями, успешно загружается kickstart и даже начинает загружаться system, но на последнем этапе загрузки начинает сыпать сообщениями вида:

Jul 25 13:35:52 switch %$ VDC-1 %$ %PSS-0-PSS_WRITE_LOG_FAILURE: zschk: failed to write log: No space left on device
2014 Jul 25 13:35:52 switch %$ VDC-1 %$ last message repeated 32 times
2014 Jul 25 13:35:52 switch %$ VDC-1 %$ %PSS-0-PSS_WRITE_LOG_FAILURE: pfma: failed to write log: No space left on device
2014 Jul 25 13:35:53 switch %$ VDC-1 %$ last message repeated 48 times
2014 Jul 25 13:35:53 switch %$ VDC-1 %$ %PSS-0-PSS_WRITE_LOG_FAILURE: feature-mgr: failed to write log: No space left on device
2014 Jul 25 13:35:53 switch

System reset due to service "syslogd" in vdc 1 has had a hap failure

System volatile database usage is unexpectedly high at 100%.

И уходит опять в перезагрузку.

«Хммм…» — подумал я, «Ему просто места мало! Сейчас мы удалим какие-то ненужные файлы и все заработает!!» — АВОТХУЙ! ничего подобного, после удаления нескольких увесистых файлов, ситуация изменилась ровно нисколько.

Как любой порядочный айтишник, я пошел гуглить, и конечно же, набрел на описание бага в Нексусах с похожими симптомами. Только вот неувязочка, этот баг был давно пофиксен и в версии 5.2.3.N2.2.21b он проявляться не должен.

Дальше я попытался сделать erase configuration что бы исключить проблему в конфиге, но это не помогло…

Изучая различные процедуры восстановления Нексусов и фабрик, заметил интересную команду init system которая якобы затирает существующие конфиги и инициализирует систему с нуля. Воу! Это то, что мне нужно!

Загрузив из лоадера только kickstart без system-а, мы попадаем в бутовую оболочку — switch(boot) и здесь возможностей уже гораздо побольше, чем в loader>  (собственно, отсюда я и сделал erase configuration и init system).

После ввода команды init system нас предупреждают, что все конфиги, лицензии и пр. будут удалены. Сама процедура занимает какое-то время на проверку и переразбивку локального хранилища данных. После завершения мы получим чистый раздел bootflash:

Да, по завершении процедуры интересно было узнать, что все образы тоже удалились и загружать мне теперь нечего (упс..).

Поэтому небольшой варнинг:

Перед выполнением процедуры init system нелишним будет скопировать на FTP сервер или по SCP рабочие системные образы: kickstart, system, manager.

Если скопировать данные файлы вы все же не удосужились (как я), тогда придется их искать в другом месте, например — скачать из работающей фабрики.

Мне эти файлы подогнал коллега, который до этого их предусмотрительно скопировал себе на комп :)

Здесь начинается мануал по восстановлению фабрики, когда у нас есть только оболочка loader>, пустой bootflash: и рабочие образы kickstart, system и manager (неважно какой версии, главное что бы у всех 3-х файлов версия была одинаковая).

Веселье начинаем с того, что поднимаем у себя на машине TFTP-сервер (например Tftpd32) и копируем в корень файл ucs-6100-k9-kickstart.<version>.bin

Убеждаемся, что наша машинка в одной сети с «поциентом» и настраиваем у поциента сеть:

loader> set ip <fabric_ip> <netmask>

Данный айпи пинговаться не будет, даже не пытайтесь :)

Пробуем загрузить кикстарт с TFTP:

loader> boot tftp://<your_ip>/ucs-6100-k9-kickstart.<version>.bin

Загрузившись попадаем в оболочку switch(boot), и отсюда закачиваем на bootflash наши образы. Сделать это можно с помощью ftp или scp.

Я пытался залить по фтп, но в итоге с данных образов железка грузиться отказалась, возможно, из-за ошибки передачи данных, а может я криво настроил фтп, но в итоге я склонился к варианту с scp. Выглядит процедура как-то так:

Настраиваем сеть

switch(boot)# conf t
switch(boot)(config)# int mgmt 0
switch(boot)(config)# ip address <fabric_ip> <netmask>
switch(boot)(config)# no shut
switch(boot)(config)# exit
switch(boot)# ip default-gateway <gateway_ip>   //если надо

Копируем файлы

switch(boot)# copy scp://root@<ssh_server_ip>/<path_to_files>/ucs-6100-k9-kickstart.<version>.bin bootflash:
switch(boot)# copy scp://root@<ssh_server_ip>/<path_to_files>/ucs-6100-k9-system.<version>.bin bootflash:
switch(boot)# copy scp://root@<ssh_server_ip>/<path_to_files>/ucs-manager-k9.<version>.bin bootflash:

Теперь один важный момент — нужно скопировать имедж менеджера в файл nuova-sim-mgmt-nsg.0.1.0.001.bin при чем независимо от версии самого менеджера, целевой файл должен назваться именно так.

switch(boot)# copy ucs-manager-k9.<version>.bin nuova-sim-mgmt-nsg.0.1.0.001.bin

Если честно, я так и не понял зачем это делать, нигде толком про это не сказано :)

После того, как все файлы залиты в корень раздела bootflash, даем команду exit что бы вернуться обратно в лоадер.

switch(boot)# exit

Ну а теперь момент истины — пытаемся загрузить залитые имеджи:

loader> boot ucs-6100-k9-kickstart.<version>.bin ucs-6100-k9-system.<version>.bin

После этого, все должно взлететь, и фабрика, по идее, порадует вас приглашением провести инициализацию, но не спешите расслабляться — нужно еще активировать загруженные образы, что бы после перезагрузки фабрика опять не превратилась в тыкву.

Для этого проводим инициализацию в режиме standalone, даем адрес и ломимся на UCS Manager по веб-морде (можно, в принципе и с консоли, но через гуй как-то проще).

Тыцаем пошагово как накартинке:

fic-reanimation-01

В появившемся окне выставляем Startup Version для Kickstart и для System нужную версию и применяем настройки.

На этом мануал закончился, НО не закончились мои приключения :)))

Т.к. на новой версии прошивки система не взлетела, все вышеприведенные действия я проделал для старой версии, а потом решил прошиться через UCS Manager на новую версию.

И что сука характерно удивительно — система опять ушла в циклический ребут, извергая лучи поноса все те же странные ошибки…

Версия прошивки была опять немедленно понижена и опять все заработало. В попытках траблшуттинга были сделаны некоторые телодвижения наподобии просмотра занятого пространства с помощью команды show system internal flash из оболочки nxos:

fi-A(nxos)# show system internal flash
Mount-on 1K-blocks Used Available Use% Filesystem
/ 307200 128264 178936 42 /dev/root
/proc 0 0 0 0 proc
/post 2048 4 2044 1 none
/sys 0 0 0 0 none
/isan 1536000 764888 771112 50 none
/var/tmp 307200 9724 297476 4 none
/var/sysmgr 512000 2320 509680 1 none
/var/sysmgr/ftp 35840 56 35784 1 none
/callhome 32768 0 32768 0 none
/dev/shm 262144 165952 96192 64 none
/volatile 61440 4 61436 1 none
/debug 2048 8 2040 1 none
/dev/mqueue 0 0 0 0 none
/mnt/cfg/0 85528 4196 76916 6 /dev/sda5
/mnt/cfg/1 85528 4196 76916 6 /dev/sda6
/var/sysmgr/startup-cfg 307200 0 307200 0 none
/dev/pts 0 0 0 0 devpts
/mnt/plog 56192 1556 54636 3 /dev/mtdblock2
/mnt/pss 85549 4330 76802 6 /dev/sda4
/bootflash 15022052 1311972 12946996 10 /dev/sda3
/opt 3970300 33044 3736848 1 /dev/sda7
/opt/db/nvram 3963 1585 2174 43 /dev/mtdblock3
/workspace 3945128 32836 3711884 1 /dev/sda8
/spare 5882244 214840 5368600 4 /dev/sda9
/bootflash/sysdebug/tftpd_logs 1024 0 1024 0 tmpfs

интересующая меня строка была в норме, просмотр все тех же логов, и пр. — ничего подозрительного, необычного и нового замечено не было.

На этом моменте я заколебался и оставил старую работающую версию прошивки. Если более опытные и хардкорные гуру подскажут какой-нибудь совет в комментариях — буду премного благодарен.

На этом разрешите откланяться, надеюсь, кому-то было интересно :)

Некрофилия для начинающих или: реанимация Cisco Fabric Interconnect: 4 комментария

  1. Сергей

    Словил проблему 1 в 1 аналогичную вашей. Одна фабрика апдейтится нормально, вторая вылетает с переполнением лога. Проверил /dev/shm/ — на рабочей фабрике на новой прошивке 55% на старой — 30%. На глючной фабрике со старой прошивкой 60%, с новой прошивкой, как вы понимаете, ничего увидеть нельзя.
    Самое интересное, что я частично решил проблему. после всех моих злоключений случайно вышло, что версия кикстарта и система осталась от 2.1.3 а вот версия ucs manager осталась 2.2.3е. Мне вообще не верилось что это будет работать, но факт остается фактом — фабрики загружаются, менеджер стартует, шасси находятся. Я даже смог закачать серверный бандл и обновить им симс одного из криво детектящихся серверов.
    Единственная проблема в том, что обе фабрики висят с критикал ошибкой следующего содержания: [FSM:FAILED]: Ethernet traffic flow monitoring configuration on A(FSM:sam:dme:SwEthLanFlowMonDeploy)
    На эту тему даже есть описанный баг:
    https://tools.cisco.com/quickview/bug/CSCul11595
    Судя по описанию, ошибка не критичная и думаю можно попробовать ею пренебречь.

    1. Доктор Добрянский Автор записи

      Ничто в этом мире не идеально )) Только недавно обсуждали в почте с читателем еще один интересный баг прошивки Cisco FIC… На самом деле — то что имеем сейчас, это цветочки, по сравнению с тем что было пару лет назад, это значит что прогресс есть и это радует ;)
      А на счет «пренебречь» то ой как не советую, особенно, если на железе крутится что-то критичное для бизнеса… У Cisco много странных ошибок, которые вроде и критичные, а вроде и ничего в конкретной ситуации не значат, но в любом случае — советую решить ее, и лучше всего через открытие кейса в саппорт (благо саппорт у Cisco хороший), иначе в любой штатной ситуации она может вылезти боком.

  2. descargar facebook

    Hey there! I know this is kind of off topic but I was wondering which blog
    platform are you using for this site? I’m getting fed up of WordPress because I’ve had issues with hackers and I’m looking at alternatives for another platform.
    I would be awesome if you could point me in the direction of a good platform.

  3. minecraft games

    I know this if off topic but I’m looking into starting my own weblog and was wondering what all is needed to get setup?
    I’m assuming having a blog like yours would
    cost a pretty penny? I’m not very internet smart so I’m not 100% certain. Any recommendations or advice would be
    greatly appreciated. Cheers

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Не робот ли ты часом? * Лимит времени истёк. Пожалуйста, перезагрузите CAPTCHA.