|
|
  |
Главная страница / Архитектура отрасли Операционные системы для сетевых устройствВ стремлении расширить спектр сетевых элементов многие производители вынуждены инвестировать в развитие операционных систем (ОС), для каждой из которых характерны свой инструментарий, свой интерфейс прикладного программирования (API) и свои проблемы сопровождения. В результате чаще всего код оказывается непереносим, и инженерам приходится изучать новую ОС для перехода от одного проекта к другому, что увеличивает время выхода продукта на рынок. Возврат инвестиций в разработку кода тоже получается, мягко говоря, ограниченным. «Не остаются в стороне» и клиенты: поскольку программное обеспечение в разных устройствах отличается, отличаются интерфейсы и инструментарий обслуживания; таким образом, навыки, применимые для одного устройства, оказываются неприменимы к другому. Неизбежный результат – повышение стоимости владения. Современные требования к масштабируемости Предположим теперь, что ОС способна предоставить одинаковый код (причем не просто исходный текст, а готовые бинарные модули), инструментарий и API для любого проекта, от пограничных устройств до оборудования операторского класса. Для этого система, как минимум, должна позволять: • адресовать огромное количество различных конфигураций памяти – от сотен килобайт до единиц гигабайт; • управлять сотнями, если не тысячами, задач одновременно; • выполнять одни и те же приложения и системные компоненты, как на однопроцессорной системе, так и в распределенной сети или SMP-блоке. Масштабирование в распределенной сети Операционные системы с классической архитектурой не удовлетворяют перечисленные требования, особенно последнее. Например, в архитектуре современного маршрутизатора расширение сети теоретически реализуется очень просто: достаточно добавить дополнительные линейные карты, принимающие самостоятельные решения по маршрутизации. С одной стороны, такая децентрализация позволяет избежать перегрузки процессора маршрутов. С другой стороны, множество линейных карт способны, одновременно обращаясь к центральному процессору, очень быстро перегрузить системную шину. В результате маршрутизатор, даже при достаточных мощностях, теряет способность масштабироваться в соответствии с растущим трафиком. В качестве решения можно, например, перенести программный интеллект (здесь это база данных маршрутов) из главного процессора в линейные карты, разгрузив системную шину. К сожалению, в ОС с классической архитектурой это весьма непросто по целому ряду причин. В частности, многие ОС не поддерживают механизмов прозрачного межзадачного взаимодействия в сети, поэтому, чтобы разнести компоненты приложения по нескольким процессорам, придется добавить в каждый из них (в нашем случае – в базу данных маршрутов) дополнительный сетевой код. Аналогичные проблемы возникли бы при попытке перенести распределенное приложение на однопроцессорную систему. Пример подхода к проблеме: ОС реального времени QNлема решается за счет следующих факторов. Во-первых, используемая в QNX архитектура на основе микроядра позволяет «отвязать» приложения, драйверы, стеки протоколов и т. п. от ядра ОС. В результате бинарный код любого процесса может быть легко перемещен на любой процессор – без необходимости в перекомпоновке и перестроении ядра. Во-вторых, QNX предоставляет универсальный механизм межзадачного взаимодействия, работающий одинаково как в локальной, так и в сетевой конфигурации. В результате любой процесс или поток на заданном процессоре имеет прозрачный доступ к любому ресурсу любого другого процессора в сети; с точки зрения приложения, никакой разницы между локальным и удаленным ресурсом не существует. Что это означает? Вместо отдельных вычислительных «островов», когда все процессоры, по сути, являются изолированными, мы получаем «виртуальный суперкомпьютер» с прозрачным обменом информацией между вычислительными узлами. В нашем примере с маршрутизатором такая прозрачность ликвидирует ограничение по масштабируемости: базу данных можно перемещать куда угодно «как есть». Таким образом, за счет использования таких систем можно обеспечить возврат инвестиций, о котором мы говорили в начале материала. Полный текст статьи см.: http://www.qnx.com/download/download/8096/From_Tightly%20_Coupled_to_Network_Distributed.pdf Главная страница / Архитектура отрасли |