Распределенные операционные системы. Сетевые операционные системы. Программное обеспечение промежуточного уровня.

Распределенная операционная система – это операционная система, компоненты которой распределены по компьютерам. В реальности создать такую систему с удовлетворительными характеристиками так и не удалось. Оказалось, что очень сложно организовать совместную работу разных процессоров. Низкая скорость сетевого взаимодействия не позволяет эффективно перераспределить нагрузку по аппаратуре (памяти, процессорам) разных компьютеров.

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

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

Удаленный вызов процедур.

Удаленный вызов процедур – первая разработка, реализовавшая прозрачность расположения функций. С некоторого компьютера стало возможным вызвать программу, которая запускалась на другом компьютере, выполнялась и передавала результат клиенту.

Не путайте этот механизм с запуском программы по сети. В последнем случае код выполняемого файла передается по сети на ваш компьютер и запускается на вашем компьютере.

Удаленный вызов процедур позволяет выполнять всю необходимую работу на удаленном компьютере, например, настройку параметров его работы (удаленное администрирование). Это была первая цель при разработке протокола. Вторая цель – распределение нагрузки. Сложную вычислительную задачу можно поручить более приспособленному для этого компьютеру.

Попытаемся разобраться с тем, какие проблемы стояли перед разработчиками RPC, и как эти проблемы были решены.

Связь двух процессов, работающих на разных компьютерах, можно осуществить, используя встроенные в операционную систему коммуникационные средства. Это могут быть сокеты, именованные каналы и т.п. При этом программист прикладного процесса должен знать и использовать некоторую заданную коммуникационную модель. Так, например, для организации связи через сокеты следует использовать подходящий шаблон, в котором для передачи данных применяется системный вызов send(), а для получения – receive(). Более того, следует заранее точно знать, какой транспортный протокол будет использован: TCP или UDP, т.к. от этого существенно зависит шаблон программы. А что будет, если общающиеся компьютеры имеют разную аппаратную платформу, работают под управлением разных операционных систем? В этом случае необходимо еще и позаботиться о преобразованиях форматах, порядка передаваемых параметров и т.п.

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

Великолепная фраза, характеризующая описанную ситуацию, есть в книге «Распределенные системы. Принципы и парадигмы» Э.Танненбаума и М. ван Стеена. «Основой множества распределенных систем является явный обмен сообщениями между процессами. Однако процедуры send и receive не скрывают взаимодействия, что необходимо для обеспечения прозрачности доступа. Эта проблема была известна давно, но по ней мало что было сделано до появления в 1980 году статьи [62], в которой предлагался абсолютно новый способ взаимодействия. Хотя идея была совершенно простой (естественно, после того, как кто-то все придумал), её реализация часто оказывается весьма хитроумной».

Вызов локальной процедуры