Шрифт:
Протокол конфигурирования должен быть гибким и надежным. В зависимости от размера сети, топологии и выдвигаемых требований, может быть полезна централизация загрузочной информации на одном сервере, распределение ее по нескольким серверам или выполнение реплицирования такой информации.
11.3 Возможности BOOTP
BOOTP был первым стандартом по автоматизации загрузки в окружении TCP/IP. После того как протокол прошел несколько этапов улучшения, он стал способен предоставлять системам все базовые конфигурационные параметры, а также несколько специализированных. Кроме того, BOOTP разрешает системам проводить поиск размещения необходимого программного обеспечения для загрузки.
Конфигурировать клиента BOOTP или DHCP очень просто. На рис. 11.1 показан выбор протокола в меню установки параметров программы Chameleon. Раскрывающееся окно разрешает пользователю указать адрес сервера BOOTP (если он известен). Если же адрес не введен, запрос на загрузку будет отправлен в широковещательной рассылке.
Рис. 11.1. Конфигурирование BOOTP на настольном клиентском компьютере
11.4 Необходимость DHCP
Область использования BOOTP ограничивает действия администратора, которому необходимо автоматизировать конфигурирование IP-адресов и не вводить вручную длинные списки аппаратных адресов вместе с соответствующими им IP-адресами. Администратору требуется защита от случайного изменения при конфигурировании IP-адресов, чтобы пользователь мог спокойно отключить систему и, перенеся ее на другое место сети, получить для системы правильные конфигурационные данные, а следовательно, быстро и без проблем запустить систему на новом месте.
DHCP расширяет возможности BOOTP и устраняет некоторые неопределенности, возникающие при использовании BOOTP и приводящие к неоптимальному взаимодействию в сети.
11.5 Первая версия BOOTP
Первоначально BOOTP разрабатывался для бездисковых рабочих станций. Современные условия привели к необходимости автоматизации загрузки систем, имеющих в ПЗУ (постоянном запоминающем устройстве, которое сохраняет информацию даже после отключения компьютера от сети. — Прим. пер.) только базовые средства для IP, UDP и TFTP. Исходный сценарий загрузки (см. рис. 11.2) выглядел следующим образом:
■ Клиент отправляет в широковещательной рассылке сообщение UDP на загрузочную информацию.
■ Сервер возвращает клиенту его IP-адрес и, при необходимости, местоположение файла загрузки.
■ С помощью простейшего протокола пересылки файлов (Trivial File Transfer Protocol — TFTP) клиент загружает в собственную память необходимое программное обеспечение и начинает работу.
Рис. 11.2. Локальное взаимодействие между сервером загрузки и клиентом
Администраторы быстро поняли, что лучше использовать BOOTP для загрузки большего объема конфигурационных данных и настраивать по этому протоколу системы с собственными жесткими дисками (которым не требуется загрузка программного обеспечения).
Системам, которым требуется TFTP для загрузки программного обеспечения, удобнее использовать один сервер для параметров BOOTP, а другой (или несколько) — для загрузки программного обеспечения (см. рис. 11.3). Например, программное обеспечение операционной системы лучше получать с сервера с тем же типом операционной системы, что и у клиента.
Рис. 11.3. Использование отдельных серверов для загрузки параметров и программного обеспечений
11.6 Эволюция BOOTP
Протокол BOOTP обеспечивает в работе достаточную гибкость:
■ Перед запуском клиент может не иметь никакой информации или быть частично сконфигурированным.
■ Клиент может получить информацию на сервере загрузки или выбрать для этого специально указанный сервер.
■ Клиент может не загружать программное обеспечение, загрузить его по умолчанию или загрузить определенный файл.
Прошло немного времени, и в сообщения BOOTP потребовалось включить дополнительные параметры — маску подсети, адрес маршрутизатора по умолчанию, адреса DNS и другую информацию.
Список дополнительных параметров постоянно увеличивался (полный список параметров BOOTP на момент выхода книги приведен в таблице 11.1), и скоро даже их часть уже не могла разместиться в сообщении UDP реалистичного размера. Для решения этой проблемы избыточные значения поместили в конфигурационном файле, который должен загружаться клиентом через TFTP. Идентификатор этого файла находится в основном сообщении UDP.