Сетевые операционные системы

Системы с распределенной разделяемой памятью

Каждый узел имеет свое ядро, которое содержит модули для управления локальными ресурсами — памятью, локальным процессором, локальными дисками и т. д. Кроме того, каждый узел имеет отдельный модуль для межпроцессорного взаимодействия, то есть посылки сообщений на другие узлы и приема сообщений от них.

Рис. 3. Общая структура мультикомпьютерных операционных систем

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

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

Рис. 4. Возможности блокировки и буферизации при пересылке сообщений

Таблица 2. Соотношение между блокировкой, буферизацией и надежностью связи

Точка синхронизации	Буферизация отправителя	Гарантия надежной связи
Блокировка отправителя до наличия свободного места в буфере (S1)	Да	Нет необходимости
Блокировка отправителя до посылки сообщения (S2)	Нет	Нет необходимости
Блокировка отправителя до приема сообщения (S3)	Нет	Необходима
Блокировка отправителя до обработки сообщения (S4)	Нет	Необходима

Существует всего два возможных места буферизации сообщений — на стороне отправителя или на стороне получателя.

Это приводит к четырем возможным точкам синхронизации, то есть точкам возможной блокировки отправителя или получателя. Если буферизация происходит на стороне отправителя, это дает возможность заблокировать отправителя, только если его буфер полон, что показано точкой синхронизации S1 на рисунке. С другой стороны, процедура помещения сообщения в буфер может возвращать состояние, показывающее, что операция успешно выполнена. Это позволяет отправителю избежать блокировки по причине переполнения буфера. Если же отправитель не имеет буфера, существует три альтернативных точки блокировки отправителя: отправление сообщения (точка S2), поступление сообщения к получателю (точка S3), принятие сообщения получателем (точка S4). Отметим, что если блокировка происходит в точке S2, S3 или S4, наличие или отсутствие буфера на стороне отправителя не имеет никакого значения.

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

Другой момент, важный для понимания семантики обмена сообщениями, — надежность связи. Отличительной чертой надежной связи является получение отправителем гарантии приема сообщения. На рис. 4 надежность связи означает, что все сообщения гарантированно достигают точки синхронизации S3. При ненадежной связи всякие гарантии отсутствуют. Если буферизация производится на стороне отправителя, о надежности связи ничего определенного сказать нельзя. Также операционная система не нуждается в гарантированно надежной связи в случае блокировки отправителя в точке S2.

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

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

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

Рис. 5. Страницы адресного пространства распределены по четырем машинам (а). Ситуация после обращения процессора 1 к странице 10 (б). Ситуация, когда запись в страницу 10 невозможна и необходима репликация (в)

Один из распространенных подходов — задействовать виртуальную память каждого отдельного узла для поддержки общего виртуального адресного пространства. Это приводит нас к распределенной разделяемой памяти (Distributed Shared Memory, DSM) со страничной организацией. Принцип работы этой памяти следующий. В системе с DSM адресное пространство разделено на страницы (обычно по 4 или по 8 Кбайт), распределенные по всем процессорам системы. Когда процессор адресуется к памяти, которая не является локальной, происходит внутреннее прерывание, операционная система считывает в локальную память страницу, содержащую указанный адрес, и перезапускает выполнение вызвавшей прерывание инструкции, которая теперь успешно выполняется. Этот подход продемонстрирован на рис. 5, a для адресного пространства из 16 страниц и четырех процессоров. Это вполне нормальная страничная организация, если не считать того, что в качестве временного хранилища информации используется не диск, а удаленная оперативная память.

В этом примере при обращении процессора 1 к коду или данным со страницы 0, 2, 5 или 9 обращение происходит локально. Ссылки на другие страницы вызывают внутреннее прерывание. Так, например, ссылка на адрес со страницы 10 вызывает внутреннее прерывание операционной системы, и она перемещает страницу 10 с машины 2 на машину 1, как показано на рис. 2.5, б.

Одно из улучшений базовой системы, часто позволяющее значительно повысить ее производительность, — это репликация страниц, которые объявляются закрытыми на запись, например, страниц, содержащих текст программы, константы «только для чтения» или другие закрытые на запись структуры. Например, если страница 10 — это секция текста программы, ее использование процессором 1 приведет к пересылке процессору 1 ее копии, а оригинал в памяти процессора 2 будет продолжать спокойно храниться, как показано на рис.5, в. В этом случае процессоры 1 и 2 оба смогут обращаться к странице 10 так часто, как им понадобится, не вызывая при этом никаких внутренних прерываний для выборки памяти.

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

