Обзор сетевых возможностей

Имеется простой способ быстрого определения номера нужного подустройства. /dev/rmtX.N N=A+B+C где, A - ёмкость (А=4, если ёмкость высокая и А=0, если ёмкость ленты низкая); В - удержание (В=2, если удержание необходимо и В=0 в противном случае); С - перематывание (С=1, если нужно перематывание и С=0, если не нужно).

Меню архивирования

Архивирование удобно выполнять с помощью SMIT:

System Storage Management (Physical & Logical)

 
Move cursor to desired item and press Enter.

  Logical Volume Manager
  File Systems
  Files & Directories
  System Backup Manager



F1=Help      F2=Refresh        F3=Cancel         F8=Image
F9=Shell     F10=Exit          Enter=Do

Процесс архивирования rootvg - mksysb

Для работы с системным архивированием необходимо установить bos.sysmgt.br. Этот процесс архивирует только группу томов rootvg. Причём:

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

Файл /image.data

При создании группы томов rootvg процесс установки базовой операционной системы использует файл /image.data.

Обычно, информация в станзах этого файла генерируется командами lsxx; например, lsvg для группы томов, lslv для логического тома, lsjfs для файловой системы.

Администратор при необходимости может описать дополнительные действия после установки базовой операционной системы используя поле BOSINST_FILE= в станзе post_install_data.

Описание важнейших станз

LOGICAL_VOLUME_POLICY Содержит информацию используемую при восстановлении.

Если поле SHRINK= установлено в YES то логические тома и файловые системы "обрезаются" (создаются размером установленным в полях LV_MIN_LPs и FS_MIN_SIZE) при восстановлении.

Поле EXACT_FIT= указывает на то, использовать или не использовать карту физических разделов для размещения логических томов.

Поле VG_SOURCE_DISK_LIST= указывает на диски, которые установка базовой операционной системы должна использовать для оптимального размещения.

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

Файл /bosinst.data

Файл /bosinst.data содержит требования необходимые для целевой системы, а также определяет то, как пользователь взаимодействует с ней.

control_flow:
CONSOLE=
INSTALL_METHOD=overwrite
PROMPT=yes
EXITING_SYSTEM_OVERWRITE=no
INSTALL_X_IF_ADAPTER=yes
RUN_STARTUP=yes
RM_INST_ROOTFS=no
ERROR_EXIT=
CUSTOMIZATION_FILE=
TCB=no
INSTALL_TYPE=
BUNDLES=

Наличие этого файла позволяет использовать один и тот же архивный образ для различных аппаратно целевых систем. Утилита системного архивирования просто копирует файл /bosinst.data как первый файл в образе rootvg. Если этого файла нет в директории root, то в файл /bosinst.data образа копируется содержимое файла /usr/lpp/bosinst/bosinst.template.

CONSOLE - определяет устройство (полный путь), которое вы хотите использовать как консоль.

INSTALL_METHOD - определяет метод установки (migration, preserve или overwrite)

PROMPT - определяет, используется ли меню выбора действий для пользователя при установке или нет. Если значение этой переменной установлено в no, то администратор обязан заполнить все значения в станзах locale и control_flow (исключение: значения для параметров ERROR_EXIT и CUSTOMIZATION_FILE не обязательны).

EXITING_SYSTEM_OVERWRITE - подтверждение того, что программа установки должна (или не должна) перезаписывать существующие файлы. Эта переменная используется в том случае, если определена установка без сообщений (переменная PROMPT установлена в no).

INSTALL_X_IF_ADAPTER - запрос насчет того, если в целевой системе существует графический адаптер, устанавливать ли AIXWindows или нет.

RUN_STARTUP - запускать ли Installation Assistant после первой загрузки после уста-новки BOS.

