В последние годы производители активного сетевого оборудования продвигают свои продукты которые работают на модульных ОС, при этом CLI если и отличается, то незначительно.
Основные различия, как правило, скрыты от администраторов и пользователей по вполне логичным причинам (защита технологий, авторских прав, а также возможных необратимых последствий, к которым могут привести действия пытливых умов). О том как такие логические структуры реализуются практически чуть ниже.
Как правило модульные ОС работают поверх:
• MontaVista Linux (Cisco NX-OS, Extreme XOS)
• FreeBSD (JunOS)
• OpenBSD (Dell-Force10 OS)
• и других …
Но работа непосредственно с самой файловой системой заблокирована и требует дополнительных привилегий.
Такой режим работы в Extreme XOS называется «debug-mode».
Для входа в “debug-mode” необходимо вбить вручную команду полностью , так как подсказка в этом случае не работает. После этого консоль выдаст приглашение на ввод пароля, получить который нужно у инженеров ТАС (если этого требует сервисный случай и есть действующий сервисный контракт). Пароль будет действителен в течении 59 минут, и генерируется на основе выдаваемого системой “challenge”.
После входа в “debug-mode” пользователю становиться доступна подсказка с помощью <ТАВ> пары дополнительных скрытых веток команд настроек.
И если ветка в большей своей части доступна к просмотру и в обычном режиме работы,
то вот ветка (сразу почему-то вспоминается мультфильм :) является полностью скрытой и предназначена для отладки разработчиками XOS.
Стоит также заметить что, если знать скрытые команды ветки , то прописав их полностью в CLI их можно применить, а вот с командами такое не пройдет.
Но самое главное это то, что исключительно из этого режима есть возможность попасть в shell.
Набор команд встроенного BusyBox представлен на картинке
И достаточно привычная для всех Linux-систем структура корневых каталогов
Все подмонтировано на предустановленную в коммутаторе CF.
При установке XOS из BootRom можно увидеть как идет форматирование этих восьми логических разделов. Девятая позиция это внешняя USB флешка подключенная в порт на лицевой панели.
Ниже ответ на вопрос – «В чем разница при установке ОС в разделы „primary “ и „secondary“ ?», а также почему один файл XOS подходит для установки на все коммутаторы одной линейки независимо
от модели и функционала.
До выпуска семейства коммутаторов Summit X460 на коммутаторах устанавливались CPU от Broadcom с архитектурой MIPS 64, сейчас это более производительные процессоры от RMI с подобной архитектурой. Именно поэтому в файл операционной системы включены два ядра, каждое из которых скомпилировано под свой процессор. В качестве ядра выбрана версия 2.6.98.6.
Файлы alphadiags помогают продиагностировать аппаратную часть, начиная от работоспособности портов, внутренних шин и заканчивая светодиодами. Диагностика бывает простой и расширенной и запускается из CLI с помощью команды < run diagnostic { normal | extended } > (запуск вызывает обрыв трафика на портах !!!).
Вполне возможно что название alphadiags каким то образом связано с тем, что все оборудование Extreme Networks собирается на конвейерах заводов «Alpha».
Процессор который установлен в коммутаторе Summit X460-24t
Ниже собственно, те процессы и модули ядра благодаря которым операционная система и называется модульной.
Под каждый процесс выделен свой участок памяти, что позволяет при сбое одного процесса остальным работать, а также делать ручной перезапуск некоторых некритичных для работы всей
системы модулей.
Авторство некоторых модулей ядра. Так как Extreme Networks использует в своем оборудовании ASICs от Broadcom, то для работы с ними необходимы модули ядра от первоисточника.
Каждый коммутатор имеет идентификатор своей платформы который хранится в EEPROM, поэтому после установки идет проверка на соответствие платформы и уровня лицензии. Информация о том какой функционал необходимо запустить содержится в соответствующих файлах. Удобство такого подхода в том что после ввода лицензионного ключа просто подается команда на запуск соответствующих модулей, без необходимости полной переустановки образа ОС.
Последний файл это скрипт который загружает конфигурацию «по-умолчанию».
С помощью встроенного редактора «vi» можно посмотреть структуру таких файлов. Там всё достаточно просто: описание процесса/модуля, путь запуска, возможность ручного перезапуска, возможность самовосстановления процесса после сбоя, а также некоторые другие параметры.
Вывод:
1. Модульные ОС являются более интеллектуальными чем их предшественники — монолитные ОС, со всеми вытекающими маркетинговыми последствиями. Однако для их установки необходима соответствующая аппаратная поддержка, что в свою очередь увеличивает конечную стоимость продуктов. Особенно это заметно на коммутаторах доступа, которые в таком случае не могут конкурировать по цене с аналогами на монолитных ОС, а некоторые производители даже не делают в этом сегменте предложения.
2. Сложность при желании установить образ системы на виртуальную машину: во-первых пользователю недоступны установочные скрипты встроенные в ОС, во–вторых не все производители используют в своих решениях процессора с архитектурой х86. И поэтому данный вопрос с эмуляторами решается только производителями, которые вносят необходимые исправления и компилируют исходники под х86.
В целом ситуация в чем-то (по личному мнению автора) напоминает рынок мобильных телефонов, где с появлением модульных ОС типа IOS и Android произошел де-факто отказ от старых платформ,
которые сейчас занимают нишу в нижнем ценовом сегменте. Рынок сетевых устройств конечно не будет столь динамичным, но тенденции и преимущества от такого перехода очевидны.
Так что давайте вместе следить за анонсами от Extreme Networks, Cisco Systems, Juniper Networks и другими лидерами рынка, которые активно развивают и используют рассмотренный нами функционал.
Автор: Muk
