Управление процессами и ресурсами в многомашинных вычислительных системах

Работа добавлена:



Если Вы нашли нужный Вам реферат или просто понравилась коллекция рефератов напишите о Нас в любой соц сети с помощью кнопок ниже





Управление процессами и ресурсами в многомашинных вычислительных системах на http://mirrorref.ru

4. Управление процессами и ресурсами

в многомашинных вычислительных системах

4.1. Способы организации  управления процессами

и ресурсами в  многомашинных вычислительных системах

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

      ПодММВС сосредоточенного типа понимают многомодульную (или многоузловую) систему, каждый модуль которой включает центральный процессор, оперативную память, интерфейсное устройство и, возможно, дисковую память для свопинга. Такие модули обычно называют«вычислительными модулями». Все вычислительные модули, как правило, имеют общие периферийные устройства. Для связи отдельных модулей (узлов) используются выделенные интерфейсные линии. Вся система чаще всего располагается в одном помещении и администрируется одной организацией. Такие системы в свою очередь принято подразделять на два типа: «кластерные системы» (claster – гроздь), которые состоят из нескольких единиц или десятков (как правило, не более четырех десятков) модулей, и «массово-паралллельные вычислительные системы» или «массивно-параллельные системы»MPP (Massiveparallelprocessing), которые включают более 100 единиц вычислительных модулей. Основными компонентами таких систем, то есть отдельными вычислительными модулями чаще всего являются «усеченные» варианты обычных ВМ.

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

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

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

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

      1) вызов для отправки сообщенияsend(dest,  &mptr);

      2) вызов для получения сообщенияreceive(addr, &mptr).

      Первая процедура посылает сообщение, на которое указывает указательmptr, процессуdest (идентификатор процесса) и блокирует вызывающий ее процесс до тех пор, пока сообщение не будет отправлено. Вторая процедура вызывает блокировку процесса вплоть до получения сообщения. Когда сообщение приходит, оно копируется в буфер, на который указываетmptr, и процесс, вызвавший эту библиотечную процедуру, разблокируется. Параметрaddr указывает адрес, от которого вызывающий процесс ожидает прихода сообщения.

      Отметим, что возможны различные варианты этих двух процедур и их параметров.

      Описанные выше вызовы представляют собойблокирующие вызовы (иногда называемыесинхронными вызовами). Когда процесс обращается к процедуреsend, он указывает адресат и буфер, данные из которого следует послать указанному адресату. Пока сообщение посылается, передающий процесс блокирован (то есть приостановлен). Команда, следующая за обращением к процедуреsend, не выполняется до тех пор, пока все сообщение не будет послано. Аналогично, обращение к процедуреreceiveне возвращает управления, пока сообщение не будет получено целиком и положено в буфер, адрес которого указан в параметре. Процесс остается приостановленным, пока не прибудет сообщение, даже если на это уйдет несколько часов. В некоторых системах получатель может указать, от кого именно он ожидает прихода сообщения. В этом случае процесс будет блокирован, пока не прибудет сообщение от указанного отправителя.

      Альтернативу блокирующим вызовам составляютнеблокирующие вызовы(иногда называемыеасинхронными вызовами). Если процедураsendявляется неблокирующей, то она возвращает управление вызывающему ее процессу практически немедленно, прежде чем сообщение будет отправлено. Преимущество этой схемы состоит в том, что отправляющий процесс может продолжать вычисления параллельно с передачей сообщения, что позволяет избежать простоя центрального процессора (при условии, что других готовых к работе процессов нет). Выбор между блокирующим и неблокирующим примитивами обычно делается проектировщиками системы (то есть, как правило, доступен либо один примитив, либо другой), хотя в некоторых системах бывают доступны оба примитива и право выбора предоставляется пользователю.

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

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

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

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

      Таким образом, у отправителя имеется следующий выбор:

      1. Блокирующая операцияsend (центральный процессор простаивает во время передачи сообщения).

      2. Неблокирующая операцияsend с копированием (время центрального процессора теряется на создание дополнительной копии).

      3. Неблокирующая операцияsendс прерыванием (усложняет программу).

      4. Копирование при записи (в конечном итоге требуется дополнительная операция копирования).

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

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

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

