Э. Таненбаум, М. ван Стеен - Распределённые системы (принципы и парадигмы) (1162619), страница 59
Текст из файла (страница 59)
Этот пример иллюстрирует рис. 4.6.Пространство имен разделено на неперекрывающиеся части, которые [301] в DNSназываются зонами {zones). Зона — это часть пространства имен, реализованнаяотдельным сервером имен (некоторые из зон показаны на рисунке).Что касается доступности и производительности, серверы имен каждогоуровня имеют к ним различные требования.
Высокая доступность особенно важна для серверов имен глобального уровня. Если происходит сбой сервера имен,большая часть пространства имен оказывается недоступной, поскольку разрешение имен не может «перескочить через голову» иерархии имен на оконечные серверы.4 . 1 . Именованные с у щ н о с т и227Глобальныйуровеньo c e V - Y vuI eng / c s V рjack/\jiillк'ёГо"|'п"Административный <;уровеньai/\lindarobotcscsl 1pc24ftptp /\ www 1i^pu6"-^globeУправленческийуровень^jf index.txt /ЗонаРис. 4 .
6 . Пример разбиения пространства имен DNS на три уровняТребования к производительности не столь жесткие. Поскольку узлы глобального уровня изменяются медленно, результаты операции поиска будут верны в течение длительного времени. Соответственно, эти результаты могут бытьэффективно подвергнуты кэшированию (то есть локально сохранены) на клиенте.
При осуществлении той же операции поиска в следующий раз результат может быть извлечен из кэша клиента без обращения к серверам имен. В результате серверы имен глобального уровня не должны часто отвечать на одинаковыепоисковые запросы. С другое! стороны, производительность может быть важнымфактором, особенно в крупных системах с миллионами пользователей.Требования по доступности и производительности серверов имен глобального уровня должны удовлетворяться репликацией серверов в комбинации с кэшированием на стороне клиента.
Как мы выясним в главе 6, изменения, вносимыена этом уровне, не обязаны вступать в силу немедленно, что значительно облегчает поддержание непротиворечивости реплик.Доступность серверов имен административного уровня особенно важна дляклиентов, относящихся к той же организации, которую обслуживает данный сервер имен. Если с сервером имен происходит сбой, множество ресурсов организации оказываются недоступными, поскольку их просто невозможно найти. С другой стороны, для пользователей вне этой организации временная недоступностьее ресурсов не столь важна.Что касается производительности, серверы имен административного уровняимеют параметры, сходные с серверами глобального уровня.
Поскольку измене-228Глава 4 . Именованиения узлов происходят не слишком часто, кэширование результатов поиска может быть весьма эффективным, а это делает производительность менее критичной. Однако в отличие от глобального уровня административный уровень долженобеспечить возвращение результатов поиска в течение нескольких миллисекунд,независимо от их источника (непосредственно с сервера или из локального кэшаклиента).
Изменения также должны вноситься быстрее, чем на глобальном уровне. Так, например, недопустимо, чтобы от создания до активизации нового пользователя проходило несколько часов.Эти требования обычно подразумевают использование в качестве серверовимен высокопроизводительных машин. Кроме того, может применяться и кэширование на стороне клиента в сочетании с репликацией серверов для повышенияобщей доступности.Требования к доступности серверов имен управленческого уровня обычноменее серьезны.
В частности, для работы сервера имен нередко достаточно одноймашины (выделенной), даже с риском временной недоступности. Однако критична производительность. Пользователи требуют, чтобы операции осуществлялись немедленно. Поскольку изменения вносятся постоянно, кэширование наклиенте обычно малоэффективно, если только не применять специальных мер,которые будут обсуждаться в главе 6.Сравнение серверов имен различных уровней приведено в табл. 4.1. В распределенных системах серверы имен глобального и административного уровнейреализовывать нелегко. Трудности связаны с репликацией и кэшированием, которые необходимы для достижения нужной производительности и доступности,но создают проблемы с непротиворечивостью. Некоторые из этих проблем усугубляются тем фактом, что кэши и реплики разнесены по глобальной сети, которая вносит длительные задержки связи и значительно затрудняет синхронизацию. Репликация и кэширование детально обсуждаются в главе 6.Т а б л и ц а 4 , 1 .
Сравнение серверов имен при реализации узловв большом пространстве именЭлементГлобальныйуровеньАдминистративныйуровеньУправленческийуровеньГеографический масштаб сетиВсемирнаяОрганизацияОтделОбщее число узловНесколькоМногоОгромное числоВремя поискаСекундыМиллисекундыНемедленноРаспространение измененийМедленноеНемедленноеНемедленноеЧисло репликМножествоМало или нетНетКэширование на клиентеДаДаИногдаРеализация разрешения именРаспределенность пространства имен по множеству серверов имен затрудняетреализацию разрешения имен.
Чтобы пояснить реализацию разрешения имен вкрупных службах имен, представим себе, что серверы не реплицируются и кэширование на стороне клиента не используется. Каждый клиент имеет доступ к ло-4.1. Именованные сущности229калькой процедуре разрешения имен {пате resolver), которая и отвечает за этотпроцесс. В соответствии с рис. 4.6 предположим, что разрешается (абсолютный)путь:root:<nl, VU, OS, ftp, pub, globe, jndex.txt>Если использовать форму записи URL, этот путь соответствует имениftp://ftp.cs.vu.nl/pub/globe/index.txt.
Теперь у нас есть два способа реализации разрешения имен.При итеративном разрешении имени {iterative пате resolution) процедура разрешения имен передает полное имя корневому серверу имен. Предполагается,что адрес корневого сервера, с которым контактирует процедура разрешения имен,общеизвестен. Корневой сервер разрешит ту часть пути, которую сможет, и вернет результат клиенту. В нашем примере корневой сервер может разрешить только метку п1, для которой он и вернет адрес ассоциированного с ней сервера имен.После этого клиент передаст этому серверу имен оставшуюся часть пути (тоесть имя nl:<vu, cs, ftp, pub, globe, index.txt>).
Сервер сможет разрешить толькометку VU и вернет адрес ассоциированного с этой меткой сервера имен вместе составшейся частью пути, vu:<cs, ftp, pub, globe, index.txt>.Процедура разрешения имен клиента свяжется со следующим сервером имен,который сможет разрешить метку cs, а также ftp и вернет адрес FTP-сервера вместе с путем ftp:<pub, globe, index.txt>. После этого клиент свяжется с FTP-сервером и потребует от него разрешить остаток исходного пути. FTP-сервер разрешит последовательно метки pub, globe и jndex.txt и передаст запрошенный файл(в данном случае по протоколу FTP). Подобный процесс итеративного разрешения иллюстрирует рис. 4.7 (запись #<cs> используется для указания адреса сервера, отвечающего за обработку метки <cs>).1.
<nl.vu,cs.ftp>2. #<nl>, <vu,cs,ftp>Корневойсервер имен•.•-•:!:VL.3. <vu,cs,ftp>Процедураразрешенияименклиента4. #<vu>, <cs,ftp>5. <cs.ftp>6. #<cs>, <ftp>7. <ftp>8. #<ftp><nl,vu,cs,.ftp>|j#<nl,vu,cs,ftp>Узлы,обслуживаемыеодним серверомименРис. 4.7. Принцип итеративного разрешения именНа практике последний шаг, а именно связь с FTP-сервером и запрос на передачу файла с путем ftp:<pub, globe, index.txt>, выполняется клиентским процес-230Глава 4.
Именованиесом отдельно от всего остального. Другими словами, клиент обычным образомобрабатывает только путь root:<nl, vu, cs, ftp>, из которого он извлекает адрес, покоторому находится FTP-сервер, как и показано на рисунке.Альтернативой итеративному разрешению имен является использование в ходе разрешения рекурсии. Вместо того чтобы возвращать процедуре разрешенияимен клиента промежуточные результаты, при рекурсивном разрешении имени{recursive пате resolution) сервер имен передает эти результаты следующему обнаруженному серверу имен.
Рассмотрим, например, что происходит, когда корневой сервер обнаруживает адрес сервера имен, реализованного на узле с именем п1. Он требует от сервера имен разрешить путь nl:<vu, cs, ftp, pub, globe,index.M>. Используя и далее рекурсивное разрешение имен, этот следующийсервер разрешит путь целиком и вернет файл index.txt корневому серверу, который, в свою очередь, передаст его процедуре разрешения имен клиента.Рекурсивное разрешение имен иллюстрирует рис. 4.8.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