Дополнительного увеличения производительности можно добиться путем ухода от строгого соответствия между реплицируемыми страницами. Другими словами, мы позволяем отдельной копии временно отличаться от других. Практика показывает, что этот подход действительно может помочь, но, к сожалению, может также сильно осложнить жизнь программиста, вынужденного в этом случае отслеживать возможную несовместимость. Поскольку основной причиной разработки DSM была простота программирования, ослабление соответствия не находит реального применения.

Другой проблемой при разработке эффективных систем DSM является вопрос о размере страниц. Мы сталкивались с подобным выбором, когда рассматривали вопрос размера страниц в однопроцессорной системе с виртуальной памятью. Так, затраты на передачу страницы по сети в первую очередь определяются затратами на подготовку к передаче, а не объемом передаваемых данных. Соответственно, большой размер страниц может снизить общее число сеансов передачи при необходимости доступа к большому количеству последовательных элементов данных. С другой стороны, если страница содержит данные двух независимых процессов, выполняющихся на разных процессорах, операционная система будет вынуждена постоянно пересылать эту страницу от одного процессора к другому, как показано на рис. 6. Размещение данных двух независимых процессов на одной странице называется ошибочным разделением (false sharing).

Рис. 6. Ошибочное разделение страницы двумя независимыми процессами

После почти 15 лет исследований распределенной памяти совместного использования разработчики DSM продолжают добиваться сочетания эффективности и легкости программирования. Для достижения высокой производительности крупномасштабных мультикомпьютерных систем программисты прибегают к пересылке сообщений, невзирая на ее высокую, по сравнению с программированием систем (виртуальной) памяти совместного использования, сложность. Это позволяет нам сделать вывод о том, что DSM не оправдывает наших ожиданий для высокопроизводительного параллельного программирования.

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

Рис. 7. Общая структура сетевой операционной системы

Служба, обычно предоставляемая сетевыми операционными системами, должна обеспечивать удаленное соединение пользователя с другой машиной путем применения команды типа: rlogin machine

В результате выполнения этой команды происходит переключение рабочей станции пользователя в режим удаленного терминала, подключенного к удаленной машине. Это означает, что пользователь сидит у графической рабочей станции, набирая команды на клавиатуре. Команды передаются на удаленную машину, а результаты с удаленной машины отображаются в окне на экране пользователя. Для того чтобы переключиться на другую удаленную машину, необходимо открыть новое окно и воспользоваться командой rlogin для соединения с другой машиной. Выбор удаленной машины производится вручную.

Сетевые операционные системы также имеют в своем составе команду удаленного копирования для копирования файлов с одной машины на другую. Например: rcp machinel:filel machine2:file2 Эта команда приведет к копированию файла file1 с машины machine1 на machine2 и присвоению ему там имени file2. При этом перемещение файлов задается в явном виде, и пользователю необходимо точно знать, где находятся файлы и как выполняются команды.

Такая форма связи хотя и лучше чем ничего, но все же крайне примитивна. Это подвигло проектировщиков систем на поиски более удобных вариантов связи и совместного использования информации. Один из подходов предполагает создание глобальной общей файловой системы, доступной со всех рабочих станций. Файловая система поддерживается одной или несколькими машинами, которые называются файловыми серверами (file servers). Файловые серверы принимают запросы от программ пользователей, запускаемых на других машинах (не на серверах), которые называются клиентами (clients), на чтение и запись файлов. Каждый пришедший запрос проверяется и выполняется, а результат пересылается назад.

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

«Нехватка» прозрачности в сетевых операционных системах имеет некоторые очевидные обратные стороны: с ними часто сложно работать, поскольку пользователь вынужден явно подсоединяться к удаленным машинам или копировать файлы с одной машины на другую. Это также проблемы с управлением. Поскольку все машины под управлением сетевой операционной системы независимы, часто и управлять ими можно исключительно независимо. В результате пользователь может получить удаленное соединение с машиной X, только имея на ней регистрацию. Таким образом, если пользователь хочет использовать один пароль на «все случаи жизни», то для смены пароля он вынужден будет явно сменить его на каждой машине. Рассуждая далее, мы видим, что в основном все права доступа относятся к конкретной машине. Нет простого метода сменить права доступа, поскольку всюду они свои. Такой децентрализованный подход к безопасности нередко затрудняет защиту сетевой операционной системы от атак злоумышленников.

Имеются также и преимущества по сравнению с распределенными операционными системами. Поскольку узлы сетевых операционных систем в значительной степени независимы друг от друга, добавить или удалить машину очень легко. В некоторых случаях все, что надо сделать, чтобы добавить узел, — это подсоединить соответствующую машину к общей сети и поставить в известность о ее существовании остальные машины сети. В Интернете, например, добавление нового сервера происходит именно так. Чтобы сведения о машине попали в Интернет, мы должны просто дать ей сетевой адрес, а лучше символическое имя, которое затем будет внесено в DNS вместе с ее сетевым адресом.