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

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

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

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

После включения, железка долго и нудно сыпет на консоль какие-то диагностические сообщения типа результата стартап-тестирования оборудования или что-то в этом роде, после чего вываливается в оболочку 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 по веб-морде (можно, в принципе и с консоли, но через гуй как-то проще).

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

В появившемся окне выставляем 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

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

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

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