В более сложной форме, чем рассмотрено выше, передача сообщений скрыта от пользователя под видомвызова удаленной процедуры RPC (Remote Procedure Call).

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

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

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

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

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

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

      Традиционно вызывающую процедуру называютклиентом, а вызываемую –сервером. В дальнейшем изложении будет использоваться именно эта  терминология.

      RPC достигает прозрачности следующим путем. Когда вызываемая процедура действительно является удаленной, в библиотеку помещается вместо локальной процедуры другая версия процедуры, называемаяклиентским стабом (stub – заглушка). Подобно оригинальной процедуре, стаб вызывается с использованием вызывающей последовательности, так же происходит прерывание при обращении к ядру. Только в отличие от оригинальной процедуры он не помещает параметры в регистры и не запрашивает у ядра данные, вместо этого он формирует сообщение для отправки ядру удаленной ВМ.

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

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

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

      В идеале RPC должен функционировать правильно и в случае отказов. Рассмотрим некоторые наиболее часто встречающиеся классы отказов и способы реакции системы на них.

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

       2. Потерян запрос от клиента к серверу. Самое простое решение – через определенное время повторить запрос.

      3. Потеряно ответное сообщение от сервера клиенту. Один из вариантов решения проблемы в этом случае – последовательная нумерация всех запросов клиентским ядром. Ядро сервера запоминает номер самого последнего запроса от каждого из клиентов, и при получении каждого запроса выполняет анализ: является ли этот запрос первичным или повторным.

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

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

      б) сразу сообщить приложению об ошибке. Этот подход гарантирует, что RPC был выполнен не более одного раза.

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

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

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

      Следует подчеркнуть, что при реализации метода вызова удаленных процедур, клиентская процедура, написанная пользователем, выполняет «нормальный» (то есть локальный) процедурный вызов клиентского стаба. Так как клиентская процедура и клиентский стаб находятся в одном адресном пространстве, параметры передаются обычным образом. Аналогично, серверная процедура вызывается процедурой в своем адресном пространстве. Таким образом, вместо выполнения с помощью процедурsend иreceive по сути операций ввода-вывода, в методе вызова удаленных процедур связь с удаленными объектами осуществляется при помощи имитации локальных процедурных вызовов.

4.2. Понятия сетевой и распределенной операционных систем

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

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

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

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

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

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

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

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

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

4.3. Варианты реализации распределенных

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

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

      Один из типов такого программного обеспечения представляет собойпромежуточное программное обеспечение, основанное на документах. Типичным представителем такого подхода является основная идея«Всемирной паутины» WWW (World Wide Web), которая заключается в том, что распределенная система должна выглядеть как гигантская коллекция документов, связанных гиперссылками.

      Другой подход состоит в том, чтобы придать распределенной системе вид огромной всемирной файловой системы. Использованиемодели файловой системы для распределенной системы означает, что имеется единая глобальная файловая система с пользователями по всему миру, способными читать и писать файлы, к которым у них есть доступ. Для связи процессов используется файловый обмен. Один процесс записывает данные в файл, а другой процесс считывает их оттуда. В этом случае возможно использование одной из следующих моделей:модели закачивания-скачивания имодели удаленного доступа.В первой модели чтобы получить доступ к файлу, процесс сначала считывает его с удаленного сервера, на котором хранится этот файл. Если для файла разрешено только чтение, то файл читается локально для более высокой производительности. Если файл должен быть записан, он записывается также локально. Когда процесс заканчивает работу с файлом, обновленный файл отправляется обратно на сервер. В модели удаленного доступа файл остается на сервере, а клиент посылает серверу команды для выполнения работы на месте. Преимущество модели закачивания-скачивания заключается в ее простоте и том факте, что перенос файла целиком эффективнее, чем перенос его по частям. К недостаткам данной модели относится необходимость наличия достаточно большого объема памяти для хранения файла целиком локально. К тому же перенос файла целиком, когда требуется только его часть, представляет собой излишние расходы. Наконец, при наличии нескольких конкурирующих пользователей возникает проблема непротиворечивости файлов. Примером рассмотренного подхода является файловая системаAFS (AndrewFileSystem – файловая система, названная в честь спонсоров проекта ее разработки).

      В следующим подходе, связанном  с использованием  промежуточного программного обеспечения, предлагается называть все, что есть в системе,объектами. При этом объект – это набор переменных, объединенных вместе с набором процедур доступа к ним, называемыхметодами. Процессам не разрешается получать доступ к переменным напрямую. Вместо этого они должны вызывать методы. Примером объектного промежуточного программного обеспечения являетсятехнология CORBA (Common Object Request Broker Architecture – архитектура распределенных объектных приложений). Технология CORBA представляет собой систему типа клиент-сервер, в которой клиентский процесс может осуществлять операции с объектами, расположенными на серверах. Архитектура CORBA была разработана для неоднородной системы, состоящей из разнообразных аппаратных платформ и операционных систем. Чтобы клиент на одной платформе мог вызвать сервер на другой платформе, между клиентом и сервером располагаются специальные программные посредники.

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

      Другими примерами моделей, основанных на координации, являются модель «публикация-подписка» и система Jini.

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