RM_INST_ROOTFS - удаляет все файлы и директории в директориях /usr/lpp/*/Inst_roots.

ERROR_EXIT - запускает определенную администратором исполняемую программу, если в программе установки обнаружена ошибка.

CUSTOMIZATION_FILE - определяет имя и полный путь к файлу настроек, который исполняется сразу после завершения программы установки.

TCB - определяет потребность в установке Защищенной вычислительной основы

INSTALL_TYPE - определяет какое программное обеспечение устанавливать на систему. Параметр может принимать следующие значения: full (полно-функциональная конфигурация), client (клиентская конфигурация) и personal (конфигурация персо-нальной рабочей станции).

BUNDLES - определяет какие пакеты программного обеспечения устанавливать. Имена пакетов разделяются пробелами.

Станза target_disk_data содержит значения определяющие параметры дисков системы, на которую программа должна установить BOS.

LOCATION - определяются коды размещения диска на которой должна будет установлена BOS.

SIZE_MB - определяет форматированный размер диска (в мегабайтах) где программа должна установить BOS.

HDISKNAME - определяет имя и путь целевого диска.

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

CULTURAL_CONVENTION - определяет культурные соглашения для установки.

MESSAGES - определяются директории сообщений.

KEYBOARD - определяется раскладка клавиатуры.

Восстановление информации

Восстановление информации является довольно легким занятием, если вы используете SMIT.

Немного подробнее хотелось бы описать процесс восстановления системы из системного образа. Для восстановления информации из системного архива необходимо загрузить систему в режим Installation/Maintenance (Установка/Обслуживание), выбрать пункт меню "Maintenance", а в нем выбрать пункт "Install from a System backup" и определить устройство на котором расположен образ системы.

Команды архивирования UNIX

Администратор может также воспользоваться известными и применяемыми в мире UNIX командами архивирования tar, cpio и dd.

Стратегия работы с архивами

1. Удостоверьтесь, что вы можете восстановить информацию быстро, просто и качественно.

2. Периодически проверяйте ваши архивы (tapechk).

4. Проверьте файловые системы после архивирования (fsck).

5. Удостоверьтесь, что файлы не находятся в использовании во время архивирования (fuser).

7. Постарайтесь иметь бумажный список всех файлов, находящихся на ленте.

8. При команде создания ленты давайте ей метку.

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

Обзор сетевых возможностей

Подробное рассмотрение способов построения, расширения и сопровождения сетей, а также функционирования высокоуровневого сетевого программного обеспечения, такого как доменная система имен DNS, сетевая файловая система NFS, методы маршрутизации, система электронной почты sendmail и пр., требует многих томов. Поэтому в этой книге даётся только краткий обзор сетевых возможностей AIX.

Обзор TCP/IP

TCP/IP - это сетевая архитектура, которая определяет механизм для совместной работы различных компьютеров подсоединенных к различным сетям для обмена данными. Программное обеспечение TCP/IP позволяет обмениваться данными между различными компьютерными платформами от мейнфреймов до персональных компьютеров и, в большей степени, ассоциируется с миром UNIX/AIX.

Можно определить TCP/IP как набор протоколов, которые определяют то, каким образом компьютеры в сети могут обмениваться между собой информацией.

Протокол - это набор правил, которые определяют механизм и структуру передаваемых данных. Используя эти определения, производители могут написать программное обеспечение для различных аппаратных платформ.

Аббревиатура TCP/IP означает "Transmission Control Protocol/Internet Protocol". Это имена двух важнейших протоколов. В сетевой архитектуре TCP/IP имеются много других протоколов. Эти протоколы не привязаны ни к какой операционной системе и аппаратной платформе. И в силу такой независимости, для того чтобы сетевая аппаратура могла их использовать, только программный интерфейс должен быть построен в соответствии с этими протоколами.

Протоколы TCP/IP работают с различными типами сетей - от низкоскоростных соединений последовательного типа до быстрых локальных компьютерных сетей (LAN) типа Token-Ring или Ethernet и еще более быстрых сетей на основе оптического кабеля, таких как FDDI и HYPERchannel.

Сеть на основе TCP/IP называют internet (не путать с названием глобальной сети сетей The Internet, название которой пишется с заглавной буквы и которая тоже построена на основе протоколов TCP/IP).

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

Сетевой интерфейс, который подключен к internet со своим адресом TCP/IP, называется узел (host).

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

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

Имена и адресация

Каждый сетевой интерфейс в сети TCP/IP имеет имя, присваиваемое сервером имён (DNS) или определенное в файле /etc/hosts (см.Настройка клиентской части). Например, sys3.

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

Формат IP адреса IP-адрес является 32-х разрядным бинарным (состоящим из 1 и 0) числом, которое содержит в себе адрес и сети и узла.

Чтобы облегчить работу с IP-адресами их, обычно, разделяют на четыре группы по восемь цифр (четыре октета):

и каждый октет преобразуют в десятичный вид.

Десятичная запись с точечными разделителями вышеуказанного IP-адреса:

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

· поля идентификатора сети (netid), являющегося логическим сетевым адресом подсети, к которой подключён данный сетевой интерфейс;
· поля идентификатора узла (hostid), являющегося логическим адресом сетевого интерфейса в данной сети.

Вместе, netid и hostid уникальным образом предоставляют сетевому интерфейсу уникальный IP-адрес.

IP-адреса организованы в классы значением первого октета:

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

Специальные IP-адреса

Существуют IP-адреса, применяемые для специальных целей:

Маска подсети

Для упрощения и ускорения определения той части IP-адреса, которая является netid, а также для выделения подсетей в диапазоне адресов стандартных классов применяют маски подсети (subnet mask).

Маска подсети - это бинарное число, которое определяет, какая часть IP-адреса является netid, а какая hostid. Использование маски подсети имеет особенно важное значение, если ваша сеть подключена к Internet. Если ваша сеть объединяет несколько удаленных филиалов вашу сеть также необходимо разбить на подсети с организацией маршрутизации между ними, чтобы уменьшить трафик по межфилиальным коммуникациям, которые, обычно, не такие скоростные, как локальная сеть.

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

Цифра 0 в маске подсети означает, что соответствующий разряд в IP-адресе является hostid. Например, чтобы разбить сеть класса С на четыре подсети необходимо применить маску подсети

Маска подсети показывает, что hostid могут находиться в диапазоне 000001 до 111110 (от 1 до 62) и первые два разряда четвертого октета могут иметь значения от 00 до 11. Следовательно, наша сеть класса С 194.93.173 (254 адреса), с помощью маски подсети разбита на четыре подсети с 62-мя адресами (248 адресов + 4 адреса пошло на netid + 2 специальных адреса).

Маршрутизация

Когда узел обнаруживает, что необходимо послать пакет в другую подсеть, он посылает его по адресу, который указывается при конфигурировании, как стандартный шлюз (default gateway) или по адресу другого доступного маршрутизатора, если стандартный шлюз недоступен. Шлюз - это старый термин для маршрутизатора (router).

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

При маршрутизации IP-адреса отправителя и получателя не изменяются. Изменяются только соответствующие аппаратные адреса.

Некоторые возможности сети TCP/IP

Стандартные возможности сети TCP/IP включают в себя:

· Mail (электронная почта)
· File Transfer (средства передачи файлов)
· Remote Login (удаленное подключение)
· Remote Execution (удаленное исполнение приложений)
· Remote Printing (печать на удаленных принтерах).

Различные приложения AIX используют протоколы TCP/IP, например такие как:

· Network File System (NFS)
· Network Information Services (NIS)
· Network Computing System (NCS)
· Distributed Computing Environment (DCE)
· Xwindow и AIXwindows
· Xstation Manager
· AIX Netwiev/6000

Конфигурирование TCP/IP

Для конфигурирования TCP/IP требуется следующая информация:

Каждый сетевой интерфейс должен иметь уникальный адрес (TCP/IP address), имя узла (hostname) и почти всегда маску подсети (subnet mask).

Каждый компьютер должен иметь доступ к таблице имен для трансляции имен в адреса. Она находится либо в файле /etc/hosts, либо в Domain Name Server (DNS).

Для использования DNS вы должны знать имя домена (Domain Name) и адрес сервера имен (Address of the Name Server).

Для обмена данными с другими сетями вы должны знать адрес стандартного шлюза (address of the default gateway).

Обзор доменной службы имен DNS

Как работает DNS

В сетях TCP/IP компьютеры для общения между собой используют IP-адреса. Однако то, что удобно машинам, неудобно людям. Есть спорное мнение, что сама человеческая натура протестует против запоминания чисел типа 192.168.1.34 (что не мешает нам запоминать телефонные номера с кодом города и страны, типа 380-564-40-06-24). К тому же IP-адреса совсем не информативны. По IP-адресу невозможно понять, что это: сервер, ПК, маршрутизатор или сетевой принтер. Приятней работать с осмысленными именами, такими как account-server.

Тем не менее сетевые устройства обращаются друг к другу, используя IP-адрес, а не имена.

Решает эту проблему система именования сетевых объектов, которая отвечает за преобразование символьных имен в IP-адреса. Система именования выполняет функции телефонной книги, в которой каждому номеру телефона поставлена в соответствие запись о фамилии или названии фирмы. Системе передается имя (например archie.univie.ac.at), а она возвращает IP-адрес (140.78.3.8).

Системы именования сетевых объектов делятся на "плоские" и иерархические (доменные).

В "стародавние времена", когда Internet еще называлась ARPANET и Сеть состояла лишь из многотерминальных компьютеров типа мэйнфреймов (при этом их количество оставалось относительно невелико), была реализована система именования для одноуровневого (плоского) пространства имен. Ее также называют "плоской" системой именования. Каждый компьютер имел файл (обычно /etc/hosts) со списком IP-адресов хостов и их символьные имена. При появлении в Internet нового компьютера информация о нем заносилась в файл hosts, затем этот файл рассылался на все другие машины.

Недостатки такой схемы начали проявляться довольно быстро: с переходом от больших машин к персональным и с ростом Internet. Трафик, связанный с обновлением информации при добавлении компьютеров в Internet, грозил забить все линии связи. Кроме того, каждое имя в сети должно быть уникальным, а сделать это становится все труднее и труднее. Поэтому к середине 80-х годов появилась другая, более гибкая система именования - система имен доменов (Domain Name System, DNS).

DNS реализует иерархическое пространство имен. Единицей измерения является домен (территория, область). Понятие домена DNS не надо путать с доменом Windows NT или доменом NIS. Они не имеют друг к другу никакого отношения.

В DNS вся сеть представляется в виде единого иерархического дерева. На вершине располагается корневой домен (обозначается символом "."). Ниже находятся домены первого уровня. Поскольку Internet развивался в первую очередь в США и за счет американских налогоплательщиков, это вызвало некоторый крен при формировании доменов первого уровня: Internet как бы оказался поделенным между США и всем остальным миром.

Наиболее известные домены первого уровня: com - коммерческие организации (главным образом в США); edu - учебные заведения США; gov - правительственные учреждения США; mil - военные учреждения США; net - различные сетевые агентства и Internet-провайдеры; int - международные организации; org - некоммерческие учреждения; код страны - двухбуквенный код для обозначения государства (ru - для России, ua - для Украины и т.п.). Ниже доменов первого уровня располагаются домены второго уровня и так далее вплоть до хостов. Для доменов первого уровня, обозначающих государства, доменами второго уровня часто бывают города или области (например, kiev - для Киева или dp -Днепропетровская область), а доменами третьего уровня - предприятия и организации.

Любой хост или домен в Internet однозначно идентифицируется так называемым полным доменным именем (Fully Qualified Domain Name, FQDN). Его иногда еще называют абсолютным доменным адресом. Домены в FQDN записываются справа налево в порядке подчинения и разделяются точками. Каждая отдельная составляющая FQDN называется меткой (label). Длина метки не должна превышать 63 символа, а полная длина FQDN - 255 символов.

Допустимыми символами являются буквы английского языка, цифры и знак дефиса "-" (знак дефиса не может стоять в начале или конце метки). Регистр букв значения не имеет, т. е. company1.krcrme.dp.ua. и COMPANY1.KRCRME.DP.UA. обозначают один и тот же домен.

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

Кроме абсолютной применяется и относительная доменная адресация. Когда два устройства находятся в одном и том же домене, они могут обращаться друг к другу по имени, не указывая полного доменного пути. Так, host2 обращается к host1 двумя способами: по полному доменному имени host1.company1.krcrme.dp.ua. по относительному доменному адресу host1

В полном доменном имени конечную точку можно не ставить, поскольку обычно программное обеспечение TCP/IP подразумевает, что составное доменное имя (т.е. когда присутствует более двух меток) обозначает FQDN. Таким образом, company1.krcrme.dp.ua. и company1.krcrme.dp.ua суть одно и то же.

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

Как уже отмечалось, основное назначение DNS состоит в преобразовании имени хоста в его IP-адрес. На самом деле DNS является системой, не зависимой от протокола сетевого уровня, т. е. она может быть реализована не только в среде TCP/IP.

Однако функции DNS этим не ограничиваются. DNS позволяет получить следующую информацию:

Существует и ряд других, реже используемых параметров.

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

Программное обеспечение, которое общается с серверами имен, называют клиентом DNS (Resolver DNS). Клиент DNS выполняет роль посредника между сетевыми приложениями и серверами имен. При этом он, как правило, скрыт от пользовательских программ. Сетевые приложения используют клиент DNS чаще всего неявно, через функции стека TCP/IP. Однако приложение nslookup позволяет получить любую информацию из базы DNS. Клиент DNS входит в состав программного обеспечения TCP/IP. Но стек TCP/IP, по-мимо DNS, поддерживает и "плоскую" систему именования (через файл hosts). Это позволяет обеспечить работоспособность сетевых устройств при проблемах с DNS (например при отсутствии связи с сервером имен). Клиент DNS может функционировать как на отдельном компьютере, так и на сервере имен.

Сервер имен на самом деле отвечает не за домен, а за так называемую зону управления (Zone of Authority), в которую могут входить несколько смежных доменов. Более того, сервер имен способен управлять несколькими, причем не обязательно смежными, зонами одновременно.

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

Время, в течение которого информация хранится в кэше, определяется источником информации и обычно составляет от десятков минут до нескольких суток.

Кэширование позволяет уменьшить трафик в сети, а также снизить нагрузку на серверы имен.

Серверы имен бывают нескольких типов. Первичный сервер имен (Primary Name Server) хранит на своих дисках главные файлы (master files), в которых содержится вся информация о зонах управления данного сервера. Эти файлы загружаются в память сервера имен при его запуске.

Вторичный сервер имен (Secondary Name Server) используется как дубликат первичного сервера, что обеспечивает отказоустойчивость DNS. Он загружает информацию с первичного сервера и затем периодически ее обновляет, посылая первичному серверу запросы.

Серверы "только для кэширования" (Cache-Only Server) записывают в кэш информацию, полученную от других серверов имен. Чаще всего они используются в больших сетях для разгрузки первичного сервера.

Это, однако, еще не все типы серверов имен, но оставшиеся (серверы Forwarder и Slave Forwarder) имеют лишь незначительные отличия в обработке информации DNS.

По правилам Internet, для повышения отказоустойчивости DNS зоной должны управлять как минимум два сервера имен. Обычно для этого устанавливают один первичный и один-два вторичных сервера. При добавлении компьютера в сеть или изменении его IP-адреса, файлы (master files) редактируются только на первичном сервере имен.

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

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

Таким путем удалось резко снизить в Internet трафик, связанный с преобразованием имен в IP-адреса.

Серверы имен могут работать в двух режимах: нерекурсивном и рекурсивном.

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

Таким образом, в нерекурсивном режиме клиент сам осуществляет все запросы к серверам имен.

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

Чтобы работать в рекурсивном режиме, сервер и клиент должны быть настроены соответствующим образом. Однако в большинстве случаев пользователь не имеет возможности менять настройку режима работы клиента, поскольку она "зашита" в программное обеспечение TCP/IP.

Рекурсивный режим применяется реже нерекурсивного, так как нагрузка на серверы имен в этом случае значительно возрастает. Да и для клиента такой режим не оптимален, ибо в случае задержки ответа ему трудно определить, что произошло: сбой на линии или просто опрашивается очень длинная цепочка серверов имен.

Сервисы DNS в AIX

Все сервисы доменного именования полностью реализованы в AIX. Поддерживаются следующие типы серверов имен:

1. Первичный сервер имен;
2. Вторичный сервер имен;
3. Сервер "только для кэширования";
4. Сервер Forwarder;
5. Удаленный сервер.

Клиент DNS в AIX, gethostbyaddr() и gethostbyname(), пытается определить имена ис-пользуя следующую процедуру:

Если файл /etc/resolv.conf не существует, клиент DNS считает, что в сети используется плоская система именования. Тогда он использует для определения имен файл /etc/hosts.

В обратном случае, клиент DNS считает локальную сеть доменной сетью и пытается использовать для определения имени нижеследующие источники в показанном ниже порядке:

Функции сервера имен в AIX выполняет демон named. Он контролируется посредством AIX SRC (system resource control). Этот демон может стартовать автоматически при каждом перезапуске системы используя команду smit stnamed или если будет отредактирован файл rc.tcpip убрав комментарий в сроке #start /etc/named "$src_running" Демон named стартует также при команде startsrc -s named.

Хост AIX конфигурируется для использования сервера имен используя следующие шаги:

1. Создайте файл /etc/resolv.conf включив в него имя домена и адреса до 16-ти серверов имен. Например:

Порядок записей серверов имен имеет значение для определения порядка вызова серверов: сначала самый первый сервер имен из списка, далее второй и т. д.

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

Если указанный первым в списке серверов имен не работает, то пройдет заметный промежуток времени (до нескольких секунд), прежде чем клиент DNS обратится ко второму серверу.

2. Создайте файл /etc/named.boot для определения имени и типа локального демона named.

3. Создайте файлы /etc/named.* для определения требуемых для демона данных. Формат этих файлов должен соответствовать формата записей стандартных ресурсов (Standard Resource Record Format).

Демон named в AIX также поддерживает записи ресурсов для почты типа MB (mailbox domain name), MR (mail rename domain name), MG (mail group member), MINFO (mailbox or mail list information) и MX (mail exchange).

Приложения пользователя AIX/6000 включает в себя программы host и nslookup. В AIX/6000 также можно воспользоваться программой dig для запросов к серверам имен.

Настройка клиентской части

Как уже было отмечено, программное обеспечение TCP/IP одновременно поддерживает и клиента DNS, и файл hosts. Содержимое файла /etc/resolv.conf мы рассмотрели уже выше. Файл hosts отвечает за "плоскую" систему именования. Местонахождение этого файла зависит от операционной системы (AIX - /etc/hosts, DOS и Windows - ETC\HOSTS, NetWare - SYS:\ETC\HOSTS).

Формат его очень прост: он состоит из строк, каждая из которых определяет один хост: <IP-адрес> <имя> [<псевдоним> ... <псевдоним>]

Обратите внимание, что файл hosts может содержать имена в доменном формате.

Настройка сервера имен

Среди администраторов сетей бытует мнение, что DNS следует использовать только при наличии подключения к Internet. Но DNS позволяет упростить администрирование локальных сетей TCP/IP независимо от того, имеют они выход в Internet или нет. При отсутствии DNS добавление компьютера в локальную сеть приводит к тому, что в файл hosts каждого хоста необходимо ввести информацию о новом компьютере. Это нетрудно, если машин в сети немного. А если их десятки или сотни? При использовании DNS вся процедура сводится к добавлению одной-двух строк в файлы базы DNS на первичном сервере имен. После этого хосты сети будут распознавать новый компьютер по имени автоматически. Если по каким-либо причинам необходимо изменить IP-адрес или имя хоста, то с DNS сделать это довольно просто. Кроме того, использование DNS значительно облегчает процедуру подключения корпоративной сети к Internet.

Стандарты DNS

Настройка базы DNS задается в специальных текстовых файлах на серверах имен. Форматы записей в этих файлах регламентируются стандартами, изложенными в документах RFC (Request For Comments). Они разрабатываются "законодательным" органом Internet - IETF (Internet Engineering Task Force). Однако сам набор файлов и порядок их загрузки на серверах имен RFC не регламентируется. Для этого существует стандарт de facto под названием BIND (Berkley Internet Name Domain). Данная спецификация была разработана в университете Беркли и впервые реализована в BSD Unix. Подавляющее большинство серверов имен поддерживают спецификацию BIND.

Многие версии программного обеспечения серверов имен имеют административные утилиты, упрощающие настройку и управление базами DNS. Тем не менее администраторы сетей, как правило, предпочитают не пользоваться ими, а работать напрямую с файлами базы DNS. Хотя это несколько усложняет администрирование, но в то же время дает максимальную гибкость и полный контроль при управлении DNS.

Подустройство	Низкая ёмкость	Перематывание(удержание)на начало при открытии	Перематывание на начало при закрытии операции
/dev/rmtX	нет	нет	да
/dev/rmtX.1	нет	нет	нет
/dev/rmtX.2	нет	да	да
/dev/rmtX.3	нет	да	нет
/dev/rmtX.4	да	нет	да
/dev/rmtX.5	да	нет	нет
/dev/rmtX.6	да	да	да
/dev/rmtX.7	да	да	нет