Руководство по управлению системой: Сети и средства связи

Демон PXE Proxy DHCP (pxed)

Сервер PXE Proxy DHCP действует примерно так же, как и сервер DHCP: он просматривает сообщения клиентов DHCP и отвечает на некоторые запросы. Однако, в отличие от сервера DHCP, сервер PXE Proxy DHCP не управляет сетевыми адресами, а всего лишь отвечает на запросы клиентов, идентифицирующих себя как клиенты PXE. На основании ответов сервера PXE Proxy DHCP клиенты могут найти сервер загрузки или сетевые адреса и описания поддерживаемых и совместимых серверов загрузки.

Использование сервера PXE Proxy DHCP вместе с сервером DHCP позволяет получить определенные преимущества. Во-первых, вы можете отделить администрирование сетевых адресов от администрирования образов загрузки. Один процесс системы может управлять информацией о загрузке с помощью сервера PXE Proxy DHCP, а другой независимый процесс - конфигурацией сервера DHCP. Во-вторых, вы можете определить несколько серверов загрузки, позволяя клиенту выбрать конкретный сервер непосредственно перед загрузкой. Различные серверы загрузки могут содержать информацию для различных операционных систем или конфигураций. Кроме того, сервер proxy позволяет клиентам PXE использовать групповые IP-адреса при поиске совместимых серверов загрузки.

Сервер PXE Proxy DHCP можно настроить как в той же системе, в которой работает сервер DHCP, так и в другой системе. Кроме того, его можно настроить как в той же системе, где работает демон сервера загрузки, так и в другой системе.

Сервер PXE Proxy DHCP

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

База данных PXED

Для создания списка ответов на пакет REQUEST, полученный от клиента, применяется база данных db_file.dhcpo. Значения, возвращаемые базой данных, зависят от выбранного типа сервера. Значения задаются ключевым словом pxeservertype в файле pxed.cnf.

База данных заполняется и проверяется в соответствии с информацией, заданной в файле конфигурации.

Средства поддержки протокола PXED

Средства поддержки протокола PXED основаны на спецификациях Intel Preboot Execution Environment (PXE) версии 2.1 и совместимы со спецификацией Intel PXE версии 1.1. Отправляемая клиентам информация о конфигурации определяется с помощью базы данных.

Служебные нити PXED

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

Первая нить, main, обрабатывает запросы SRC (такие, как startsrc, stopsrc, lssrc, traceson и refresh). Кроме того, эта нить согласовывает все операции, влияющие на остальные нити, и обрабатывает сигналы. Пример:

• SIGHUP (-1) обновляет все базы данных в файле конфигурации.
• SIGTERM (-15) завершает работу сервера в нормальном режиме.

Остальные нити выполняют обработку пакетов. В зависимости от типа сервера, может быть создана одна или две нити. Одна нить ожидает сигнала на порту 67, а вторая - на порту 4011. Каждая нить может обрабатывать запрос клиента.

Настройка демона PXED

По умолчанию сервер PXED считывает информацию из файла /etc/pxed.cnf, в котором хранится исходная база данных параметров и адресов сервера. Сервер может запускаться с помощью Web-администратора системы, SMIT или команды SRC.

Настройка сервера PXED - это самая трудная часть настройки PXED в сети. Во-первых, определите, в каких сетях будут размещаться клиенты PXE. В следующем примере демон pxed будет работать в той же системе, что и сервер DHCP:

pxeservertype       proxy_on_dhcp_server
 
subnet default
{
    vendor pxe
    {
        option    6      2       # Отключить групповые адреса сервера загрузки
        option    8      1   2     9.3.4.5    9.3.4.6   2    1    9.3.149.29
                                 # Выше приведен список серверов загрузки
        option    9      0       "PXE bootstrap server" \
                         1       "Microsoft Windows NT Boot Server"  \
                         2       "DOS/UNDI Boot Server"
        option    10    20    "задержка (в секундах) перед автоматическим выбором первой опции меню"
     }
}

Опции контейнера vendor отправляются клиенту PXE только в том случае, если IP-адрес клиента принадлежит диапазону адресов подсети (9.3.149.0 - 9.3.149.255).

В следующем примере демон pxed будет работать в другой системе, чем сервер DHCP:

