Итак, не откладывая дело в долгий ящик, публикую вторую часть приведенного ранее поста. Выражаю благодарность за публикацию — приятно, что статья вас заинтересовала и тема нашла продолжение.
Напомню, что в прошлой части я остановился на том, что после перезагрузки одно из устройств VC не заработало должным образом. Как было справедливо замечено в одном из комментариев, получается, что я после всего этого пошел домой. Нет, первая часть описывает примерно 20 минут моей почти пятичасовой эпопеи. Пристегнулись? Поехали!
После перезагрузки не совсем понятно что же произошло и произошло ли, но главное – клиентский трафик пошел. Подключаюсь через выделеный менеджмент Ethernet-интерфейс и первая неожиданность – основным RE стал member1:
В принципе это случается и не страшно, так как устройства у меня одинаковые с pre-provisioned конфигурацией VC и любое из них может быть мастером. Операционка обновилась и это хорошо. А вот это уже не хорошо:
Устройство видит только один RE, а их должно быть два. Дальнейшее расследование только подтверждает, что негорящие светодиоды неспроста:
Первое устройство, member0, опознано как Linecard и имеет статус Inactive – это означает, что оно не принимает активного участия в виртуальном шасси. Выделенные стек-интерфейсы (vcp-1 и vcp-0) активны, значит можно попробовать локальное подключение:
Вот оно что! Операционка обновилась только на втором устройстве, а на первом — старая (обратите внимание на версию файла прошивки FPC0 и FPC1), поэтому логика VC деактивировала его. Так или иначе, устройство есть и можно попробовать обновить его заново. Одна проблема – при обновлении я следовал гайдам от Juniper и положил образ в /var/tmp, соответственно там теперь пусто и нужно заливать образ заново. Сосредотачиваю все внимание на этом свиче и несколько раз пытаюсь обновить систему/перегрузить только его (member1 продолжает работать):
В конце процесса загрузки/обновления каждый раз вижу:
Несмотря на отсутствие познаний в Unix, на которой основана JunOS, строка «KDB: enter: panic» не внушает оптимизма. Кроме прочего, система вываливается в режим системной отладки (db>), а это совсем плохо. Для справки: у Juniper есть режим знакомой всем консоли, где производится настройка работающей железки, можно зайти в командную строку Unix под root и прочее; есть режим загрузчика loader> для восстановления и заливки образа операционной системы, примерно соответствующий rommon> Cisco; и есть режим дебага db>, который появляется при проблемах с физическими компонентами кстройства. Сделать в этом режиме можно очень мало, если вы не Juniper TAC инженер. В тот момент я не особо понимаю, что это такое и, как гордый прользователь Windows, пробую нажать «дальше»:
О чудо – система загружается, хоть и со старой версией. На тот момент я не осознавал, что эта старая версия грузится из резервного раздела (slice alternate), так как обновляемая версия записывается в основной раздел и в моем случае не может грузиться с него. Поэтому так важно по возможности обновить загрузчик – это еще одна спасительная соломинка при возникновении проблем. В качестве ремарки: обратите так же внимание на строки «Logging to master … Connection to master failed». У всех устройств, объединенных в VC единая консоль управления, то есть при подключении, например через SSH, мы сразу попадаем в консоль устройства-мастера. Так как в моем случае VC неработоспособен, я попадаю в режим управления локальной железки.
В процессе работы, я придумываю залить образ операционки на работоспособный RE и копировать между членами VC – это и быстрее и не надо постоянно отвлекаться на WinSCP. Работает это даже моем случае, так как каналы связи между устройствами активны.
Тем не менее, попытка обновления и перезагрузки каждый раз дает один и тот же результат – я оказываюсь о режиме системного дебага с последующей возможностью загрузить старую версию. Соответственно, проблема постоянна и способом повторения шагов я ничего не добьюсь. Тут мне приходит в голову иедя – ведь у меня есть устройство с работающей системой (member1) и есть флешка, на которую можно накатить снепшот и грузиться с нее. Так и делаю:
Обратите внимание на сообщения при подключении флешки – она определилась как системное устройство da1, это понадобится в будущем. Снепшот на внешней флешке повторяет таковой на внутреннем хранилище устройства – версия 12.3 на основном разделе (/dev/da1s2a) и 11.1 – на резервном (/dev/da1s1a). Имена слайсов так же могу пригодиться, если вы захотите загрузить систему из определенного раздела. Вставляю флешку в проблемное устройство и продолжаю:
Здесь я опять-же из предосторожности зашел в сессию управления локальным устройством, скорее всего можно было перегрузить member0 из консоли мастера. При перезагрузке вижу постоянно цикличную последовательность:
Свич никуда дальше этих повторяющихся строк не движется. Что за?!? Не можешь найти ядро? Через некоторое время обращаю внимание на предпоследнюю строку, жму Enter и попадаю в лоадер:
Жиденько, но все же лучше, чем цикличная перезагрузка. Сам режим лоадера как раз создан для восстановления системы, то есть я в правильном месте. Время работы перевалило за 2 часа… Пробую разные варианты расположения образа системы и обновления – без результата.
Собственно эти строки должны работать, но почему-то не работают – то ли я на тот момент уже ничего не соображал, то ли что-то еще. Я вижу ту же самую циклическую перезагрузку и ругань на отсутствие ядра. В процессе постоянной перезагрузки всплывает еще одна интересность:
Для меня в тот момент это не более, чем предположение, но памятуя, что Juniper обозначает устройства с 0, мне кажется странным присутствие «disk2» — флешка у меня одна. Кроме этого, когда я вставлял флешку, она опозналась как da1. Если вы вернетесь немного назад, можно увидеть, что устройство пыталось грузиться со 2 диска сразу после перезагрузки из консоли (когда я указал внешнюю флешку как устройство для загрузки) но до текущего момента я этого не замечал. Возвращаемся в лоадер и подтверждаем опасения, диска 2 нет, а флешка является нулевым устройством:
Все? Да как бы не так! Система снова пытается грузиться с диска 2, но теперь я чувствую, что на правильном пути. Попутно перебираю близлежащие варианты c разными слайсами на флешке (nextboot diskXsY), без результата. Уже почти отчаявшись, нахожу информацию, что загрузочное устройство должно задаваться как переменная окружения из U-boot mode. Уж не знаю как описать этот четвертый режим и что там можно делать, но попасть туда можно прервав процесс загрузки нажатием Ctrl+C в самом его начале, когда система опрашивает USB устройства (USB: scanning bus for devices...). Первая строка содержит INTERRUPT в ограничителях <>, но из-за него съезжает разметка и шрифты, поэтому ограничители убрал:
Посмотрим, что я увидел после перезагрузки:
«WARNING: JUNOS versions running on dual partitions are not same» не страшно и ожидаемо, ведь новая версия содержится только в основном слайсе устройства.
«Connection to master failed...» и «warning: This chassis is operating in a non-master role...» не страшно, так как VC нужно время, чтобы восстановить связь между членами и синхронизоровать конфигурацию.
После нескольких минут ожидания, система сама просит перезапустить консоль (WARNING: cli has been replaced by an updated version) и теперь уже грузится новая версия на правильном RE.
Проверяем:
Победа! Полная и безоговорочная! Сказать, что я был доволен собой – ничего не сказать, ЧСВ просто зашкаливало. Несмотря на то, что моя работа продлилась порядка 4 часов, это было уже не так важно, так как клиенты этого не почувствовали. Я не только выдал себе виртуальную медаль, но и сохранил достаточно много денег моей компании. Впечатлений за эти 4 часа я получил столько, что потом понадобилось много дней (и пива), чтобы собрать все воедино и понять полную картину.
Теперь осталось только сделать снепшоты на внутреннее хранилище в основной раздел и, через неделю-две – в резервный. Почему через неделю – для обкатки новой версии в продакшне, так как загрузить старую версию системы из резервного раздела гораздо проще, чем ее даунгрейдить на всем устройстве.
Проанализируем ситуацию.
Согласно Juniper TAC, проблемы с обновлением возникли из-за повреждения основного загрузочного раздела. Сделать с этим ничего нельзя и коммутатор надо сдавать по гарантии. Я все-таки очень надеюсь, что проблема была вызвана повреждением файловой системы (некорректная перезагрузка или подобное) и была исправлена в процессе обновления (Un-Protected 1 sectors Erasing Flash…. done), когда я задавал переменную окружения.
С какого перепуга устройство хотело грузиться с disk2, если на него никто явно не указывал и его не было в системе – непонятно, TAC так же затруднился с комментариями. В логах потом можно было даже проследить, что disk2 появляется из ниоткуда (обратите внимание, что new boot device = disk1s2 меняется на new boot device = disk2):
Фактически, данная проблема увеличила затраченое время часа на полтора. Да, свич так же ругается на отсутствие ядра, но почему потом система пытается использовать disk2, если система его вроде как не видела в loader> не понятно. Могу предположить, что при проблемах с загрузкой, устройство пробует циклически перебирать диски, но опять-же устройства disk2 система не видела. Как и почему потом та же самая флешка в дальнейшем с успехом загрузила устройство тоже вызывает вопросы.
Вполне возможно, что я ошибся здесь:
ведь при перезагрузке настройки loader’a теряются. Надо было попробовать «boot» вместо «reboot», но тогда я этого не сделал.
Новая версия системы ощутимо увеличила нагрузку на устройство. На старой версии, загрузка процессора в течение дня была порядка 27-30%, после обновления – 45-48%, но ведь ни достаточно простая конфигурация устройства ни характеристики трафика не поменялись. После нескольких удаленных сессий с Juniper TAC причину установить не удалось – были предположения об утечке памяти и подобных проблемах, но нет. Странно, но пришлось принять как факт.
Внимательный читатель мог обратить внимание, что имена устройств, отображаемые в лоадере (disk0) и использованого для успешной загрузки (disk1 и затем /dev/da1s1a) разные. С чем это связано не рискну утверждать. Могу предположить, что имена меняются в зависимости от степени успешной загрузки системы. Загрузил лоадер — получил одни имена устройств, обращаешься из db> — будут другие; из CLI мы вообще вызываем устройства через «media external» и «media internal». В общем, пока только предположение.
Большинство приведенных выкладок и команд я собрал воедино в гайд задолго до обновления. После этого периодически перичитывал и дополнял его, если мне на ум приходили возможные проблемы. В нем не было разве что режима db> и процедур ==>setenv. Понятное дело, всего предусмотреть не вышло и что-то не работало как должно. Но положа руку на сердце – без этого гайда и времени на его мысленную обкатку, я бы сдался. Тем более, что это была ночная работа и острота ума была снижена.
Бекапы – хоть они и не помогли мне сильно, их наличие успокаивало совесть и душу. В худшем случае, даже если все внутреннее хранилище будет повреждено, я бы скопировал текстовый конфиг в консоль. Эти два пунтка залог того, что вы сконцентрируетесь на работе, а не анализе как вернуть все в исходное состояние и что делать дальше.
Из существенных недочетов: в процессе работы у меня было запущено несколько вкладок PuTTY, пишущих лог в один файл. Разобрать потом все по отдельным устройствам и временным меткам было очень сложно, лучше было воспользоваться SecureCRT или запустить отдельное окно на разных устройствах, тем более, что у меня было достаточно средств для этого.
И в завершении – картинка с места событий. Надеюсь этот пост будет вам полезен. Удачи в грядущих обновлениях!
PS в выводах команд я использовал разметку для обычного кода «code», которая смотрится хуже, чем разметка с бэкграундом исходного кода определенного языка или BASH. Однако разметка «code» позволяет выделение жирным шрифтом, что мне было важно для выделения интересных мест в выводе команд. Если кто поделится как сделать и то и другое (бэкграунд+жирный шрифт внутри), буду признателен и обещаю использовать в дальнейшем.
Апдейт: выяснилось, что в разных браузерах и версиях разметка кода отображается по-разному. Беду курить дальше, как сделать текст более наглядным и читаемым.
Напомню, что в прошлой части я остановился на том, что после перезагрузки одно из устройств VC не заработало должным образом. Как было справедливо замечено в одном из комментариев, получается, что я после всего этого пошел домой. Нет, первая часть описывает примерно 20 минут моей почти пятичасовой эпопеи. Пристегнулись? Поехали!
После перезагрузки не совсем понятно что же произошло и произошло ли, но главное – клиентский трафик пошел. Подключаюсь через выделеный менеджмент Ethernet-интерфейс и первая неожиданность – основным RE стал member1:
login as: user
user@switch password:
--- JUNOS 12.3R12.4 built 2016-01-20 04:27:51 UTC
{master:1}
user@switch>В принципе это случается и не страшно, так как устройства у меня одинаковые с pre-provisioned конфигурацией VC и любое из них может быть мастером. Операционка обновилась и это хорошо. А вот это уже не хорошо:
user@switch> show chassis routing-engine
Routing Engine status:
Slot 1:
Current state Master
DRAM 1024
Memory utilization 45 percent
CPU utilization:
User 14 percent
Background 0 percent
Kernel 11 percent
Interrupt 1 percent
Idle 74 percent
Model EX4500-40F
Serial ID
Start time 2016-06-02 01:28:45
Uptime 34 minutes, 55 seconds
Last reboot reason Router rebooted after a normal shutdown.
Load averages: 1 minute 5 minute 15 minute
0.59 0.80 0.66
{master:1}
user@switch>Устройство видит только один RE, а их должно быть два. Дальнейшее расследование только подтверждает, что негорящие светодиоды неспроста:
user@switch> show virtual-chassis
Preprovisioned Virtual Chassis
Virtual Chassis ID:
Virtual Chassis Mode: Enabled
Mstr Mixed Neighbor List
Member ID Status Serial No Model prio Role Mode ID Interface
0 (FPC 0) Inactive ХХХХХ ex4500-40f 129 Linecard N 1 vcp-1
1 vcp-0
1 (FPC 1) Prsnt ХХХХХ ex4500-40f 129 Master* N 0 vcp-1
0 vcp-0
{master:1}
user@switch>Первое устройство, member0, опознано как Linecard и имеет статус Inactive – это означает, что оно не принимает активного участия в виртуальном шасси. Выделенные стек-интерфейсы (vcp-1 и vcp-0) активны, значит можно попробовать локальное подключение:
Подключение и проверка
{master:1}
user@switch> request session member 0
--- JUNOS 11.1R3.5 built 2011-06-25 01:18:46 UTC
{linecard:0}
user@switch> show system storage
fpc0:
— Filesystem Size Used Avail Capacity Mounted on
/dev/da0s1a 370M 142M 198M 42% /
devfs 1.0K 1.0K 0B 100% /dev
/dev/md0 37M 37M 0B 100% /packages/mnt/jbase
/dev/md1 12M 7.3M 3.6M 67% /packages/mfs-jcrypto-ex
/dev/md2 22M 22M 0B 100% /packages/mnt/jcrypto-ex-11.1R3.5
/dev/md3 8.7M 4.1M 3.9M 51% /packages/mfs-jdocs-ex
/dev/md4 6.3M 6.3M 0B 100% /packages/mnt/jdocs-ex-11.1R3.5
/dev/md5 64M 61M -1.4M 102% /packages/mfs-jkernel-ex
/dev/md6 162M 162M 0B 100% /packages/mnt/jkernel-ex-11.1R3.5
/dev/md7 13M 8.5M 3.5M 71% /packages/mfs-jpfe-ex45x
/dev/md8 24M 24M 0B 100% /packages/mnt/jpfe-ex45x-11.1R3.5
/dev/md9 20M 15M 2.9M 84% /packages/mfs-jroute-ex
/dev/md10 47M 47M 0B 100% /packages/mnt/jroute-ex-11.1R3.5
/dev/md11 16M 11M 3.2M 78% /packages/mfs-jswitch-ex
/dev/md12 35M 35M 0B 100% /packages/mnt/jswitch-ex-11.1R3.5
/dev/md13 12M 7.8M 3.6M 68% /packages/mfs-jweb-ex
/dev/md14 22M 22M 0B 100% /packages/mnt/jweb-ex-11.1R3.5
/dev/md15 126M 8.0K 116M 0% /tmp
/dev/da0s3e 243M 4.4M 219M 2% /var
/dev/da0s3d 727M 130K 668M 0% /var/tmp
/dev/da0s4d 123M 492K 113M 0% /config
/dev/md16 118M 14M 95M 13% /var/rundb
procfs 4.0K 4.0K 0B 100% /proc
/var/jail/etc 243M 4.4M 219M 2% /packages/mnt/jweb-ex-11.1R3.5/jail/var/etc
/var/jail/run 243M 4.4M 219M 2% /packages/mnt/jweb-ex-11.1R3.5/jail/var/run
/var/jail/tmp 243M 4.4M 219M 2% /packages/mnt/jweb-ex-11.1R3.5/jail/var/tmp
/var/tmp 727M 130K 668M 0% /packages/mnt/jweb-ex-11.1R3.5/jail/var/tmp/uploads
devfs 1.0K 1.0K 0B 100% /packages/mnt/jweb-ex-11.1R3.5/jail/dev
fpc1:
— Filesystem Size Used Avail Capacity Mounted on
/dev/da0s2a 363M 130M 204M 39% /
devfs 1.0K 1.0K 0B 100% /dev
/dev/md0 69M 69M 0B 100% /packages/mnt/jbase
/dev/md1 5.8M 1.1M 4.2M 21% /packages/mfs-fips-mode-powerpc
/dev/md2 2.9M 2.9M 0B 100% /packages/mnt/fips-mode-powerpc-12.3R12.4
/dev/md3 9.1M 4.4M 3.9M 53% /packages/mfs-jcrypto-ex
/dev/md4 12M 12M 0B 100% /packages/mnt/jcrypto-ex-12.3R12.4
/dev/md5 8.1M 3.5M 4.0M 47% /packages/mfs-jdocs-ex
/dev/md6 6.2M 6.2M 0B 100% /packages/mnt/jdocs-ex-12.3R12.4
/dev/md7 43M 39M 616K 98% /packages/mfs-jkernel-ex
/dev/md8 109M 109M 0B 100% /packages/mnt/jkernel-ex-12.3R12.4
/dev/md9 12M 7.9M 3.6M 69% /packages/mfs-jpfe-ex45x
/dev/md10 22M 22M 0B 100% /packages/mnt/jpfe-ex45x-12.3R12.4
/dev/md11 17M 12M 3.2M 79% /packages/mfs-jroute-ex
/dev/md12 38M 38M 0B 100% /packages/mnt/jroute-ex-12.3R12.4
/dev/md13 12M 7.2M 3.6M 67% /packages/mfs-jswitch-ex
/dev/md14 21M 21M 0B 100% /packages/mnt/jswitch-ex-12.3R12.4
/dev/md15 14M 9.5M 3.4M 73% /packages/mfs-jweb-ex
/dev/md16 25M 25M 0B 100% /packages/mnt/jweb-ex-12.3R12.4
/dev/da0s3e 243M 20M 204M 9% /var
/dev/md17 252M 12K 232M 0% /tmp
/dev/da0s3d 727M 107M 561M 16% /var/tmp
/dev/da0s4d 123M 494K 113M 0% /config
/dev/md18 118M 22M 86M 20% /var/rundb
procfs 4.0K 4.0K 0B 100% /proc
/var/jail/etc 243M 20M 204M 9% /packages/mnt/jweb-ex-12.3R12.4/jail/var/etc
/var/jail/run 243M 20M 204M 9% /packages/mnt/jweb-ex-12.3R12.4/jail/var/run
/var/jail/tmp 243M 20M 204M 9% /packages/mnt/jweb-ex-12.3R12.4/jail/var/tmp
/var/tmp 727M 107M 561M 16% /packages/mnt/jweb-ex-12.3R12.4/jail/var/tmp/uploads
devfs 1.0K 1.0K 0B 100% /packages/mnt/jweb-ex-12.3R12.4/jail/dev
{linecard:0}
user@switch> exit
rlogin: connection closed
{master:1}
user@switch>
user@switch> request session member 0
--- JUNOS 11.1R3.5 built 2011-06-25 01:18:46 UTC
{linecard:0}
user@switch> show system storage
fpc0:
— Filesystem Size Used Avail Capacity Mounted on
/dev/da0s1a 370M 142M 198M 42% /
devfs 1.0K 1.0K 0B 100% /dev
/dev/md0 37M 37M 0B 100% /packages/mnt/jbase
/dev/md1 12M 7.3M 3.6M 67% /packages/mfs-jcrypto-ex
/dev/md2 22M 22M 0B 100% /packages/mnt/jcrypto-ex-11.1R3.5
/dev/md3 8.7M 4.1M 3.9M 51% /packages/mfs-jdocs-ex
/dev/md4 6.3M 6.3M 0B 100% /packages/mnt/jdocs-ex-11.1R3.5
/dev/md5 64M 61M -1.4M 102% /packages/mfs-jkernel-ex
/dev/md6 162M 162M 0B 100% /packages/mnt/jkernel-ex-11.1R3.5
/dev/md7 13M 8.5M 3.5M 71% /packages/mfs-jpfe-ex45x
/dev/md8 24M 24M 0B 100% /packages/mnt/jpfe-ex45x-11.1R3.5
/dev/md9 20M 15M 2.9M 84% /packages/mfs-jroute-ex
/dev/md10 47M 47M 0B 100% /packages/mnt/jroute-ex-11.1R3.5
/dev/md11 16M 11M 3.2M 78% /packages/mfs-jswitch-ex
/dev/md12 35M 35M 0B 100% /packages/mnt/jswitch-ex-11.1R3.5
/dev/md13 12M 7.8M 3.6M 68% /packages/mfs-jweb-ex
/dev/md14 22M 22M 0B 100% /packages/mnt/jweb-ex-11.1R3.5
/dev/md15 126M 8.0K 116M 0% /tmp
/dev/da0s3e 243M 4.4M 219M 2% /var
/dev/da0s3d 727M 130K 668M 0% /var/tmp
/dev/da0s4d 123M 492K 113M 0% /config
/dev/md16 118M 14M 95M 13% /var/rundb
procfs 4.0K 4.0K 0B 100% /proc
/var/jail/etc 243M 4.4M 219M 2% /packages/mnt/jweb-ex-11.1R3.5/jail/var/etc
/var/jail/run 243M 4.4M 219M 2% /packages/mnt/jweb-ex-11.1R3.5/jail/var/run
/var/jail/tmp 243M 4.4M 219M 2% /packages/mnt/jweb-ex-11.1R3.5/jail/var/tmp
/var/tmp 727M 130K 668M 0% /packages/mnt/jweb-ex-11.1R3.5/jail/var/tmp/uploads
devfs 1.0K 1.0K 0B 100% /packages/mnt/jweb-ex-11.1R3.5/jail/dev
fpc1:
— Filesystem Size Used Avail Capacity Mounted on
/dev/da0s2a 363M 130M 204M 39% /
devfs 1.0K 1.0K 0B 100% /dev
/dev/md0 69M 69M 0B 100% /packages/mnt/jbase
/dev/md1 5.8M 1.1M 4.2M 21% /packages/mfs-fips-mode-powerpc
/dev/md2 2.9M 2.9M 0B 100% /packages/mnt/fips-mode-powerpc-12.3R12.4
/dev/md3 9.1M 4.4M 3.9M 53% /packages/mfs-jcrypto-ex
/dev/md4 12M 12M 0B 100% /packages/mnt/jcrypto-ex-12.3R12.4
/dev/md5 8.1M 3.5M 4.0M 47% /packages/mfs-jdocs-ex
/dev/md6 6.2M 6.2M 0B 100% /packages/mnt/jdocs-ex-12.3R12.4
/dev/md7 43M 39M 616K 98% /packages/mfs-jkernel-ex
/dev/md8 109M 109M 0B 100% /packages/mnt/jkernel-ex-12.3R12.4
/dev/md9 12M 7.9M 3.6M 69% /packages/mfs-jpfe-ex45x
/dev/md10 22M 22M 0B 100% /packages/mnt/jpfe-ex45x-12.3R12.4
/dev/md11 17M 12M 3.2M 79% /packages/mfs-jroute-ex
/dev/md12 38M 38M 0B 100% /packages/mnt/jroute-ex-12.3R12.4
/dev/md13 12M 7.2M 3.6M 67% /packages/mfs-jswitch-ex
/dev/md14 21M 21M 0B 100% /packages/mnt/jswitch-ex-12.3R12.4
/dev/md15 14M 9.5M 3.4M 73% /packages/mfs-jweb-ex
/dev/md16 25M 25M 0B 100% /packages/mnt/jweb-ex-12.3R12.4
/dev/da0s3e 243M 20M 204M 9% /var
/dev/md17 252M 12K 232M 0% /tmp
/dev/da0s3d 727M 107M 561M 16% /var/tmp
/dev/da0s4d 123M 494K 113M 0% /config
/dev/md18 118M 22M 86M 20% /var/rundb
procfs 4.0K 4.0K 0B 100% /proc
/var/jail/etc 243M 20M 204M 9% /packages/mnt/jweb-ex-12.3R12.4/jail/var/etc
/var/jail/run 243M 20M 204M 9% /packages/mnt/jweb-ex-12.3R12.4/jail/var/run
/var/jail/tmp 243M 20M 204M 9% /packages/mnt/jweb-ex-12.3R12.4/jail/var/tmp
/var/tmp 727M 107M 561M 16% /packages/mnt/jweb-ex-12.3R12.4/jail/var/tmp/uploads
devfs 1.0K 1.0K 0B 100% /packages/mnt/jweb-ex-12.3R12.4/jail/dev
{linecard:0}
user@switch> exit
rlogin: connection closed
{master:1}
user@switch>
Вот оно что! Операционка обновилась только на втором устройстве, а на первом — старая (обратите внимание на версию файла прошивки FPC0 и FPC1), поэтому логика VC деактивировала его. Так или иначе, устройство есть и можно попробовать обновить его заново. Одна проблема – при обновлении я следовал гайдам от Juniper и положил образ в /var/tmp, соответственно там теперь пусто и нужно заливать образ заново. Сосредотачиваю все внимание на этом свиче и несколько раз пытаюсь обновить систему/перегрузить только его (member1 продолжает работать):
{master:1}
user@switch> request system software add /var/tmp/jinstall-XXX.tgz validate member 0
user@switch> request system reboot member 0В конце процесса загрузки/обновления каждый раз вижу:
Installing disk0s3d:/jinstall-ex-4500-12.3R12.4-domestic-signed.tgz
Verified jinstall-ex-4500-12.3R12.4-domestic.tgz signed by PackageProduction_12_ 3_0
mode = 040700, inum = 38, fs = /instrootmnt/var
panic: ffs_valloc: dup alloc
###Entering boot mastership relinquish phase
KDB: enter: panic
###Entering boot mastership relinquish phase
[thread pid 316 tid 100041 ]
Stopped at kdb_enter+0x1a0: addis r3, r0, -0x7fa4
db>Несмотря на отсутствие познаний в Unix, на которой основана JunOS, строка «KDB: enter: panic» не внушает оптимизма. Кроме прочего, система вываливается в режим системной отладки (db>), а это совсем плохо. Для справки: у Juniper есть режим знакомой всем консоли, где производится настройка работающей железки, можно зайти в командную строку Unix под root и прочее; есть режим загрузчика loader> для восстановления и заливки образа операционной системы, примерно соответствующий rommon> Cisco; и есть режим дебага db>, который появляется при проблемах с физическими компонентами кстройства. Сделать в этом режиме можно очень мало, если вы не Juniper TAC инженер. В тот момент я не особо понимаю, что это такое и, как гордый прользователь Windows, пробую нажать «дальше»:
db> help
DDB Quick Help
-------------------
Type 'c' to continue, 'reset' or 'panic' to restart.
print p examine x search set write
w delete d break dwatch watch dhwatch
hwatch step s continue c until next
match trace alltrace where bt call show
ps gdb reset kill watchdog thread panic
ddbdumpsys dumpsys halt reboot
db> c
Uptime: 2m41s
Cannot dump. No dump device defined.
Automatic reboot in 15 seconds - press a key on the console to abort
Rebooting...
...Много вывода при перезагрузке...
***** FILE SYSTEM MARKED CLEAN *****
switch (ttyu0)
login: user
Logging to master
...
Connection to master failed, enabling local login
Password:
--- JUNOS 11.1R3.5 built 2011-06-25 01:18:46 UTC
{linecard:0}
user@switch>О чудо – система загружается, хоть и со старой версией. На тот момент я не осознавал, что эта старая версия грузится из резервного раздела (slice alternate), так как обновляемая версия записывается в основной раздел и в моем случае не может грузиться с него. Поэтому так важно по возможности обновить загрузчик – это еще одна спасительная соломинка при возникновении проблем. В качестве ремарки: обратите так же внимание на строки «Logging to master … Connection to master failed». У всех устройств, объединенных в VC единая консоль управления, то есть при подключении, например через SSH, мы сразу попадаем в консоль устройства-мастера. Так как в моем случае VC неработоспособен, я попадаю в режим управления локальной железки.
В процессе работы, я придумываю залить образ операционки на работоспособный RE и копировать между членами VC – это и быстрее и не надо постоянно отвлекаться на WinSCP. Работает это даже моем случае, так как каналы связи между устройствами активны.
user@switch> file copy fpc1:/var/tmp/jinstall-XXX.tgz fpc0:/var/tmp/jinstall-XXX.tgzТем не менее, попытка обновления и перезагрузки каждый раз дает один и тот же результат – я оказываюсь о режиме системного дебага с последующей возможностью загрузить старую версию. Соответственно, проблема постоянна и способом повторения шагов я ничего не добьюсь. Тут мне приходит в голову иедя – ведь у меня есть устройство с работающей системой (member1) и есть флешка, на которую можно накатить снепшот и грузиться с нее. Так и делаю:
{master:1}
umass1: SanDisk Corporation U3 Cruzer Micro, rev 2.00/0.10, addr 4
da1 at umass-sim1 bus 1 target 0 lun 0
da1: <SanDisk U3 Cruzer Micro 2.15> Removable Direct Access SCSI-2 device
da1: 40.000MB/s transfers
da1: 973MB (1994385 512 byte sectors: 64H 32S/T 973C)
user@switch> request system snapshot local partition media external
user@switch> show system snapshot media external
fpc0:
--------------------------------------------------------------------------
error: external media missing or invalid
fpc1:
--------------------------------------------------------------------------
Information for snapshot on external (/dev/da1s1a) (backup)
Creation date: Jun 2 02:28:20 2016
JUNOS version on snapshot:
jbase : 11.1R3.5
jkernel-ex: 11.1R3.5
jcrypto-ex: 11.1R3.5
jdocs-ex: 11.1R3.5
jswitch-ex: 11.1R3.5
jpfe-ex45x: 11.1R3.5
jroute-ex: 11.1R3.5
jweb-ex: 11.1R3.5
Information for snapshot on external (/dev/da1s2a) (primary)
Creation date: Jun 2 02:29:21 2016
JUNOS version on snapshot:
jbase : ex-12.3R12.4
jkernel-ex: 12.3R12.4
jcrypto-ex: 12.3R12.4
jdocs-ex: 12.3R12.4
jswitch-ex: 12.3R12.4
jpfe-ex45x: 12.3R12.4
jroute-ex: 12.3R12.4
jweb-ex: 12.3R12.4
fips-mode-powerpc: 12.3R12.4Обратите внимание на сообщения при подключении флешки – она определилась как системное устройство da1, это понадобится в будущем. Снепшот на внешней флешке повторяет таковой на внутреннем хранилище устройства – версия 12.3 на основном разделе (/dev/da1s2a) и 11.1 – на резервном (/dev/da1s1a). Имена слайсов так же могу пригодиться, если вы захотите загрузить систему из определенного раздела. Вставляю флешку в проблемное устройство и продолжаю:
user@switch> request session member 0
--- JUNOS 11.1R3.5 built 2011-06-25 01:18:46 UTC
{linecard:0}
user@switch> request system reboot member 0 media external
Reboot the system ? [yes,no] (no) yes
Здесь я опять-же из предосторожности зашел в сессию управления локальным устройством, скорее всего можно было перегрузить member0 из консоли мастера. При перезагрузке вижу постоянно цикличную последовательность:
U-Boot 1.1.6 (Mar 26 2011 - 04:34:19)
Board: EX4500-40F 10.4
EPLD: Version 6.2 (0x81)
DRAM: Initializing (1024 MB)
FLASH: 8 MB
Firmware Version: 01.00.00
USB: scanning bus for devices... 3 USB Device(s) found
scanning bus for storage devices... 1 Storage Device(s) found
ELF file is 32 bit
Consoles: U-Boot console
FreeBSD/PowerPC U-Boot bootstrap loader, Revision 2.4
(hmerge@svl-junos-pool130.juniper.net, Sat Mar 26 02:46:28 PDT 2011)
Memory: 1024MB
bootsequencing is enabled
bootsuccess is not set
new boot device = disk2
can't load '/kernel'
can't load '/kernel.old'
Press Enter to stop auto bootsequencing and to enter loader prompt.
Watchdog timed out. Resetting the board.Свич никуда дальше этих повторяющихся строк не движется. Что за?!? Не можешь найти ядро? Через некоторое время обращаю внимание на предпоследнюю строку, жму Enter и попадаю в лоадер:
loader> ?
Available commands:
bcachestat get disk block cache stats
boot boot a file or loaded kernel
autoboot boot automatically after a delay
help detailed help
? list commands
show show variable(s)
set set a variable
unset unset a variable
echo echo arguments
read read input from the terminal
more show contents of a file
nextboot set next boot device
lsdev list all devices
install install JUNOS
include read commands from a file
ls list files
load load a kernel or module
unload unload all modules
lsmod list loaded modules
export export variables to U-Boot environment
save save U-Boot environment
heap show heap usageЖиденько, но все же лучше, чем цикличная перезагрузка. Сам режим лоадера как раз создан для восстановления системы, то есть я в правильном месте. Время работы перевалило за 2 часа… Пробую разные варианты расположения образа системы и обновления – без результата.
loader> install /var/tmp/jinstall-ex-4500-12.3R12.4-domestic-signed.tgz
invalid URL
loader> install --format file:///jinstall-ex-4500-12.3R12.4-domestic-signed.tgz
cannot open package (error 22)
loader> install --format file:///jinstall-ex-4500-12.3R12.4-domestic-signed.tgz
Device NOT ready
Request Sense returned 06 28 00
cannot open package (error 5)
Собственно эти строки должны работать, но почему-то не работают – то ли я на тот момент уже ничего не соображал, то ли что-то еще. Я вижу ту же самую циклическую перезагрузку и ругань на отсутствие ядра. В процессе постоянной перезагрузки всплывает еще одна интересность:
Firmware Version: 01.00.00
USB: scanning bus for devices... 3 USB Device(s) found
scanning bus for storage devices... 1 Storage Device(s) found
ELF file is 32 bit
Consoles: U-Boot console
FreeBSD/PowerPC U-Boot bootstrap loader, Revision 2.4
(hmerge@svl-junos-pool130.juniper.net, Sat Mar 26 02:46:28 PDT 2011)
Memory: 1024MB
bootsequencing is enabled
bootsuccess is not set
new boot device = disk2Для меня в тот момент это не более, чем предположение, но памятуя, что Juniper обозначает устройства с 0, мне кажется странным присутствие «disk2» — флешка у меня одна. Кроме этого, когда я вставлял флешку, она опозналась как da1. Если вы вернетесь немного назад, можно увидеть, что устройство пыталось грузиться со 2 диска сразу после перезагрузки из консоли (когда я указал внешнюю флешку как устройство для загрузки) но до текущего момента я этого не замечал. Возвращаемся в лоадер и подтверждаем опасения, диска 2 нет, а флешка является нулевым устройством:
loader> lsdev
disk devices:
disk0 - USB storage device 0
net devices:
net0:
loader> nextboot disk0:
loader> reboot
Resetting...Все? Да как бы не так! Система снова пытается грузиться с диска 2, но теперь я чувствую, что на правильном пути. Попутно перебираю близлежащие варианты c разными слайсами на флешке (nextboot diskXsY), без результата. Уже почти отчаявшись, нахожу информацию, что загрузочное устройство должно задаваться как переменная окружения из U-boot mode. Уж не знаю как описать этот четвертый режим и что там можно делать, но попасть туда можно прервав процесс загрузки нажатием Ctrl+C в самом его начале, когда система опрашивает USB устройства (USB: scanning bus for devices...). Первая строка содержит INTERRUPT в ограничителях <>, но из-за него съезжает разметка и шрифты, поэтому ограничители убрал:
=> INTERRUPT
=> setenv loaddev disk1
=> saveenv
Saving Environment to Flash...
. done
Un-Protected 1 sectors
Erasing Flash...
. done
Erased 1 sectors
Writing to Flash... writing to flash...
done
. done
Protected 1 sectors
=> reset
...Перезагрузка...
...
Boot media /dev/da1 has dual root support
WARNING: JUNOS versions running on dual partitions are not same
** /dev/da1s1a
FILE SYSTEM CLEAN; SKIPPING CHECKS
clean, 274948 free (84 frags, 34358 blocks, 0.0% fragmentation)
switch (ttyu0)
login: user
Logging to master
...
Connection to master failed, enabling local login
Password:
--- JUNOS 12.3R12.4 built 2016-01-20 04:27:51 UTC
warning: This chassis is operating in a non-master role as part of a virtual-chassis (VC) system.
warning: Use of interactive commands should be limited to debugging and VC Port operations.
warning: Full CLI access is provided by the Virtual Chassis Master (VC-M) chassis.
warning: The VC-M can be identified through the show virtual-chassis status command executed at this console.
warning: Please logout and log into the VC-M to use CLI.
{linecard:1}
user@switch>
WARNING: cli has been replaced by an updated version:
CLI release 12.3R12.4 built by builder on 2016-01-20 03:55:45 UTC
Restart cli using the new version ? [yes,no] (yes)
Restarting cli ...
{master:0}
user@switch>
Посмотрим, что я увидел после перезагрузки:
«WARNING: JUNOS versions running on dual partitions are not same» не страшно и ожидаемо, ведь новая версия содержится только в основном слайсе устройства.
«Connection to master failed...» и «warning: This chassis is operating in a non-master role...» не страшно, так как VC нужно время, чтобы восстановить связь между членами и синхронизоровать конфигурацию.
После нескольких минут ожидания, система сама просит перезапустить консоль (WARNING: cli has been replaced by an updated version) и теперь уже грузится новая версия на правильном RE.
Проверяем:
user@switch> show chassis routing-engine
Routing Engine status:
Slot 0:
Current state Master
DRAM 1024
Memory utilization 50 percent
CPU utilization:
User 43 percent
Background 0 percent
Kernel 24 percent
Interrupt 1 percent
Idle 32 percent
Model EX4500-40F
Serial ID
Start time 2016-06-02 03:43:20
Uptime 3 minutes, 22 seconds
Last reboot reason Router rebooted after a normal shutdown.
Load averages: 1 minute 5 minute 15 minute
2.40 1.12 0.46
Routing Engine status:
Slot 1:
Current state Backup
DRAM 1024
Memory utilization 44 percent
CPU utilization:
User 40 percent
Background 0 percent
Kernel 30 percent
Interrupt 1 percent
Idle 28 percent
Model EX4500-40F
Serial ID
Start time 2016-06-02 01:28:45
Uptime 2 hours, 17 minutes, 57 seconds
Last reboot reason Router rebooted after a normal shutdown.
Load averages: 1 minute 5 minute 15 minute
0.49 0.46 0.44
{master:0}
user@switch>
show virtual-chassis
Preprovisioned Virtual Chassis
Virtual Chassis ID:
Virtual Chassis Mode: Enabled
Mstr Mixed Neighbor List
Member ID Status Serial No Model prio Role Mode ID Interface
0 (FPC 0) Prsnt ex4500-40f ХХХХ 129 Master* N 1 vcp-1
1 vcp-0
1 (FPC 1) Prsnt ex4500-40f ХХХХ 129 Backup N 0 vcp-1
0 vcp-0
{master:0}Победа! Полная и безоговорочная! Сказать, что я был доволен собой – ничего не сказать, ЧСВ просто зашкаливало. Несмотря на то, что моя работа продлилась порядка 4 часов, это было уже не так важно, так как клиенты этого не почувствовали. Я не только выдал себе виртуальную медаль, но и сохранил достаточно много денег моей компании. Впечатлений за эти 4 часа я получил столько, что потом понадобилось много дней (и пива), чтобы собрать все воедино и понять полную картину.
Теперь осталось только сделать снепшоты на внутреннее хранилище в основной раздел и, через неделю-две – в резервный. Почему через неделю – для обкатки новой версии в продакшне, так как загрузить старую версию системы из резервного раздела гораздо проще, чем ее даунгрейдить на всем устройстве.
Проанализируем ситуацию.
Согласно Juniper TAC, проблемы с обновлением возникли из-за повреждения основного загрузочного раздела. Сделать с этим ничего нельзя и коммутатор надо сдавать по гарантии. Я все-таки очень надеюсь, что проблема была вызвана повреждением файловой системы (некорректная перезагрузка или подобное) и была исправлена в процессе обновления (Un-Protected 1 sectors Erasing Flash…. done), когда я задавал переменную окружения.
С какого перепуга устройство хотело грузиться с disk2, если на него никто явно не указывал и его не было в системе – непонятно, TAC так же затруднился с комментариями. В логах потом можно было даже проследить, что disk2 появляется из ниоткуда (обратите внимание, что new boot device = disk1s2 меняется на new boot device = disk2):
Смена загрузочного устройства
user@switch> request system reboot member 0 media external
Reboot the system? [yes,no] (no) yes
Rebooting fpc0
*** FINAL System shutdown message from root@ switch *** System going down IMMEDIATELY {linecard:0}
iuriia@CORE> JWaiting (max 300 seconds) for system process `vnlru_mem' to stop...done
Waiting (max 300 seconds) for system process `vnlru' to stop...done
Waiting (max 300 seconds) for system process `bufdaemon' to stop...done
Waiting (max 300 seconds) for system process `syncer' to stop…
Syncing disks, vnodes remaining...2 2 2 0 1 1 1 0 0 0 0 0 done
syncing disks… All buffers synced.
Uptime: 23m53s
recorded reboot as normal shutdown
Rebooting…
U-Boot 1.1.6 (Mar 26 2011 — 04:34:19)
Board: EX4500-40F 10.4
EPLD: Version 6.2 (0x82)
DRAM: Initializing (1024 MB)
FLASH: 8 MB
Firmware Version: 01.00.00
USB: scanning bus for devices… 3 USB Device(s) found
scanning bus for storage devices… 1 Storage Device(s) found
ELF file is 32 bit
Consoles: U-Boot console FreeBSD/PowerPC U-Boot bootstrap loader, Revision 2.4 (hmerge@svl-junos-pool130.juniper.net, Sat Mar 26 02:46:28 PDT 2011) Memory: 1024MB bootsequencing is enabled
bootsuccess is set
new boot device = disk1s2:
can't load '/kernel' can't load '/kernel.old' Press Enter to stop auto bootsequencing and to enter loader prompt. Watchdog timed out. Resetting the board.
U-Boot 1.1.6 (Mar 26 2011 — 04:34:19)
Board: EX4500-40F 10.4
EPLD: Version 6.2 (0x81)
DRAM: Initializing (1024 MB)
FLASH: 8 MB
Firmware Version: 01.00.00
USB: scanning bus for devices… 3 USB Device(s) found
scanning bus for storage devices… 1 Storage Device(s) found
ELF file is 32 bit
Consoles: U-Boot console FreeBSD/PowerPC U-Boot bootstrap loader, Revision 2.4 (hmerge@svl-junos-pool130.juniper.net, Sat Mar 26 02:46:28 PDT 2011) Memory: 1024MB bootsequencing is enabled
bootsuccess is not set
new boot device = disk2
Reboot the system? [yes,no] (no) yes
Rebooting fpc0
*** FINAL System shutdown message from root@ switch *** System going down IMMEDIATELY {linecard:0}
iuriia@CORE> JWaiting (max 300 seconds) for system process `vnlru_mem' to stop...done
Waiting (max 300 seconds) for system process `vnlru' to stop...done
Waiting (max 300 seconds) for system process `bufdaemon' to stop...done
Waiting (max 300 seconds) for system process `syncer' to stop…
Syncing disks, vnodes remaining...2 2 2 0 1 1 1 0 0 0 0 0 done
syncing disks… All buffers synced.
Uptime: 23m53s
recorded reboot as normal shutdown
Rebooting…
U-Boot 1.1.6 (Mar 26 2011 — 04:34:19)
Board: EX4500-40F 10.4
EPLD: Version 6.2 (0x82)
DRAM: Initializing (1024 MB)
FLASH: 8 MB
Firmware Version: 01.00.00
USB: scanning bus for devices… 3 USB Device(s) found
scanning bus for storage devices… 1 Storage Device(s) found
ELF file is 32 bit
Consoles: U-Boot console FreeBSD/PowerPC U-Boot bootstrap loader, Revision 2.4 (hmerge@svl-junos-pool130.juniper.net, Sat Mar 26 02:46:28 PDT 2011) Memory: 1024MB bootsequencing is enabled
bootsuccess is set
new boot device = disk1s2:
can't load '/kernel' can't load '/kernel.old' Press Enter to stop auto bootsequencing and to enter loader prompt. Watchdog timed out. Resetting the board.
U-Boot 1.1.6 (Mar 26 2011 — 04:34:19)
Board: EX4500-40F 10.4
EPLD: Version 6.2 (0x81)
DRAM: Initializing (1024 MB)
FLASH: 8 MB
Firmware Version: 01.00.00
USB: scanning bus for devices… 3 USB Device(s) found
scanning bus for storage devices… 1 Storage Device(s) found
ELF file is 32 bit
Consoles: U-Boot console FreeBSD/PowerPC U-Boot bootstrap loader, Revision 2.4 (hmerge@svl-junos-pool130.juniper.net, Sat Mar 26 02:46:28 PDT 2011) Memory: 1024MB bootsequencing is enabled
bootsuccess is not set
new boot device = disk2
Фактически, данная проблема увеличила затраченое время часа на полтора. Да, свич так же ругается на отсутствие ядра, но почему потом система пытается использовать disk2, если система его вроде как не видела в loader> не понятно. Могу предположить, что при проблемах с загрузкой, устройство пробует циклически перебирать диски, но опять-же устройства disk2 система не видела. Как и почему потом та же самая флешка в дальнейшем с успехом загрузила устройство тоже вызывает вопросы.
Вполне возможно, что я ошибся здесь:
loader> nextboot disk0:
loader> rebootведь при перезагрузке настройки loader’a теряются. Надо было попробовать «boot» вместо «reboot», но тогда я этого не сделал.
Новая версия системы ощутимо увеличила нагрузку на устройство. На старой версии, загрузка процессора в течение дня была порядка 27-30%, после обновления – 45-48%, но ведь ни достаточно простая конфигурация устройства ни характеристики трафика не поменялись. После нескольких удаленных сессий с Juniper TAC причину установить не удалось – были предположения об утечке памяти и подобных проблемах, но нет. Странно, но пришлось принять как факт.
Внимательный читатель мог обратить внимание, что имена устройств, отображаемые в лоадере (disk0) и использованого для успешной загрузки (disk1 и затем /dev/da1s1a) разные. С чем это связано не рискну утверждать. Могу предположить, что имена меняются в зависимости от степени успешной загрузки системы. Загрузил лоадер — получил одни имена устройств, обращаешься из db> — будут другие; из CLI мы вообще вызываем устройства через «media external» и «media internal». В общем, пока только предположение.
Большинство приведенных выкладок и команд я собрал воедино в гайд задолго до обновления. После этого периодически перичитывал и дополнял его, если мне на ум приходили возможные проблемы. В нем не было разве что режима db> и процедур ==>setenv. Понятное дело, всего предусмотреть не вышло и что-то не работало как должно. Но положа руку на сердце – без этого гайда и времени на его мысленную обкатку, я бы сдался. Тем более, что это была ночная работа и острота ума была снижена.
Бекапы – хоть они и не помогли мне сильно, их наличие успокаивало совесть и душу. В худшем случае, даже если все внутреннее хранилище будет повреждено, я бы скопировал текстовый конфиг в консоль. Эти два пунтка залог того, что вы сконцентрируетесь на работе, а не анализе как вернуть все в исходное состояние и что делать дальше.
Из существенных недочетов: в процессе работы у меня было запущено несколько вкладок PuTTY, пишущих лог в один файл. Разобрать потом все по отдельным устройствам и временным меткам было очень сложно, лучше было воспользоваться SecureCRT или запустить отдельное окно на разных устройствах, тем более, что у меня было достаточно средств для этого.
И в завершении – картинка с места событий. Надеюсь этот пост будет вам полезен. Удачи в грядущих обновлениях!
PS в выводах команд я использовал разметку для обычного кода «code», которая смотрится хуже, чем разметка с бэкграундом исходного кода определенного языка или BASH. Однако разметка «code» позволяет выделение жирным шрифтом, что мне было важно для выделения интересных мест в выводе команд. Если кто поделится как сделать и то и другое (бэкграунд+жирный шрифт внутри), буду признателен и обещаю использовать в дальнейшем.
Апдейт: выяснилось, что в разных браузерах и версиях разметка кода отображается по-разному. Беду курить дальше, как сделать текст более наглядным и читаемым.
Поделиться с друзьями
satandyh
большая печалька бэкграундом висит на фотке… или все это тестовое/лаба?
yand_ua
Согласен. Нет, это не лаба — это ядро сети. С одной стороны вроде как есть весь задел для чистого датацентра (само помещение, каналы для кабелей, патч-панели). С дургой — частые изменения в топологии/устройствах и непонимание со стороны младшего обслуживающего персонала и правилах приличия. Из лично моего опыта в этом датацентре могу сказать, что будет только хуже — с появлением оптики (и стандартных длин кабелей, которые тяжело укоротить) начались проблемы с «соплями» и «кольцами» для компенсации избыточной длины. Я сейчас пробую всю оптику, идущую к стойке навивать на «рога» из стоечных креплений в каналах под потолком, чтобы избежать соплей. Посмотрим как дело пойдет.
Если есть идеи или предложения как организовать правильно оптику, буду признателен за советы.
satandyh
Можно и нужно сделать как минимум один odf и ddf. И через них делать соединения из других помещений, зданий и т.п.
Оптику на бобины в стойке сверху (если таковые есть в шкафах), а после на бобины рядом с сервером, к которому она идет.
С медью — только перетягивать по всем правилам.
+купите маленький принтер для печатания бирок и по разработанной системе все кабели перемаркируйте.
yand_ua
Интересная идея с Distribution frame. Не скажу, что я не мыслил в данном направлении, но пока что идея конфликтует с моими ограниченными познаниями в оптике — ведь для нормальной организации DF, оптику нужно резать+полировать/паять/клеить, а это подразумевает наличие специализированного оборудования, коего в датацентре пока не предвидится. Ну и определенный уровень персонала или закупку на стороне, что учитывая специфику компании довольно проблематично.
Бобины сверху стойки — почти что мое решение с рогами, но все равно принимается. Бобины красивее. Бобины рядом с сервером — нереально.
Вот представьте себе hyperconverged сервер (у нас стоят от SuperMicro, но более яркий пример VxRail от Dell EMC) — это 4 картриджа по 2 порта 10Гб/с в каждом, плюс 2 медных гигабитных менеджмент порта. Все это, то есть 8 портов оптики на пространстве 2U. А если таких серверов пяток в стойке — 40 бобин… Где держать это хозяйство? Если унифицировать бобину на несколько серверов, возникнут проблемы с обслуживанием кабелей.
Не подумайте, что я отвергаю идею или пытаюсь оправдаться. Просто иногда реалии слегка сложнее, нежели на рекламной картинке.