Как выглядит изнутри и какие преимущества модульных ОС сетевых устройств, на примере XOS от Extreme Networks

  • Tutorial
В последние годы производители активного сетевого оборудования продвигают свои продукты которые работают на модульных ОС, при этом 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 и другими лидерами рынка, которые активно развивают и используют рассмотренный нами функционал.


Авторизованные учебные курсы Extreme Networks



МУК-Сервис — все виды ИТ ремонта: гарантийный, не гарантийный ремонт, продажа запасных частей, контрактное обслуживание
МУК
69.30
Company
Share post

Comments 16

    +1
    Спасибо, интересно.
    А что сподвигло выполнить debug-mode?
      –1
      Подозреваю, что виноваты разборки с UA-IX.
        +1
        Последнее что я слышал это blackdaimond, который они поставили на UA-IX, я что-то пропустил? :)
          0
          Ага. Его уже два месяца плющит: local.com.ua/forum/topic/40620-ua-ix-troubles.
          Не имею ничего против Extreme-ов (у самого стоит, нравится), но реакция вендора странная — нет чтобы тупо заменить на что-либо более производительное, так они наживую ковыряют.
            0
            Решение о замене всех Х650 на Х670V принято уже достаточно давно, просто срок поставки оборудования на территорию Украины 6-8 недель, отсюда и возникшая задержка.
            Кстати на этой неделе уже передана часть нового оборудования, которое после согласования времени с участниками будет установлено в продакшн.
        +1
        Идея освещения данного материала возникла достаточно давно, волновала только реакция со стороны вендора,
        поэтому материал представлен в несколько обзорной форме без детализации.
        0
        Заголовок интересный, а содержание среднее. Ожидал более глубокой инфы по принципам работы ОС.
        Но и на этом спасибо, есть пара интересных моментов.
          0
          А как вообще впечатления от этого железа? Что нравиться, что нет? Есть ли какие-ть вкусные фичи, которых нет у конкурентов?
            0
            IMHO основная вкусная фича экстримов — стоимость/плотность 10G портов… и не нужно особо думать куда подключать 10G линк...(у некоторых других вендоров приходится учитывать архитектуру модуля/коммутатора в целом, чтобы не упереться в канал к фабрике либо еще куда).
              0
              Одним из отличий можно упомянуть EAPS (RFC 3619) en.wikipedia.org/wiki/Ethernet_Automatic_Protection_Switching
              данный функционал активно используется в кольцевых топологиях, пока еще не набрал оборотов G.8032
              Впечатления дело очень индивидуальное, которые привязаны к сложившимся привычкам. Многим нравится, другие фанатично привязываются к какому-то другому вендору.
                +1
                Плюс многим нравится что коммутаторы понимают оптику любых производителей.
                  0
                  Мой 400-48t (старый, да) не кушает левые SFP.
                    0
                    На вашем коммутаторе скорее всего установлена монолитная ExtremeWare (unsupported) где нет поддержки сторонней оптики.
                    С 2003 года компания устанавливает на железо модульную ExtremeXOS где OEM модуля не блокируются.
                    Ниже ссылка на небольшую статью с официальными ответами от нескольких вендоров по этому поводу:
                    (http://deepstorage.net/WP-Save/vendors-speak-on-10gig-cables-part-2/ )
                0
                Так что давайте вместе следить за анонсами от Extreme Networks, Cisco Systems, Juniper Networks и другими лидерами рынка, которые активно развивают и используют рассмотренный нами функционал.

                У Cisco под Cat6500 какое-то время были модульные IOS. Те же самые аргументы — легкий патчинг, перезапуск глюкнувших некритичных процессов без ущерба для самого коммутатора и так далее. Забросили.
                С NX-OS ситуация немного иная. У них весь форвардинг строго хардварный. Потому можно взять и обновить какой-нибудь 5500-й (не имеющий резервирования супов) на свежий софт, не потеряв в процессе ни одного пакета: control plane исчезает, но TCAM не сбрасывает ранее имевшуюся информацию и продолжает передавать пакеты. Но само собой, такое возможно только в L2-only конфигурации, и в течение тех 90 секунд, пока софт обновляется, надо усердно молиться, чтобы не произошло событий, требующих перестроения STP :)

                Ну и на самом деле в модульных свитчах с резервированными супами не так уж и требуется эта самая модульность. При сбое одного из процессов проще и надежнее мгновенно сфейловериться на резервный суп.
                  +1
                  У Cisco под Cat6500 какое-то время были модульные IOS. Те же самые аргументы — легкий патчинг, перезапуск глюкнувших некритичных процессов без ущерба для самого коммутатора и так далее. Забросили.

                  Скорее не забросили, а адаптировали наработки под новые Nexus. Да и вряд ли забрасывали, если бы все так легко переносилось на старую аппаратную архитектуру Catalyst.
                  С NX-OS ситуация немного иная. У них весь форвардинг строго хардварный. Потому можно взять и обновить какой-нибудь 5500-й (не имеющий резервирования супов) на свежий софт, не потеряв в процессе ни одного пакета: control plane исчезает, но TCAM не сбрасывает ранее имевшуюся информацию и продолжает передавать пакеты. Но само собой, такое возможно только в L2-only конфигурации, и в течение тех 90 секунд, пока софт обновляется, надо усердно молиться, чтобы не произошло событий, требующих перестроения STP :)

                  «Control Plane» не может никуда исчезнуть s018.radikal.ru/i523/1211/ea/82aca735e70e.jpg — это видно на архитектуре и форвардинг в действительности хардварный, (софтовый форвардинг присутствует и ограничен пропускной способностью шины PCIe)

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

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

                    Так перенесли полностью. Функционал совпадал, возможность патчинга без ребута имелась. А потом кансельнули. Причина — толку не было.
                    «Control Plane» не может никуда исчезнуть

                    У N5K исчезает. Он даже на кипалайвы LACP перестает отзываться на те 90 секунд, потому категорически нельзя подкручивать их.
                    www.cisco.com/en/US/docs/switches/datacenter/nexus5000/sw/upgrade/503_N1_1/n5k_upgrade_downgrade_503.html#wp672931

                  Only users with full accounts can post comments. Log in, please.