Система JiniJini-устройство может быть не только ВМ, но также принтером, сотовым телефоном или другим устройством с центральным процессором, оперативной памятью и  соединением с сетью (возможно, беспроводным). Система  Jini представляет собой свободную федерацию Jini-устройств, которые могут входить в систему и выходить из системы по своему желанию, без централизованного управления. Когда Jini-yстройство хочет присоединиться к федерации, оно передает по локальной сети с помощью широковещания пакет с вопросом о наличии в данном районеслужбы поиска. Для нахождения службы поиска используется специальный протокол обнаружения (один из нескольких собственных протоколов системы Jini). В качестве альтернативы новое Jini-устройство может ждать, пока не придет одно из периодически рассылаемых объявлений службы поиска. Если служба поиска видит, что новое устройство хочет зарегистрироваться, она посылает в ответ программу, выполняющую регистрацию. Затем новое устройство исполняет полученную программу, связывающуюся со службой поиска и регистрирующуюся в ней на некий установленный интервал времени, Пока не истек данный интервал времени, устройство может перерегистрироваться, если оно того пожелает. Такая схема означает, что Jini-устройство может покинуть систему, просто выключившись, и о существовании этого устройства система вскоре забудет. Таким образом, не требуется ни специальной процедуры выхода из системы, ни централизованного управления. Концепция регистрации на определенный срок называется получением аренды. Обратим внимание, что поскольку программа регистрации устройства загружается в устройство по сети, эта программа может изменяться по мере развития системы, для чего не потребуется изменений аппаратного и программного обеспечения в самом устройстве.

      Более подробное изучение строения распределенных операционных систем  выходит за рамки данного учебного пособия.

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

Резюме

      Эффективным способом повышения производительности и надежности вычислительной техники является объединение отдельных автономных ВМ в многомашинные вычислительные системы.

      Различают два класса многомашинных вычислительных систем: ММВСсосредоточенного типа и ММВС распределенного типа (которые обычно называют распределенными  вычислительными системами или вычислительными сетями).

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

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

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

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

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

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

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

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

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

      Одним из наиболее эффективных способов построения распределенных ОС является установка специального промежуточного уровня программного обеспечения поверх сетевой операционной системы. Этот уровень предоставляет однородный уровень для взаимодействующих с ним приложений. Среди различных типов промежуточного программного обеспечения следует выделить документное, файловое, объектное и координационное. Примерами промежуточного программного обеспечения служат такие системы, какWWW, AFS, CORBA, Linda,Jini.

Контрольные вопросы и задания

1. С какими целями ВМ объединяют в многомашинные вычислительные системы?

2. Охарактеризуйте особенности построения и отличия ММВС сосредоточенного и распределенного типов.

3. В чем важнейшее отличие ММВС от автономных (централизованных) ВМ?

4. Посредством чего в ММВС осуществляется межпроцессное  взаимодействие?

5. Представьте основные системные вызовы для отправки и получения сообщений.

6. Чем отличаются блокирующие (синхронные) системные вызовы от неблокирующих (асинхронных)?

7. Какие проблемы возникают при организации программ с неблокирующими примитивами  и какие методы применяются для разрешения этих проблем?

8. В чем  заключается основная идея так называемого вызова удаленных процедур?

9. Опишите механизмы реализации вызовов удаленных процедур.

10. Охарактеризуйте наиболее часто встречающиеся классы отказов механизма вызова удаленных процедур и способы реакции системы на них.

11. Дайте определение понятиям «сетевая операционная система» и «сетевой протокол».

12. По какому принципу строятся сетевые средства связи?

13. Опишите основные функции вертикальных и горизонтальных  протоколов.

14. Что понимается под стеком протоколов вычислительной сети?

15. В чем отличие распределенных операционных систем от традиционных сетевых ОС?

16. Охарактеризуйте наиболее эффективные способы реализации распределенных операционных систем.

17. Приведите примеры практического построения разных типов промежуточного программного обеспечения.

Управление процессами и ресурсами в многомашинных вычислительных системах на http://mirrorref.ru


Похожие рефераты, которые будут Вам интерестны.

1. МОДЕЛИ ВЫЧИСЛЕНИЙ И УПРАВЛЕНИЯ РЕСУРСАМИ В РАСПРЕДЕЛЕННЫХ ВЫЧИСЛИТЕЛЬНЫХ СРЕДАХ

2. Основные способы параллельной обработки информации в вычислительных системах

3. Управление бизнес-процессами

4. Управление процессами в среде ОС Windows

5. Управление системами и процессами машиностроения

6. Управление ресурсами

7. Управление карьерными процессами в государственной службе России

8. Управление ресурсами банка

9. Управление человеческими ресурсами

10. Управление процессами обслуживания и качеством услуг на предприятиях индустрии гостеприимства