Глава 16. Сетевые аппаратные средства 593

Окончание табл. 16.5

Тип оконечного устройства Цвет Кода

Комментарии

Ключевые телефонные системы Красный 184С

—

а В соответствии с цветовой моделью Pantone,

б Офисные АТС, компьютеры, локальные сети, мультиплексоры и т.д.

20. Основные задачи системы dns

Система DNS определяет следующее:

• •

• •

• •

иерархическое пространство имен компьютеров и IР-адресов;

таблицу имен и адресов компьютеров, реализованную в виде распределенной базы данных;

“распознаватель” — клиентскую библиотеку функций, осуществляющих запросы к базе данных DNS;

усовершенствованные средства маршрутизации и аутентификацию отправителей сообщений электронной почты;

механизм поиска служб в сети;

протокол обмена информацией об именах.

Глава 17. Система доменных имен 599

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

Управление системой DNS

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

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

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

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

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

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

17.2. Как работает система DNS

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

600 Часть II. Работа в сети

Записи о ресурсах

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

Например, строки

nubark IN А 63.173.189.1

IN MX 10 mailserver.atrust.com.

в файле “прямого преобразования” (с именем atrust.com) и строка 1 IN PTRnubark.atrust.com.

в файле “обратного преобразования” (с именем 63.173.189.rev) связывают сайт nubark.atrust.com с IP-адресом 63.173.189.1. Запись MX перенаправляет сообщение электронной почты, адресованное на эту машину, на компьютер mailserver.atrust.com.

Записи о ресурсах — это универсальный язык системы DNS. Они не зависят от фай­ лов конфигурации, управляющих операциями, которые выполняются на любой реали­ зации данного сервера DNS. Все они являются фрагментами данных, циркулирующих внутри системы DNS, и кешируются в разных местах.

21. Сетевой протокол Network File System

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

Протокол NFS разработала компания Sun Microsystems в 1984 году. Первоначально протокол NFS был реализован как суррогат файловой системы для бездисковых кли­ ентов, однако предложенный протокол оказался столь удачным, что со временем стал универсальным решением проблемы совместного использования файлов. Все дистри­ бутивные пакеты систем UNIX и Linux содержат версию протокола NFS; многие из них используют лицензию компании Sun. В настоящее время протокол NFS открыто описан в документах RFC (см. RFC1094, RFC1983 и особенно RFC 3530).

18.1. Введение в протокол NFS

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

736 Часть II. Работа в сети

портят данные и не вызывают ярость пользователей, но для того, чтобы этого достичь, пришлось немало потрудиться.

Проблемы, связанные с состоянием

При разработке файловой системы необходимо решить, какая ее часть будет отсле­ живать файлы, открываемые каждым клиентом. Информация об этих файлах называ­ ется “состоянием” (state). Сервер, не делающий записей о статусе файлов и клиентов, называется сервером без сохранения состояния (stateless), а сервер, который решает эту задачу, — сервером с сохранением состояния (stateful). Многие годы использовались оба этих подхода, причем каждый из них имеет как преимущества, так и недостатки.

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

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

Проблемы производительности

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

Большинство протоколов пытается минимизировать количество запросов в сети. Например, предварительное кеширование предусматривает загрузку фрагментов файла в буфер локальной памяти, чтобы избежать задержки при считывании нового раздела файла. Часть полосы пропускания используется для того, чтобы избежать обмена ин­ формацией с сервером в ходе общего цикла сканирования сети (full round trip exchange). Кроме того, некоторые системы кешируют записи в памяти и посылают их обновления в пакетах, уменьшая тем самым задержку, вызванную необходимостью выполнить опе­ рации записи на сервере. Эти пакетные операции обычно называют объединением за­ просов (request coalescing).

Безопасность

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