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

Демон BINLD

Сервер демона согласования загрузочных образов (BINLD) применяется на третьем этапе загрузки клиентов PXE. Сначала клиент обращается к серверу DHCP за IP-адресом, затем получает от proxy-сервера PXE DHCP информацию о расположении сервера загрузки, а с сервера загрузки - имя и каталог загрузочного файла. Если для загрузки клиента необходимо несколько файлов, то клиент PXE может обращаться к серверу несколько раз.

На последнем этапе клиент PXE получает загрузочный образ с сервера загрузки. Расположение сервера TFTP и имя загружаемого файла клиент PXE получает с сервера загрузки.

Сервер BINLD

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

База данных BINLD

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

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

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

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

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

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

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

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

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

Настройка BINLD

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

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

pxeservertype       binld_on_dhcp_server
 
subnet default
{
    vendor pxe
    {
                bootstrapserver  9.3.149.6      #IP-адрес сервера TFTP
                pxebootfile   1   2   1   window.one   1   0
                pxebootfile   2   2   1   linux.one    2   3
                pxebootfile   1   2   1   hello.one    3   4
                client 6 10005a8ad14d any
                {
                   pxebootfile   1   2   1   aix.one     5   6
                   pxebootfile   2   2   1   window.one  6   7
        }
     }
}

В предыдущем примере сервер BINLD ожидает от клиента прямые пакеты и пакеты рассылки на порту 4011, если BINLD получил адрес рассылки из dhcpsd/pxed. В ответ на пакеты REQUEST/INFORM, принятые от клиента, сервер BINLD возвращает имя загрузочного файла и IP-адрес сервера TFTP. Если BINLD не находит загрузочный файл на уровне, указанном клиентом, он пытается найти его на следующем уровне. Сервер BINLD не отвечает ничего, если он не смог найти файл, удовлетворяющий запросу клиента (Type, SystemArch, MajorVers, MinorVers, and Layer).

В следующем примере сервер BINLD работает на другом компьютере, чем DHCP.

subnet 9.3.149.0 255.255.255.0
{
 
     vendor pxe
     {
 
     bootstrapserver        9.3.149.6      # IP-адрес сервера TFTP
     pxebootfile    1    2    1   window.one    1   0
     pxebootfile    2    2    1   linux.one     2   3
     pxebootfile    1    2    1   hello.one     3   4
     client 6 10005a8ad14d any
       {
       pxebootfile    1    2    1   aix.one      5   6
       pxebootfile    2    2    1   window.one   6   7
       }
     }
}

В следующем примере pxeservertype не задан, поэтому тип сервера по умолчанию - это binld_only. Сервер BINLD ожидает от клиента прямые пакеты и пакеты рассылки на порту 4011, прямые пакеты и пакеты оповещения на порту 67, если BINLD получил адрес рассылки из dhcpsd/pxed. Имя загрузочного файла и IP-адрес сервера TFTP отправляются клиенту PXE только в том случае, если IP-адрес клиента принадлежит диапазону адресов подсети (9.3.149.0 - 9.3.149.255).

В следующем примере сервер BINLD будет работать в той же системе, что и сервер PXED:

pxeservertype       binld_on_proxy_server
subnet default
{
     vendor
     {
     bootstrapserver        9.3.149.6          # IP-адрес сервера TFTP
     pxebootfile    1    2    1   window.one    1    0
     pxebootfile    2    2    1   linux.one     2    3
     pxebootfile    1    2    1   hello.one     3    4
     client 6 10005a8ad14d any
       {
       pxebootfile    1    2    1   aix.one     5   6
       pxebootfile    2    2    1   window.one  6   7
       }
     }
}

В предыдущем примере сервер BINLD ожидает от клиента только пакеты рассылки на порту 4011, если BINLD получил адрес рассылки из dhcpsd/pxed. Если сервер BINLD не получает пакеты рассылки, то он завершает работу и заносит в файл протокола сообщение об ошибке.

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

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

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

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

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

Контейнеры

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

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

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

• Для определения подсети, в которой находится клиент, контейнер subnet использует поле giaddr или адрес принимающего интерфейса.
• Контейнер class использует значение опции 77 (идентификатор класса пользователя).
• Контейнер vendor использует значение опции 60 (идентификатор класса вендора).
• Контейнер client использует значение опции 61 (идентификатор клиента) для клиентов PXED и поле 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.

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

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

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

Примечания:

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

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

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

Сведения о других опциях приведены в разделах Известные опции файла сервера и Опции контейнера PXE.