Э. Таненбаум, М. ван Стеен - Распределённые системы (принципы и парадигмы) (1162619), страница 60

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 60)

Как и при итеративномразрешении имен, последний шаг разрешения, а именно контакт с FTP-сервероми запрос на передачу файла, происходят на клиенте в виде отдельного процесса.1. <nl,vu,cs,ftp>8. #<nl,vu,cs,ftp>7. #<vu,cs,ftp> VПроцедураразрешенияименклиента6. #<cs,ftp>2. <vu,cs,ftp>Сервер именузла п13. <cs,ftp>Сервер именузла VU5.

#<ftp><nl.vu ,cs,ftp>Корневойсервер имен4. <ftp>Сервер именузла CS#<nl,vu,cs,ftp>Рис. 4.8. Принцип рекурсивного разрешения именОсновной недостаток рекурсивного разрешения имен состоит в том, что кпроизводительности каждого из серверов имен предъявляются повышенные тре­бования. Сервер имен должен быть в состоянии осуществить полное разрешениепути, хотя он мог бы делать это и в кооперации с другими серверами имен. Этадополнительная нагрузка обычно столь высока, что серверы имен глобальногоуровня'поддерживают только итеративное разрешение имен.У рекурсивного разрешения имен имеется два важных достоинства. Первоеиз них состоит в том, что кэширование результатов по сравнению с итеративнымразрешением имен более эффективно.

Второе — это снижение затрат на взаимо­действие. Эти преимущества объясняются тем, что процедура разрешения именклиента получает только пути к узлам глобального или административногоуровня. Для разрешения частей пути, относящихся к управленческому уровню,клиент отдельно связывается с сервером имен, адрес которого был возвращенему процедурой разрешения имен. Мы говорили об этом выше.4.1. Именованные сущности231Рекурсивное разрешение имен позволяет каждому серверу имен последова­тельно получать адрес каждого из серверов, ответственных за узлы нижнегоуровня.

В результате можно с успехом применить кэширование для повышенияпроизводительности. Так, если корневой сервер требует разрешить путь root:<nl,vu, cs, ftp>, он может в результате получить адрес сервера имен, реализующегоузел, соответствующий этому пути. Чтобы прийти к этому, сервер имен узла п1должен найти адрес сервера имен узла vu, а последний, в свою очередь, долженнайти адрес сервера имен, отвечающего за узел cs.Поскольку изменения в узлах глобального и административного уровнейпроисходят нечасто, корневой сервер имен может успешно кэшировать получен­ный адрес.

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

Этот адрес может быть возвращен корневому серверу в ходе воз­вращения сервером п1 результатов поиска по исходному имени. Полный обзорпроцесса разрешения результатов, которые могут быть кэшированы на каждойиз стадий этого процесса, приведен в табл. 4.2.Таблица 4 . 2 . Рекурсивное разрешение имени <п1, vu, cs, ftp>СерверузлаОбъектразрешенияПоискПередачадочернемуузлуПолучениеи кэшированиеВозвращениев ответна запросCS<ftp>#<ftp>——#<ftp>VU<cs,ftp>#<cs><ftp>#<ftp>#<cs>#<cs, ftp>п1<vu,cs,ftp>#<vu><cs,ftp>#<cs>#<cs,ftp>#<vu>#<vu,cs>#<vu,cs,ftp>root<nl,vu,cs,ftp>#<nl><vu,cs,ftp>#<vu>#<vu,cs>#<vu,cs,ftp>#<nl>#<nl,vu>#<nl,vu,cs>#<nl,vu,cs,ftp>Достоинство подобного подхода в том, что операции поиска со временем мо­гут стать потрясающе эффективными.

Так, представим себе, что позже разрешитьпуть root:<nl, vu, cs, flits> потребует другой клиент. Это имя поступит в корневойузел, а оттуда немедленно будет передано серверу имен узла cs, к которому и по­ступит запрос на разрешение остатка пути cs:<flits>.При итеративном разрешении имен кэширование по необходимости ограни­чивается процедурой разрешения имен клиента. Соответственно, если клиент Лзапрашивает разрешение некоторого имени, а затем клиент В требует разрешитьто же самое имя, разрешение имен потребует повторного прохода через те же са­мые серверы, через которые мы уже проходили для клиента А. В качестве компромиса многие организации задействуют локальные промежуточные серверы232Глава 4.

Именованиеимен, совместно используемые всеми клиентами. Эти локальные серверы именобрабатывают все запросы на имена и кэшируют их результаты. Такие промежу­точные серверы удобны и с точки зрения управления. Например, только этотсервер должен знать, где находится корневой сервер имен, другие машины вэтой информации не нуждаются.Второе достоинство рекурсивного разрешения имен состоит в том, что оночасто экономней с точки зрения взаимодействия. Рассмотрим вновь разрешениепути root:<nl, VU, cs, ftp> в предположении, что клиент находится в Сан-Франци­ско. Предполагая, что клиент знает адрес сервера узла п1, при рекурсивном разре­шении имен образуется связь между хостом клиента в Сан-Франциско и серве­ром в Нидерландах, помеченная на рис.

4.9 как R1. После этого вам потребуетсясвязь между сервером п1 и сервером имен университета Vrije в университетскомгородке в Амстердаме, Нидерланды. Эта связь обозначена как R2. И наконец, не­обходима связь между сервером vu и сервером имен факультета компьютерныхдисциплин (Computer Science Department), обозначенная как ЯЗ. Ответ пройдетпо тому же пути, но в обратном направлении. Понятно, что затраты на взаимо­действие будут определяться обменом сообщениями между хостом клиента исервером п1.Рекурсивноеразрешение имен R IСервер именузла п1IR2Сервер именузла VUIR1Сервер именузла CSразрешение именДальняя связьРис. 4 .

