Лекция: Распределенные системы

Рис. 149

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

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

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

Рис. 150

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

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

Рис. 151

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

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

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

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

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

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

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

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

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

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

Рис. 152

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

Так как большинство распределенных систем использует в качестве основы Интернет, ключевыми протоколами этих систем являются два главных протокола Интернета: IP и TCP. Протокол IP (Internet Protocol – Интернет-протокол) представляет собой дейтаграммный протокол, в котором отправитель вбрасывает в сеть дейтаграмму размером до 64 Кбайт и надеется, что она достигнет получателя. Никаких гарантий не предоставляется. Дейтаграмма может фрагментироваться по пути на пакеты меньшего размера. Эти пакеты перемещаются по Интернету независимо друг от друга, возможно, по разным маршрутам. Когда все пакеты достигают адресата, они собираются в нужном порядке и доставляются получателю.

Поскольку получение IP-дейтаграмм не подтверждается, для надежной связи в Интернете одного протокола IP недостаточно. Надежную связь обеспечивает другой протокол, обычно устанавливаемый поверх протокола IP. Это протокол TCP (Transmission Control Protocol — протокол управления передачей). Протокол TCP использует протокол IP для обеспечения ориентированных на соединение потоков. Чтобы воспользоваться протоколом TCP, процесс сначала устанавливает соединение с удаленным процессом. Требуемый процесс обозначается IP-адресом машины и номером порта на этой машине, который прослушивают процессы, заинтересованные в получении входящего соединения. Когда соединение установлено, процесс просто передает по нему байты, которые гарантированно выходят с другого конца соединения неповрежденными и в правильном порядке. Реализация протокола TCP добивается этого при помощи порядковой нумерации, контрольных сумм и повторной передачи неверно полученных пакетов. Все это прозрачно для отправляющего и для получающего процессов. Они просто видят надежную межпроцессную связь, подобную каналу в системе UNIX.

Для установки соединения с удаленным хостом (даже чтобы просто послать дейтаграмму) необходимо знать его IP-адрес. Так как пользоваться списками 32-разрядных IP-адресов неудобно для людей, была разработана схема, называемая DNS (Domain Name System – служба имен доменов). Она представляет собой базу данных, преобразующую имена хостов в формате ASCII в их IP-адреса. Данная система позволяет использовать DNS-имя star.cs.vu.nl вместо соответствующего ему IP-адреса 130.37.24.6. DNS-имена получили большую популярность благодаря электронной почте Интернета, в которой адреса имели форму user-name@DNS-host-name. При такой системе имен почтовая программа на передающем хосте ищет IP-адрес хоста-получателя в базе данных DNS, устанавливает TCP-соединение с почтовым демоном на этой машине и посылает сообщение в виде файла. Имя пользователя user-name отправляется вместе с письмом, чтобы указать, в какой почтовый ящик должно быть помещено письмо.

Всемирная паутина (WWW, World Wide Web) была изобретена Тимом Бернерсом-Ли в 1989 году в Европейском центре ядерных исследований CERN (Conseil Europeen pour la Recherche Nucleaire) в Швейцарии. С тех пор это приложение распространилось по всему миру со скоростью лесного пожара.

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

Рис. 153

У каждой web-страницы есть уникальный адрес, называемый URL (Uniform Resource Locator – унифицированный указатель информационного ресурса), следующего вида: протокол://DNS-имя/имя_файла. Чаще всего применяется протокол http (HyperText Transfer Protocol – протокол передачи гипертекстовых файлов), но существуют также и другие протоколы, например, ftp. Следом за протоколом указывается DNS-имя хоста, содержащего файл. Наконец, указывается локальное имя файла, содержащего web-страницу.

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

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

Рис. 154

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

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

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

Квадратами на рис. 155 изображены каталоги, а кружочками – файлы. На рисунке показаны два файловых сервера, каждый из которых содержит три каталога и несколько файлов. На среднем рисунке мы видим систему, в которой для всех клиентов (и других машин) распределенная файловая система выглядит одинаково. Если путь /D/E/x есть на одной машине, то он есть и на другой.

Рис. 155

На крайнем правом рисунке, напротив, разные машины видят файловую систему по-разному. Путь /D/E/x может существовать на клиенте 1, но отсутствовать на клиенте 2. Для систем, работающих с удаленными серверами при помощи удаленного монтирования, ситуация на последнем рисунке является нормой. Такая схема обладает гибкостью и простотой реализации. Недостаток этого подхода заключается в том, что он не обеспечивает поведения всей системы как единой системы разделения времени. В системе разделения времени файловая система выглядит одинаково для всех процессов. Это облегчает программирование и работу в системе.

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

Рис. 156

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

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

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

Один из способов разрешения данной проблемы заключается в том, чтобы немедленно распространять все изменения кэшируемых файлов обратно на серверы. Альтернативное решение представляет собой ослабление семантики совместного использования файлов. Вместо требования, чтобы при системном вызове read был виден эффект всех предшествовавших системных вызовов write, новое правило звучит так: «Изменения всех открытых файлов изначально видны только процессу, сделавшему эти изменения. Только когда файл закрывается, эти изменения становятся видны другим процессам». Принятие такого правила не изменит ситуацию на рис. 156, б, но благодаря ему такое поведение (процесс В получает оригинальную версию файла) будет теперь считаться правильным. Когда клиент 1 закрывает файл, он посылает на сервер измененную копию файла, поэтому последующие системные вызовы read, как и требовалось, получат новую копию. Практически это все та же модель закачивания/скачивания. Данное семантическое правило широко применяется и называется сеансовой семантикой.

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

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