Востокин С.В.. Операционные системы. Экзаменационные вопросы по разделам дисциплины. Учебник предназначен для студентов специальности Фундамен тальная информатика и информационные технологии
 Скачать 2.09 Mb.
|
|
Раздел II. Проектирование операционных систем Лекция 3. Требования к операционным системам и обзор подходов их реализации Обзор требований, предъявляемых к операционным системам: расширяемость, переносимость, надежность и отказоустойчивость, совместимость, безопасность, производительность операционных систем. Операционная система выполняет связующую роль между оборудованием и прикладными программами. Она является важ- нейшим элементом программной инфраструктуры, от свойств кото- рой зависит качество работы прикладного программного обеспече- ния. Поэтому при проектировании операционных систем уделяют внимание специальным функциональным требованиям – более ши- роким, чем при проектировании прикладных программ. Расширяемость. Код операционной системы должен быть написан таким образом, чтобы при необходимости можно было легко внести дополнения и изменения, не нарушая целостности системы. Во времена первых компьютеров считалось, что по мере об- новления аппаратного обеспечения код операционных систем будет создаваться заново, с нуля. Однако практика показала, что разработ- ка программного обеспечения значительно более трудоемка, чем разработка аппаратуры. Возникла необходимость защиты инвести- ций как в разработку операционной системы, так и в прикладные программы, функционирующие под ее управлением. В то время как аппаратная часть компьютера устаревает за не- сколько лет, полезная жизнь операционной системы может изме- 24 ряться десятилетиями (Unix). Аппаратные изменения, к которым должна быть, в первую очередь, адаптирована архитектура операци- онных систем, связаны с развитием периферийного оборудования. Например, современные модификации в операционных системах связаны с новыми технологиями хранения данных (накопители SSD), сетевого взаимодействия (беспроводные сети, оптические ка- налы высокой пропускной способности), новыми пользовательски- ми интерфейсами (жестовый ввод, голосовой ввод, сенсорные пане- ли). Сохранение целостности кода операционной системы, учиты- вая, что происходит постоянная модернизация аппаратуры, является одной из целей проектирования операционной системы. Расширяемость может достигаться за счет модульной структу- ры операционной системы, при которой ее части состоят из сильно связанных внутри и слабо связанных между собой модулей. Взаи- модействие между модулями организуется через стандартизирован- ные интерфейсы. Новые компоненты, добавляемые в операционную систему, функционируют, используя интерфейсы, поддерживаемые существующими компонентами. Можно заменить код устаревших модулей, не затрагивая работоспособность системы в целом. Использование объектов для представления системных ресур- сов также улучшает расширяемость системы. Объекты позволяют единообразно управлять системными ресурсами. Добавление новых объектов не разрушает существующие объекты и не требует изме- нений существующего кода. Вариантом модульной организации является применение ар- хитектуры клиент-сервер и микроядра. В ней модули изолированы в отдельных процессах и могут замещаться даже без перекомпиляции и остановки вычислений. Другой возможностью расширить функциональные возможно- сти операционной системы являются средства вызова удаленных процедур (RPC), которые могут добавляться в любую машину сети и немедленно поступать в распоряжение прикладных программ на других машинах сети. Некоторые операционные системы для улучшения расширяе- мости поддерживают загружаемые драйверы, которые добавляются в систему во время ее работы. Новые файловые системы, устройства и сети могут поддерживаться путем написания драйвера устройства, 25 драйвера файловой системы или транспортного драйвера и загрузки его в систему. Переносимость. Код операционной системы должен легко пе- реноситься между процессорами и аппаратными платформами раз- личной архитектуры. Аппаратная платформа включает наряду с ти- пом процессора и способ организации всей аппаратуры компьютера. Расширяемость позволяет улучшать операционную систему по мере обновления периферийного оборудования. Переносимость дает возможность перемещать всю систему целиком на машину, базиру- ющуюся на обновленном процессоре или аппаратной платформе, делая при этом по возможности небольшие изменения в коде. Опе- рационные системы разрабатываются либо как переносимые, либо как непереносимые. Ключевым моментом в оценке переносимости является стоимость необходимых изменений. При написании переносимой операционной системы нужно следовать перечисленным ниже правилам. Большая часть кода должна быть написана на языке высокого уровня, например, как Unix на языке Си. Код, написанный на Ас- семблере, не является переносимым, если только он не переносится на машину, обладающую командной совместимостью с исходной машиной. Необходимо учитывать аппаратную платформу, на которую операционная система должна быть перенесена. Например, система, построенная на 32-битовых адресах, не может быть перенесена на машину с 16-битовыми адресами. Следует минимизировать или по возможности исключить ча- сти кода, которые непосредственно взаимодействуют с аппаратурой. Оставшийся после такой оптимизации аппаратно-зависимый код, который не может быть исключен, локализуется в отдельных моду- лях (HAL – hardware abstraction layer). Очевидные формы зависимо- сти от аппаратуры включают прямое манипулирование регистрами процессора, аппаратно-зависимыми структурами данных (контекст процесса, дескрипторы страниц и сегментов), обращение к контрол- лерам периферийного оборудования. Надежность и отказоустойчивость. Система должна быть защищена от отказов оборудования и внутренних ошибок. Действия операционной системы должны быть предсказуемыми. Прикладные процессы не должны иметь возможность наносить вред как самой 26 операционной системе, так и другим процессам. Надежность обес- печивается применением микроядерной архитектуры. Совместимость. Операционная система должна иметь сред- ства для выполнения прикладных программ, написанных для других операционных систем или для более ранних версий данной опера- ционной системы. Пользовательский интерфейс должен быть совме- стим с существующими системами и стандартами. Совместимость операционных систем рассматривается на двух уровнях как двоич- ная совместимость и совместимость по исходным кодам. Двоичная совместимость достигается совместимостью на уровне команд процессора, системных вызовов и на уровне библио- течных вызовов, если они являются динамически связываемыми. Совместимость по исходным кодам требует наличия соответ- ствующего компилятора в составе программного обеспечения, а также совместимости на уровне библиотек и системных вызовов, при этом необходима перекомпиляция. Совместимость на уровне исходных текстов важна для разра- ботчиков приложений. Для конечных пользователей практическое значение имеет только двоичная совместимость, благодаря которой один и тот же коммерческий продукт можно использовать в различ- ных операционных средах и на различных машинах. Совместимость зависит от многих факторов, самый важный фактор – архитектура процессора. Если процессор, на который переносится операционная система, использует аналогичный набор команд и тот же диапазон адресов, двоичная совместимость может быть достигнута достаточ- но просто. Двоичная совместимость между процессорами, основанными на разных архитектурах, требует написания специальных эмулято- ров и использования прикладных сред. Для исполнения кода в гос- тевой операционной системе требуется: процедура загрузки, адапти- рованная под формат исполняемого файла; интерпретация команд целевого процессора на гостевом процессоре (если процессорные архитектуры различаются); имитация системных вызовов (вызовов библиотечных функций операционной системы) с использованием заранее написанной библиотеки функций аналогичного назначения. Примером прикладных сред в Windows NT являются подси- стемы для исполнения Win32 приложений, консольных приложений OS/2 и Unix, шестнадцатиразрядных DOS и Win16 приложений. 27 Среда исполнения языка Java, как основной механизм переносимо- сти программ, использует программную эмуляцию архитектуры Java, которая может быть реализована полностью на аппаратном уровне. Для запуска Win32(64) приложений на Linux используется программная среда Wine. Среда Cygwin, наоборот, представляет со- бой инструмент для переноса программ UNIX в Windows и является библиотекой, которая реализует интерфейс к системным вызовам Win32. Средствами обеспечения совместимости на уровне исходных кодов являются стандартизированный язык высокого уровня и стан- дартизированные интерфейсы системных вызовов. Примером стан- дартизированного процедурного языка программирования является Си (новый стандарт для языка ISO/IEC 9899:2011 вышел 19 декабря 2011 года). Наиболее известным набором стандартов, описывающих интерфейсы между операционной системой и прикладной програм- мой, является POSIX (Portable Operating System Interface for Unix – переносимый интерфейс операционных систем Unix). Стандарт со- здан для обеспечения совместимости различных UNIX-подобных операционных систем и переносимости прикладных программ на уровне исходного кода. Использование стандарта POSIX (IEEE Std 1003.1-2004, ISO/IEC 9945) позволяет создавать программы в стиле UNIX, которые могут легко переноситься из одной вычислительной системы в другую. Для семейства операционных систем, основанных на Linux, имеется стандарт совместимости LSB (Linux Standard Base). LSB специфицирует: стандартные библиотеки, несколько команд и ути- лит в дополнение к стандарту POSIX, структуру иерархии файловой системы, уровни запуска и различные расширения системы X Window System. Безопасность. Операционная система должна обладать сред- ствами защиты. Правила безопасности определяют способы защиты ресурсов пользователя и устанавливают квоты по ресурсам для предотвращения захвата пользователем всех системных ресурсов (например, памяти). Основы безопасности были заложены стандартом «Критерии оценки надежных компьютерных систем» (Department of De- fenseTrusted Computer System Evaluation Criteria, TCSEC, DoD 5200.28-STD, 26 декабря 1985 года). Этот документ часто называют 28 «Оранжевой книгой». Аналогом «Оранжевой книги» является меж- дународный стандарт ISO/IEC 15408, опубликованный в 2005 году. В соответствии с требованиями «Оранжевой книги» безопас- ной считается такая система, которая «посредством специальных механизмов защиты контролирует доступ к информации таким об- разом, что только имеющие соответствующие полномочия лица или процессы, выполняющиеся от их имени, могут получить доступ на чтение, запись, создание или удаление информации». Иерархия уровней безопасности, приведенная в «Оранжевой книге», выделяет четыре уровня (D, С, B, A) и 6 классов безопасно- сти внутри уровней (C1, C2, B1, B2, B3, A1). В уровень D попадают системы, оценка которых выявила их несоответствие требованиям безопасности. Уровень C обеспечивает произвольное управление доступом; уровень B – принудительное управление доступом; уро- вень A – верифицируемую безопасность. В каждом классе от C1 к A1 требования по безопасности расширяются. Коммерческие системы обычно соответствуют уровню C. Вот некоторые требования безопасности этого уровня: 1) наличие защи- щенных средств секретного входа, обеспечивающих идентифика- цию пользователя путем ввода логина и пароля; 2) избирательный (дискреционный) контроль доступа, позволяющий владельцу ресур- са определить, кто имеет доступ к ресурсу и что он может с ним де- лать путем предоставляемых прав доступа пользователю или группе пользователей; 3) средства учета и наблюдения, обеспечивающие возможность обнаружить и зафиксировать важные события, связан- ные с безопасностью: любые попытки создать, получить доступ и удалить системные ресурсы; 4) защита памяти, обеспечивающая инициализацию перед повторным использованием. Системы уровня B реализуют мандатный (принудительный) контроль доступа. Каждому пользователю присваивается рейтинг защиты и он может получать доступ к данным только в соответ- ствии с этим рейтингом. Этот уровень, в отличие от уровня C, обес- печивает централизованное управление потоками данных в системе и защищает систему от ошибочного поведения пользователя. Однако существует проблема, впервые описанная Батлером Лэмпсоном в 1973 году, известная как «скрытый канал» или про- блема ограждения. Лэмпсон показал, что в защищенной системе 29 возможны неконтролируемые принудительной системой безопасно- сти потоки информации. Определяют два вида скрытых каналов. Скрытый канал памяти. Процессы взаимодействуют благода- ря тому, что один может прямо или косвенно записывать информа- цию в некоторую область памяти, а второй считывать. Обычно име- ется в виду, что у процессов с разными уровнями безопасности име- ется доступ к некоторому ресурсу (например, возможность прове- рить наличие файла). Скрытый канал времени. Один процесс посылает информа- цию другому, модулируя своё собственное использование систем- ных ресурсов (например, процессорное время) таким образом, что эта операция воздействует на реальное время отклика, наблюдаемое вторым процессом. Критерии «Оранжевой книги» требуют, чтобы анализ скрытых каналов памяти был классифицирован как требование для системы класса B2, а анализ скрытых каналов времени как требование для класса B3. Уровень A является самым высоким уровнем безопасности, он требует в дополнение ко всем требованиям уровня B выполнения формального (математически обоснованного) доказательства соот- ветствия системы требованиям безопасности. Производительность. Система должна обладать настолько хорошим быстродействием и временем реакции, насколько это поз- воляет аппаратная платформа. На практике удовлетворение рас- смотренных выше требований к операционным системам, особенно по надежности и безопасности, приводит к большому потреблению системных ресурсов на функционирование самой операционной си- стемы. Снижение ресурсных требований и повышение производи- тельности является нетривиальной исследовательской задачей при проектировании новых операционных систем. Лекция 4. Архитектуры операционных систем Монолитные системы: модульные и многоуровневые. Клиент- серверные архитектуры: микроядерные и гибридные. Объектно- 30 ориентированные архитектуры. Виртуальные машины: гипервизо- ры, экзоядра, наноядра. Монолитные система – классическая, наиболее распростра- нённая архитектура ядероперационных систем. Все части монолит- ного ядра работают в одном адресном пространстве (рис.4.1). Рис. 4.1. Монолитная операционная система При использовании этой технологии код ядра операционной системы состоит из процедур. Каждая процедура системы имеет определённый интерфейс и может вызывать любую другую проце- дуру, а также обращаться непосредственно к аппаратуре. Код ядра выполняется в режиме супервизора. Рис. 4.2. Структура ядра монолитной системы Аппаратура Процедуры опе- рационной систе- мы Системный интерфейс Главная программа Сервисные про- цедуры Утилиты (работающие непосред- ственно с аппаратурой) 31 Обычно процедуры операционной системы разделяют на главную программу, сервисные процедуры и утилиты (рис.4.2). Вза- имодействие кода пользователя с операционной системой происхо- дит посредством системных вызовов. В отличие от обычных вызо- вов подпрограмм, в системном вызове происходит передача управ- ления и данных между кодом режима пользователя и кодом режима супервизора (ядра). При обращении к системным вызовам главная программа помещает параметры вызова в строго определённое ме- сто (регистры, стек) и переключает машину из режима пользователя в режим ядра (например, вызывая специальные программные пре- рывания). В режиме ядра по сформированному коду системного вызова вычисляется адрес сервисной процедуры в пространстве ядра и вы- полняется вызов. У каждого системного вызова имеется своя сер- висная процедура, а утилиты выполняют функции, нужные несколь- ким сервисным процедурам. В классической монолитной архитектуре все процедуры опе- рационной системы собраны в один объектный файл. Модульное ядро – современная, усовершенствованная модификация архитекту- ры монолитных ядер, в которой код ядра разделяется на отдельно компилируемые и загружаемые модули. Модульные ядра предоставляют механизм загрузки модулей ядра, поддерживающих аппаратное обеспечение (например, драйве- ров). Загрузка модулей может быть как динамической (без переза- грузки операционной системы), так и статической (выполняемой при перезагрузке). Большинство современных ядер, такие как OpenVMS, Linux, FreeBSD, NetBSD и Solaris, позволяют во время работы динамически (по необходимости) подгружать и выгружать модули, выполняющие часть функций ядра. Модули ядра работают в адресном пространстве ядра и могут пользоваться всеми функциями, предоставляемыми ядром. Поэтому модульные ядра продолжают оставаться монолитными. Модуль- ность ядра осуществляется на уровне бинарного образа, а не на ар- хитектурном уровне ядра, так как динамически подгружаемые мо- дули загружаются в адресное пространство ядра и в дальнейшем ра- ботают как его часть. Имеется вариант монолитной архитектуры, когда код ядра операционной системы строится как иерархия уровней. Такая архи- 32 тектура ядра называется многоуровневой. Уровни образуются груп- пами функций, каждый уровень взаимодействует только со своими непосредственными соседями через строго определенные интерфей- сы. Многоуровневая архитектура была предложена Эдсгером Дейкстра в проекте пакетной системы THE в 1968 году. В системе THE функции ядра распределялись по уровням сле- дующим образом. Уровень 0 занимался распределением времени процессора, реализуя базовую многозадачность. Уровень 1 осу- ществлял управление памятью через механизм виртуальной памяти. Уровень 2 отвечал за связь между консолью оператора и процесса- ми. Уровень 3 управлял буферизацией и взаимодействием с устрой- ствами ввода-вывода. На уровне 4 работали программы пользовате- ля. Уровень 5 – это пользователь системы. Многоуровневая архитектура операционной системы THE, в основном, служила средством разработки. Однако каждый уровень может быть наделён привилегиями и выполнять системный вызов с контролем параметров для обращения к другому уровню. В данной архитектуре уровни называются кольцами защиты. Многоуровневая архитектура с кольцами защиты была реализована в операционной системе Multics. Проблемой многоуровневой архитектуры является множе- ственность и размытость интерфейсов между слоями, так как слож- но выполнить однозначную группировку функций по уровням. Ос- новной проблемой монолитной архитектуры является низкая надеж- ность. Она вызвана большим объемом критического к сбою кода, который сложно сопровождать. Также из-за того, что весь код рабо- тает в общем адресном пространстве, ошибка в одной из процедур может привести к повреждению разделяемых всеми процедурами данных и выходу системы из строя. Подобная ситуация может быть и при злонамеренном повреждении кода через модифицированные злоумышленниками подгружаемые модули ядра. Монолитная архитектура, между тем, имеет преимущества с точки зрения удобства организации взаимодействия между частями операционной системы. Оно организуется проще, так как может ис- пользовать глобальные структуры данных системы. По этой же при- чине и по причине отсутствия переключения режима процессора 33 взаимодействие происходит быстрее. Это свойство существенно, например, для эффективной реализации файловых систем. Клиент – серверная архитектура. Эта архитектурная модель предполагает наличие программного компонента потребителя сер- виса, который называется клиентом, и программного компонента поставщика сервиса (сервера). Взаимодействие клиента и сервера стандартизировано. Инициатором обмена является клиент, который посылает запрос серверу, находящемуся в состоянии ожидания за- проса. Применительно к структурированию операционной системы подход состоит в разделении ее на несколько процессов-серверов, каждый из которых выполняет отдельный набор сервисных функ- ций, например, управление памятью, планирование процессов. Сер- верные процессы работают в пользовательском режиме. Микроядро работает в привилегированном режиме и выполняет функции до- ставки сообщений нужному серверу и передачи результатов клиенту (рис. 4.3). Рис. 4.3. Клиент-серверная архитектура В представленной теоретической модели существует про- блема: для реализации своих функций серверы должны иметь до- ступ к аппаратуре. В зависимости от того как разрешается эта ар- хитектурная проблема различают микроядерную и гибридную реа- Сервер памяти Сервер процессов Микроядро Аппаратура Приложение Режим пользователя Режим ядра 34 лизацию клиент-серверного подхода к построению ядра операци- онной системы. Архитектурный подход при проектировании микроядра за- ключается в помещении в ядро только тех функций, которые можно исполнить в режиме супервизора (привилегированном режиме). Все остальные функции распределяются между серверами пользователь- ского режима. При этом используется парадигма разделения меха- низма и политики. Ядро отвечает за механизм реализации некоторо- го решения по управлению ресурсами, а сервер пользовательского режима отвечает за политику, то есть за принятие решений. Пример 1. Очевидно, что запуск процесса требует привилеги- рованного режима, так как связан с манипулированием аппаратно зависимыми структурами данных и передачей управления между процессами. Сам запуск процесса требует доступа к аппаратуре и выполняется ядром. Решение о приоритетах процессов, дисциплине постановки их в очередь может принимать работающий вне ядра планировщик. Пользователь может использовать тот планировщик, который подходит для его прикладной задачи. Пример 2. Для управления памятью в системе имеется плани- ровщик, который определяет стратегию замещения страниц и рабо- тает вне ядра как сервер пользовательского режима (pager). Все остальные аппаратно зависимые функции по управлению памятью реализуются в ядре. Пример 3. У драйверов устройств можно выделить общий ин- терфейс, работающий в режимах ядра. В его функции входит работа с аппаратными прерываниями и доступ к управляющим регистрам устройств ввода-вывода. Драйвер, работающий в режиме пользова- теля, например драйвер СУБД, может включать оптимизацию под конкретный способ доступа к диску, работая на уровне сегментов диска, а не с файлами. Преимуществом микроядерной архитектуры является высокая надежность и гибкость. Надежность обеспечивается тем, что воз- можные сбои локализуются в сервере режима пользователя и не за- трагивают другие сервисы и ядро. Восстановление осуществляется перезапуском отказавшего сервиса без необходимости остановки всех процессов и перезапуска операционной системы. Само ядро, в силу малого объема кода, легко проанализировать на наличие оши- 35 бок. Например, размер кода ядра L4 составляет 14 килобайт и со- держит 7 системных вызовов. Микроядерная архитектура операционной системы вносит до- полнительные накладные расходы, связанные с обменом сообщени- ями, что отрицательно влияет на производительность. Для того, чтобы микроядерная операционная система по скорости не уступала операционным системам на базе монолитного ядра, требуется обес- печить правильное разбиение системы на компоненты, стараясь ми- нимизировать взаимодействие между ними. Таким образом, основ- ная сложность при создании микроядерных операционных систем – необходимость очень аккуратного проектирования. Примерами микроядер являются Mach, L4, Minix, QNX. Наиболее известная операционная система, основанная на микрояд- ре – Symbian OS. Гибридное ядро. Этот архитектурный подход заключается в размещении аппаратно зависимых сервисов в режиме ядра (управ- ление процессами, памятью, вводом-выводом; безопасность). При этом сохраняется ориентированный на сообщения механизм взаимо- действия клиент-серверной архитектуры. Основным преимуществом подхода является значительное по- вышение быстродействия системы. Это происходит потому, что не требуется частого переключения из режима ядра в режим пользова- теля при передаче сообщений между серверами, реализующими сложный системный вызов. Недостатком является некоторая потеря гибкости и надежно- сти. Такие известные семейства операционных систем, как Windows NT и Mac OS X построены на основе гибридных ядер, соответствен- но NT kernel и XNU. Оригинальное решение проблемы производительности с со- хранением высокой надежности и гибкости микроядерного подхода предложено Microsoft и развивается в рамках проекта операционной системы Singularity. В данной операционной системе серверные процессы и ядро исполняются на одном уровне привилегий. Защита процессов производится не путем организации аппаратно- защищенных адресных пространств, а путем использования проме- жуточного языка и его верификации перед компиляцией в код про- цессора. 36 Объектно-ориентированные архитектуры операционных систем. Преимущества объектной модели (инкапсуляция, наследо- вание, полиморфизм) используются также при написании операци- онных систем. Можно выделить три способа применения объектов. Код ядра пишется на процедурном языке, а объекты моделируются средства- ми языка, например, Си. Такой подход используется в ядре Windows NT. Так пользователю доступны описатели (типа HANDLE) для ра- боты с объектами ядра. Имеются полиморфные функции (например, CloseHandle, выполняющая очистку произвольного объекта ядра). Сокрытие реализации объектов ядра выполняется аппаратными ме- ханизмами защиты. Код операционной системы может быть реализован непосред- ственно на объектно-ориентированном языке программирования. Например, язык Objective C используется в операционных системах Mac OS X и iOS. Шире всего объектно-ориентированные технологии применя- ются в программном обеспечении промежуточного уровня – про- граммной прослойке между операционными системами и приклад- ным программным обеспечением. Примером данного вида про- граммного обеспечения Microsoft является архитектура COM (component object model). На основе COM были реализованы техно- логии: Microsoft OLE Automation, ActiveX, DCOM, COM+, DirectX. В COM используется IDL для описания интерфейсов компонента и язык реализации C++. Кроссплатформенным аналогом технологии COM является архитектура CORBA, позволяющая организовать взаимодействие систем, написанных на разных языках программи- рования и работающих на разных операционных системах. Виртуальная машина. Концепция виртуальной машины была разработана в конце 60-х годов в исследовательском центре IBM (Кембридж, Массачусетс) в процессе работы над операционной си- стемой CP/CMS. Последующая коммерческая реализация VM/CMS используется в компьютерах IBM до настоящего времени. Проект изначально разрабатывался как альтернатива OS/360. Эта система разделения времени обеспечивает с одной стороны многозадачность, а с другой – расширенную машину. Эти функции можно полностью разделить. Монитор VM работает с оборудовани- ем и обеспечивает многозадачность. Но представленная монитором 37 машина не является расширенной: она полностью идентична обору- дованию. На ней может работать любая операционная система, ко- торая работает на аппаратуре, в том числе сама VM. Эта операцион- ная система, в свою очередь, реализует расширенную машину. Такая архитектура оказывается проще и надежнее обычной многозадачной операционной системы OS/360. На использовании виртуализации основаны интенсивно раз- вивающиеся в настоящее время «облачные» вычисления. Напри- мер, одним из основных решений для сглаживания неравномерно- сти нагрузки «облачного» поставщика услуг является размещение слоя серверной виртуализации между слоем программных услуг и аппаратным обеспечением. Виртуализация позволяет реализовать балансировку нагрузки посредством программного распределения виртуальных серверов по реальным компьютерам без остановки вычислений. Экзоядро развивает идею виртуальной машины. Основная идея операционной системы на основе экзоядра состоит в том, что ядро должно выполнять лишь функции координатора для неболь- ших процессов, связанных только одним ограничением: экзоядро должно иметь возможность гарантировать безопасное выделение и освобождение ресурсов оборудования. В отличие от операционных систем на основе микроядра, экзоядра обеспечивают большую эф- фективность за счет отсутствия необходимости в переключении между процессами при каждом обращении к оборудованию. Наноядро – архитектура ядра операционной системы компью- теров, в рамках которой крайне упрощённое ядро выполняет лишь одну задачу – обработку аппаратных прерываний, генерируемых устройствами компьютера. Наиболее часто в современных компью- терах наноядра используются для виртуализации аппаратного обес- печения реальных компьютеров или для обеспечения возможности запуска «старой» операционной системы на новом, несовместимом аппаратном обеспечении без её полного переписывания. 38 Экзаменационные вопросы по разделу II 1. Функциональные требования, предъявляемые к операционным системам, и способы их реализации. Расширяемость. Переноси- мость. Надежность. Совместимость. Безопасность. Производи- тельность. 2. Основные архитектуры операционных систем: монолитные, многоуровневые, микроядро, объектно-ориентированные, вирту- альные машины. |