subnet default
{
    vendor pxe
    {
        option    6      10      # Имя файла загрузки указано в начальном пакете pxed,
                                 # полученном от клиента
        option    8      1   2     9.3.4.5    9.3.4.6   2    1    9.3.149.29
                                 # Выше приведен список серверов загрузки
        option    9      0       "PXE bootstrap server" \
                         1       "Microsoft Windows NT Boot Server"  \
                         2       "DOS/UNDI Boot Server"
        option    10    20    "задержка (в секундах) перед автоматическим выбором первой опции меню"
        bootstrapserver          9.3.148.65
        pxebootfile    1    2    1   window.one
        pxebootfile    2    2    1   linux.one
        pxebootfile    1    2    1   hello.one
        client 6 10005a8ad14d any
        {
           pxebootfile    1    2    1   aix.one
           pxebootfile    2    2    1   window.one
        }
    }
 
Vendor pxeserver
{
    option     7     224.234.202.202
}

В файле конфигурации не указано ключевое слово pxeservertype, поэтому будет применяться значение по умолчанию pdhcp_only, означающее, что сервер PXED работает на другом компьютере, чем сервер DHCP. В этой конфигурации сервер PXED ожидает пакетов BINLD REQUEST/INFORM от клиентов на двух портах( 67 и 4011). Опция 7 отправляется серверу BINLD, когда сервер PXED получает пакет REQUEST/INFORM на порту 67 от BINLD, а опция 60 указывает на сервер PXED.

Директива db_file указывает, какой метод базы данных должен применяться для обработки этой части файла конфигурации. Комментарии начинаются с символа #. Символы, стоящие в строке после символа #, игнорируются сервером PXED. С помощью каждой строки option сервер задает для клиента какое-либо действие. В разделе Опции контейнера PXED описаны все поддерживаемые и известные опции. В разделе Формат файла сервера PXED для выполнения общих операций описаны способы задания опций, неизвестных серверу.

Файл конфигурации

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

Контейнер (по существу, это способ группирования параметров) позволяет объединять клиентов в группы на основании идентификатора. Типы контейнеров: subnet, class, vendor и client. Контейнеры, определяемые пользователем, в настоящее время не поддерживаются. Клиент однозначно определяется своим идентификатором, что позволяет всегда точно обнаруживать его, например, при переносе в другую подсеть. Для определения клиента может применяться несколько контейнеров.

Опции - это идентификаторы, возвращаемые клиенту. Это может быть, например, применяемые по умолчанию адреса шлюза и сервера DNS.

Контейнеры

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

.

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

Для идентификации клиентов в разных типах контейнеров применяются различные опции:

• Для определения подсети, в которой находится клиент, контейнер subnet использует поле giaddr или адрес принимающего интерфейса.
• Контейнер class использует значение опции 77 (идентификатор класса пользователя).
• Контейнер vendor использует значение опции 60 (идентификатор класса вендора).
• Контейнер client использует значение опции 61 (идентификатор клиента) для клиентов PXE и поле chaddr в пакете BOOTP для клиентов BOOTP.

Во всех контейнерах, кроме subnet, можно применять шаблоны сравнения, включая регулярные выражения.

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

Основные правила для контейнеров и подконтейнеров:

• На глобальном уровне допустимы все контейнеры.
• Контейнеры subnet нельзя помещать в другие контейнеры.
• В контейнеры с ограничениями нельзя помещать обычные контейнеры того же типа. (Например, если контейнер содержит опцию, разрешающую только класс Accounting, то в него нельзя помещать контейнер, который содержит опцию, разрешающую применение всех классов, имена которых начинаются с буквы "a". Это недопустимо.)
• Контейнеры client с ограничениями не могут содержать вложенные контейнеры.

С помощью этих правил вы можете создавать иерархию контейнеров, в которой опции объединены в наборы, соответствующие конкретным клиентам или группам клиентов.

Каким образом организована обработка адресов и опций, если клиент входит в несколько контейнеров? Сервер DHCP получает сообщение, формирует запрос к базе данных (в данном случае - к файлу db_file) и получает список контейнеров. Контейнеры перечисляются в списке в порядке их вложенности и приоритета. Приоритет определяется как неявный иерархический уровень контейнера. Контейнеры с ограничениями имеют более высокий приоритет, чем обычные. Сортировка контейнеров выполняется в таком порядке: клиенты, классы, вендоры и подсети. В пределах одного типа контейнеры упорядочиваются по уровню вложенности. Созданный таким образом список упорядочивается от более конкретных объектов к менее конкретным. Например:

    Subnet 1
    --Class 1
    --Client 1
    Subnet 2
    --Class 1
    ----Vendor 1
    ----Client 1
    --Client 1

В примере есть две подсети Subnet 1 и Subnet 2. Кроме того, определен один класс, Class 1, один вендор, Vendor 1, и один клиент, Client 1. Class 1 и Client 1 определены в разных местах. Поскольку они они определены в разных контейнерах, то их имена могут совпадать, однако, указанные в них значения могут различаться. Если клиент Client 1 отправит сообщение серверу DHCP из подсети Subnet 1 с указанием класса Class 1, определенного в списке опций этого клиента, то сервер DHCP создаст следующий список контейнеров:

Subnet 1, Class 1, Client 1

Контейнер, определенный наиболее точно, заносится в список последним. Для получения адреса список просматривается в обратном порядке до обнаружения первого доступного адреса. Затем список просматривается в прямом порядке (в соответствии с иерархией) для получения опций. По мере просмотра списка, новые значения опций переопределяют прежние значения до тех пор, пока в контейнере не встретится опция deny. Поскольку класс Class 1 и клиент Client 1 находятся в одной и той же подсети Subnet 1, они упорядочиваются в соответствии с приоритетом контейнеров. Если сообщение будет получено от клиента с тем же именем, находящегося в подсети Subnet 2, то будет создан следующий список контейнеров:

Subnet 2, Class 1, Client 1 (на уровне Subnet 2), Client 1 (на уровне Class 1 )

Первой в списке указывается подсеть Subnet 2, затем класс Class 1, затем клиент Client 1 на уровне Subnet 2 (так как этот клиент находится в иерархии на один уровень ниже). Иерархия подразумевает, что клиент, имя которого указано в первом операторе, определен менее конкретно, чем клиент Client 1, определенный в классе Class 1 подсети Subnet 2.

Приоритет, определяемый по уровню вложенности, выше, чем приоритет самих контейнеров. Например, если тот же клиент отправит такое же сообщение, указав идентификатор вендора, то список контейнеров будет следующим:

Subnet 2, Class 1, Vendor 1, Client 1 (на уровне Subnet 2), Client 1 (на уровне Class 1)

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

Адреса и диапазоны адресов

С контейнерами любого типа могут быть связаны диапазоны адресов. Контейнеры subnet обязательно имеют связанный диапазон адресов. Каждый диапазон адресов в пределах контейнера должен быть подмножеством диапазона адресов родительского контейнера и не должен пересекаться с диапазонами адресов других контейнеров. Например, если внутри подсети определен класс с диапазоном адресов, то этот диапазон должен быть подмножеством диапазона адресов подсети. Диапазон внутри этого контейнера класса не должен пересекаться с любыми другими диапазонами этого уровня.

Диапазоны адресов могут задаваться в строке контейнера. Для задания несмежных диапазонов адресов можно воспользоваться операторами range и exclude. Таким образом, если в подсети есть два диапазона по десять адресов, то имеет смысл указать эти диапазоны в операторе subnet, чтобы уменьшить объем памяти и избежать конфликтов адресов с другими клиентами.

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

Опции

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

Ведение протокола

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

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

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

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

Кроме того, если применяются записи logItem INFO и TRACE, то в протокол при обработке каждого сообщения клиента PXE заносится несколько сообщений. Добавление строк в файл протокола может привести к чрезмерному увеличению нагрузки; поэтому ограничение объема заносимой в протокол информации повышает производительность сервера DHCP. Протокол можно подключить динамически с помощью команды SRC traceson.

Опции контейнера PXE

При работе с клиентом PXE сервер DHCP передает следующую опцию серверу BINLD для настройки этого сервера:

Синтаксис файла сервера PXED для общих операций сервера

Примечание: Используемые в таблицы единицы времени (единицы_времени) являются необязательными и применяются в качестве модификаторов значений времени. По умолчанию время указывается в минутах. Допустимо указывать время в секундах (1), минутах (60), часах (3600), сутках (86400), неделях (604800), месяцах (2392000) и годах (31536000). В скобках указано число, на которое надо умножить заданное значение времени, n, чтобы перевести его в секунды.

Синтаксис файла сервера PXED для базы данных db_file

Примечания:

• Используемые в таблицы единицы времени (единицы_времени) не обязательны и применяются в качестве модификаторов значений времени. По умолчанию время указывается в минутах. Допустимо указывать время в секундах (1), минутах (60), часах (3600), сутках (86400), неделях (604800), месяцах (2392000) и годах (31536000). В скобках указано число, на которое надо умножить заданное значение времени, n, чтобы перевести его в секунды.
• Элементы, описанные в одном контейнере, могут быть переопределены во вложенном контейнере. Например, можно определить клиентов BOOTP на глобальном уровне, но разрешить их работу только в конкретной подсети, указав ключевое слово supportBootp в обоих контейнерах.
• В контейнерах client, class и vendor поддерживаются регулярные выражения. Если в контейнере class или vendor указана заключенная в кавычки строка, в которой после открывающей кавычки стоит символ !, то остаток строки будет обрабатываться как регулярное выражение. В контейнере client регулярные выражения можно указывать в полях hwtype и hwaddr. В обоих полях можно задавать строку следующего формата:

  десятичное_число-данные
  

  Если десятичное_число равно нулю, то данные представляют строку ASCII. Если указано любое другое число, то данные представляют собой набор шестнадцатеричных цифр.

Более подробная информация о других опциях приведена в разделе Известные опции файла сервера DHCP.