9 . Сравнение между рекурсивным и итеративным разрешением именс точки зрения затрат на взаимодействиеВ противоположность этому, при итеративном разрешении имен хост клиен­та связывается по отдельности с серверами п1, vu и cs, в результате чего общиезатраты будут почти в три раза выше, чем при рекурсивном разрешении. Стрел­ки на рисунке с метками 11,12 и 13 обозначают взаимодействие при итеративномразрешении имен.4.1.4. Пример — система доменных именОдной из самых больших на сегодня распределенных служб именования являетсясистема доменных имен (Domain Name System, DNS) Интернета.

DNS использу­ется в первую очередь для поиска адресов хостов и почтовых серверов. На сле­дующих страницах мы сосредоточимся на организации пространства имен сис­темы DNS и информации, хранящейся на ее узлах. Кроме того, мы поближе4 . 1 . Именованные с у щ н о с т и233ознакомимся с существующей реализацией DNS. Дополнительную информациюпо этой теме можно найти в [8, 301].Пространство имен DNSПространство имен DNS иерархически организовано в виде дерева с корнем.Метка представляет собой не зависящую от регистра строку алфавитно-циф­ровых символов. Максимальная длина метки — 63 символа, полная длина путиограничена 255 символами. Строковое представление пути состоит из списка ме­ток, начиная справа, разделенных точками. Корень также представлен точкой.Так, например, путь root:<nl, vu, cs, flits> представляется строкой flits.cs.vu.nl., вклю­чая точку справа, которая означает корень.

Обычно для удобства чтения мы бу­дем опускать эту точку.Поскольку каждый из узлов в пространстве имен DNS имеет ровно одно вхо­дящее ребро (за исключением корня, который входящих ребер не имеет), меткавходящего в узел ребра используется также и в качестве имени этого узла. Под­дерево называется доменом (domain), а путь к корневому узлу домена — домен­ным именем (domain пате). Отметим, что, как и путь, доменное имя может бытьабсолютным или относительным.Содержимое узла комплектуется из набора записей о ресурсах (resource re­cords).

Существуют различные типы записей о ресурсах, наиболее важные из нихперечислены в табл. 4.3.Таблица 4 . 3 . Наиболее важные типы записей о ресурсахТип записиСущность записиОписаниеSOAЗонаИнформация о соответствующей зонеАХостIP-адрес хоста, на котором установлен узелMXДоменПочтовый сервер, обрабатывающий почтовыеадреса узлаSRVДоменСервер, предоставляющий некоторую службуNSЗонаСервер имен, отвечающий за определенную зонуCNAMEУзелСимволическая ссылка на первичное имясоответствующего узлаPTRХостКаноническое имя хостаHINFOХостИнформация о хосте, на котором установлен узелTXTЛюбая сущностьДополнительная информация, зависящаяот сущностиУзел в пространстве имен DNS часто представляет одновременно несколькосущностей.

Так, например, доменное имя vu.nl используется для представлениядомена и зоны. В данном случае домен реализован в нескольких зонах.Запись о ресурсе SOA (start of authority — начало полномочий) содержит та­кую информацию, как, например, почтовый адрес системного администратора,отвечающего за указанную зону, имя хоста, на котором находятся данные о зонеи т. д.234Глава 4. ИменованиеЗапись А (address — адрес) представляет отдельный хост в Интернете. Эта за­пись содержит IP-адрес хоста, используемый при взаимодействии. Если хост име­ет несколько IP-адресов, например, в случае машин с множественной адресацией,узел будет содержать запись А для каждого адреса.Важный тип записи о ресурсах ~ MX (mail exchange — почтовый обмен).

Этазапись является символической ссылкой на узел, представляющий почтовый сер­вер. Например, пусть узел, представляющий домен cs.vu.nl, имеет запись MX, со­держащую имя zephyr.cs.vu.nl, которое относится к почтовому серверу. Этот сер­вер будет обрабатывать все адреса для входящих почтовых сообщенийпользователей домена cs.vu.nl. Узел может иметь несколько записей MX.Записи SRV похожи на записи MX. Такая запись содержит имя сервера конкрет­ной службы. Записи SRV определены в [477]. Конкретная служба определяется поее имени вместе с именем протокола. Так, web-сервер домена cs.vu.nl может бытьпоименован при помощи такой записи SRV, как http.tcp.cs.vu.nl.

Эта запись можетссылаться затем и на реальное имя сервера (soHng.cs.vu.nl).Узлы, представляющие зону, содержат одну или более записей NS (name ser­ver — сервер имен). Как и запись MX, запись NS содержит имя сервера имен, реа­лизующего зону, представленную узлом. В принципе каждый узел пространстваимен может иметь запись NS, ссылающуюся на сервер имен, который его реализу­ет. Однако, как мы ранее говорили, реализация пространства имен DNS такова,что необходимость содержать записи NS существует только для узлов, представ­ляющих зону.DNS выделяет псевдонимы для того, что называется капопическьши глменами{canonical names). Предполагается, что каждый хост имеет каноническое, или пер­вичное, имя. Псевдоним реализуется посредством узла, хранящего запись CNAME(canonical name — каноническое имя), которая содержит каноническое имя хоста.Имя узла, на котором хранится эта запись, совпадает с именем символическойссылки, как показано на рис.

Характеристики

Список файлов книги