Э. Таненбаум, М. ван Стеен - Распределённые системы (принципы и парадигмы) (1162619), страница 58
Текст из файла (страница 58)
Этот подход соблюдается в системе именования Jade [371], емутакже следуют многие распределенные файловые системы.Рассмотрим набор пространств имен, распределенных по нескольким машинам. В частности, пусть каждое из пространств имен реализовано на своем сервере,которые, возможно, работают на разных машинах. Соответственно, если мы хотим смонтировать внешнее пространство имен NS2 с пространством имен NS1,нужно (если серверы NS2 и NS1 работают на разных Maunniax) организовать связьпо сети между этими серверами. Чтобы смонтировать внешнее пространство именв распределенной системе, необходима как минимум следующая информация:> имя протокола доступа;-f имя сервера;4^ имя монтирующей точки во внешнем пространстве имен.Отметим, что каждое из этих имен должно разрешаться.
Имя протокола доступа должно разрешаться реализацией этого протокола, при помощи которой организуется связь с сервером внешнего пространства имен. Имя сервера должноразрешаться посредством адреса сервера. И наконец, имя монтирующей точкидолжно разрешаться посредством идентификатора узла во внешнем пространстве имен.4.1. Именованные сущности223В нераспределенных системах любая из этих трех точек может оказаться невостребованной. Так, в системе UNIX нет ни протоколов доступа, ни серверов.Имя монтирующей точки также не является необходимым, поскольку это простокорневой каталог внешнего пространства имен.Имя монтирующей точки может быть разрешено сервером внешнего пространства имен.
Однако мы также нуждаемся в пространствах имен и реализациях для протокола доступа и имени сервера. Одна из возможностей предоставитьвсе эти три имени — это URL.Чтобы сделать разговор более конкретным, рассмотрим ситуацию, когда пользователь с портативным компьютером хочет получить доступ к удаленному файловому серверу.
И машина клиента, и файловый сервер сконфигурированы подсетевую файловую систему {Network File System^ NFS) фирмы Sun, которую мырассмотрим в подробностях в главе 10. NFS — это распределенная файловая система, в которую включен протокол, детально описывающий, как клиент можетполучить доступ к файлу, хранящемуся на (удаленном) файловом сервере NFS.В частности, чтобы система NFS работала через Интернет, клиент должен указать, к какому файлу он хочет получить доступ посредством URL, например,nfs://flits.cs.vu.nl//honne/steen.
Этот URL-адрес именует файл (который можетбыть и каталогом) с именем /home/steen на файловом сервере NFS flits.cs.vu.nl,доступ к которому возможен с использованием протокола NFS [80].Имя nfs широко известно, в том смысле, что существует глобальное соглашение о его интерпретации. Другими словами, при разборе того, что мы использовали в качестве URL, имя nfs разрешается реализацией протокола NFS. Имясервера разрешается его адресом DNS с помощью системы DNS, которую мы обсудим в следующем пункте. Как мы уже говорили, имя /home/steen разрешаетсясервером внешнего пространства имен.Организация файловой системы на клиентской машине частично приведенана рис. 4.4.
Корневой каталог имеет несколько определенных пользователем сущностей, включая вложенный каталог под названием /remote. Этот вложенный каталог предназначен для того, чтобы хранить монтажную точку внешних пространств имен, таких как домашний каталог пользователя университета Vrije.С этой стороны узел каталога с именем /remote/vu используется для храненияURL nfs://flits.cs.vu.nl//home/steen.Теперь рассмотрим имя /remote/vu/mbox.
Это имя разрешается, начиная скорневого каталога клиентской машины, и продолжает разрешаться там, покамы не достигнем узла /remote/vu. Затем разрешение имени продолжится возвращением URL nfs://flits.cs.vu.nl//home/steen, что, в свою очередь, заставляет клиентскую машину установить связь с файловым сервером flits.cs.vu.nl по протоколу NFS и получить доступ в каталог /home/steen.
Затем разрешение именипродолжается чтением файла mbox в этом каталоге.Распределенные системы позволяют монтировать удаленные файловые системы так, как это было продемонстрировано, разрешая клиентской машине, к примеру, выполнить следующие команды:cd /remote/vuIs -1224Глава 4. ИменованиеСервер именМашина Акlote /Сервер имен внешнего пространства имен\keys["nfs://flits.cs.vu.ni//home/steen^VМашина Вhome/y\stee.mbox iОперационнаясистемаТСетьСсылка на внешнеепространство именРис.
4.4. Монтирование удаленного пространства именпосредством особого протокола доступаЭти команды создают список файлов в каталоге /home/steen удаленного файлового сервера. Прелесть всего этого в том, что пользователь освобождается отдеталей доступа к удаленному серверу. В идеале он заметит разве что некоторуюпотерю производительности по сравнению с доступом к локальным файлам. Фактически пользователь будет считать, что пространства имен, расположенные налокальной машине и в каталоге /home/steen на удаленной машине, образуютединое пространство имен.Монтирование — это лишь один из способов объединения различных пространств имен. Другой подход, применяемый в глобальной службе имен {GlobalName Service, GNS) компании DEC, состоит в том, чтобы создать новый корневой узел, а существующие корневые узлы сделать дочерними от него [253].
Этотпринцип, который иллюстрирует рис. 4.5, рассмотрен ниже.Проблема подобного подхода состоит в том, что созданные имена иногда приходится изменять. Например, абсолютный путь /home/steen в пространстве имен NS1изменен на относительный путь, который разрешается, начиная с узла пО, и соответствует абсолютному пути /vu/home/steen. Чтобы решить эту проблему и позволить в будущем добавлять и другие пространства имен, имена в GNS всегда включают (неявно) идентификатор узла, с которого должно начинаться разрешение.Так, например, в пространстве имен NS1 на рисунке имя /home/steen/keys всегда расширяется для включения идентификатора узла пО, превращаясь в имяnO:/home/steen/keys.
Расширение обычно скрыто от пользователей. Оно означает, что идентификатор узла абсолютно уникален. Соответственно, узлы из различных пространств имен будут всегда иметь разные идентификаторы.4.1. Именованные сущности225mO-^homenO - • v u\—\NS1vumbox"m6:/mbox""np:/home/steen/keys"Рис. 4 . 5 . Организация глобальной службы имен компании DECОбъединение двух пространств имен NS1 и NS2 без изменения существующих имен происходит так, как показано на рисунке.
При добавлении нового корневого узла этот узел получает на хранение таблицу, отображающую идентификатор корневого узла NS1 на имя, под которым этот корень будет известен вновом пространстве адресов. То же самое происходит и с корневым узлом NS2.Разрешение имен всегда начинается с корня нового адресного пространства, имяnO:/home/steen после обнаружения идентификатора узла пО в таблице корневогоузла сначала преобразуется в имя /vu/home/steen.Потенциальная проблема GNS состоит в том, что корневой узел объединенного пространства имен требует поддерживать отображение идентификаторовстарых корневых узлов в их новые имена.
Если объединить тысячи пространствимен, этот подход может вызвать проблемы производительности.4.1.3. Реализация пространств именПространство имен формирует сердце службы именования, службы, которая позволяет пользователям и процессам добавлять, удалять и находить имена. Служба именования реализуется при помощи серверов имен. Если распределеннаясистема сокращена до размеров локальной сети, она вполне в состоянии реализовать службу именования при помощи всего лишь одного сервера имен. Однако вкрупных распределенных системах с множеством сущностей, возможно, разнесенных по множеству географических зон, необходимо разнести реализацию пространства имен по нескольким серверам имен.Распределение пространства именПространства имен крупномасштабных, возможно, глобальных распределенныхсистем обычно организованы иерархически. Как и ранее, мы предполагаем, что226Глава 4.
Именованиепространство имен имеет только один корневой узел. Для эффективной реализации этого пространства имен удобно разбить его на логические уровни. В [98] выделяют три уровня:4- глобальный уровень;4- администратршный уровень;4 управленческий уровень.Глобальный уровень (global layer) формируется узлами верхнего уровня, тоесть корневыми узлами и другими направляющими узлами, которые логическисвязаны с корневыми, то есть их дочерними узлами.
Узлы глобального уровняобычно характеризуются своей стабильностью, в том смысле, что их направляющие таблицы изменяются редко. Эти узлы могут представлять организации илигруппы организаций, имена которых хранятся в пространстве имен.Лдминистративгсый уровень (administrational layer) формируется из направляющих узлов, которые вместе представляют одну организацию. Характернойчертой направляющих узлов административного уровня является то, что онипредставляют группы сущностей, относящихся к одной и той же организацииили административной единице.
Например, это может быть направляющий узелвсех отделений организации или направляющий узел всех хостов. Другой направляющий узел может использоваться в качестве исходной точки для именования всех пользователей и т. д. Узлы административного уровня относительностабильны, хотя изменения в них вносятся в основном чаще, чем в узлы глобального уровня.И, наконец, управленческий уровень {managerial layer) состоит из узлов, которые обычно регулярно изменяются. Например, в этот уровень входят узлы, представляющие хосты локальной сети.
По той же причине этот уровень включаетузлы, предоставляющие совместно используемые файлы, такие как библиотекиили объектный код. Другим важным классом узлов управленческого уровня являются те, которые представляют каталоги и файлы пользователей. В противоположность глобальному и административному уровням, узлы управленческогоуровня обслуживаются не только системными администраторами, но и отдельными конечными пользователями распределенных систем.Чтобы конкретизировать предмет обсуждения, рассмотрим пример разбиения части пространства имен DNS, включающего имена файлов организации,к которым можно получить доступ через Интернет (например, web-страниц ифайлов, предназначенных для загрузки).
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
