оступным. Процесс можно описать следующим образом:

1. Клиент вводит сеть IP в состоянии инициализации и передает по широковещательное сообщение по всем доступным сетям с запросом на получение IP адреса и описанием требований к соединению (DHCPDISCOVER).

2. Агент ретрансляции BOOTP обнаруживает это сообщение и передает его всем доступным серверам DHCP для обработки.

3. Каждый сервер DHCP отвечает на запрос клиента с сообщением предложения (DHCPOFFER), которое состоит из доступного адреса IP и информации конфигурации на основе предопределенных администратором требований к соединению для этого узла.

4. Клиент получает все ответы от серверов и определяет наилучшее предложение используя встроенный алгоритм.

5. Затем клиент отправляет выбранному серверу запрос на получение адреса и информации конфигурации (DHCPREQUEST).

6. В заключение, выбранный сервер DHCP посылает в сеть сообщение о подтверждении получения обслуживания (DHCPACK). После этого все другие сервера, которые не были выбраны, освобождают адреса IP, которые они предложили клиенту и возвращаются в режим опроса сети, ожидая следующий пакет DHCPDISCOVER.

7. После того, как сервер DHCP получает подтверждение от клиента DHCP, сервер автоматически модифицирует сервер имен DNS в соответствии с этим адресом IP.

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

9. Когда время таймера истекает, клиент посылает DHCPREQUEST пакет серверу, запрашивая обновление "арендного договора".

10. Если клиент не получает никакого ответа от сервера, то он ждет до истечения трех четвертей продолжительности "арендного договора" и затем передает DHCPREQUEST пакет ко всей сети, чтобы запросить обслуживание у нового сервера. Этот процесс гарантирует, что сервис DHCP продолжается без прерывания.

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

DHCP - протокол прикладного уровня основанный на BOOTP, который выполняется при помощи протокола UDP. Если размер сети требует обслуживания DHCP во многих связанных сетях межсетевой маршрутизатор должен поддерживать возможность передачи сообщений агента ретрансляции BOOTP. Как указано выше, этот агент ретран-ляции ответственен за передачу сообщения BOOTP между двумя IP сетями. Прохождение такого сообщения требуется в случае, если DHCP клиент и сервер находятся в разных сетях.

Сервис DHCP в крупных, связанных между собой, сетях (с общим числом узлов более 5000) может вызывать массивные штормы широковещательных сообщений. В этом случае рекомендуется установить большее количество DHCP серверов в разных сетях.

DHCP в AIX V4

Реализация клиента и сервера DHCP в AIX состоит из следующих модулей:

· Демон клиента dhcpcd
· Демон сервера dhcpsd
· Демон агента ретрансляции dhcprd

Текущая реализация DHCP для RS/6000 поддерживает такие LAN-основанные протоколы, как Ethernet, Token-Ring и FDDI. Эта реализация как клиента, так и сервера DHCP соответствует всем доступным RFC и также была проверена на совместимость с другими клиентами и серверами DHCP.

Таблица ниже показывает перечень продуктов, способных работать с реализацией DHCP для AIX.

Сервер DHCP Клиенты DHCP
AIX V4.2 MacOS, Windows 3.x, Windows 95,Windows NT 3.5, Chameleon,FTP Software, AIX V4.1.4
AIX V4.1.4 OS/2 Warp Connect
OS/2 Warp Server, SUN Solaris,FTP Software, Competitive Automation AIX V4.2, AIX V4.1.4

Каждая машина RS/6000 может выполнять одну из трех ролей: роль сервера, роль клиента или роль агента передачи сообщений BOOTP.

Конфигурирование сервера DHCP

Сервер DHCP генерирует и предлагает адреса IP, основанные на наборе предопределенных атрибутов или сред. Пользователи могут создавать эти области определения, редактируя ASCII файл или используя графический интерфейс пользователя (GUI).

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

Внутри сервера DHCP, представление информации клиента используя ключи. С этими ключами сервер DHCP может назначать IP адреса клиенту.

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

Второй ключ - идентификатор клиента. Идентификатором клиента может быть имя узла TCP/IP или MAC адрес. Сервер может использовать идентификатор клиента, чтобы обеспечить более специфические возможности.

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

Таким образом, иерархия для назначения возможностей ресурса клиента выглядит следующим образом:

· специфический клиент;
· класс;
· сеть;
· глобальная переменная.

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

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

Сценарий конфигурации сервера

В нижеследующем DHCP сценарии конфигурации сервера фирма "Х" имеет шесть IP сетей и имеет назначенные Центром Информации Сети Internet (InterNIC) сети диапазон адресов IP один класса C и один класса B.

Общие пользователи фирмы "Х" сгруппированы как или динамические или статические.

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

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

Сеть класса B разбита на под сети класса C для пяти рабочих групп. Имеется только четыре сети класса C, потому что рабочие группы бухгалтерии и вычислительного центра совместно используют одну сеть класса C.

Ниже показывается, как сконфигурирована сеть класса C для отдела маркетинга.

Состояние network имеет два параметра: первый параметр - сетевой адрес, и второй параметр определяет диапазон разрешенных адресов, которые могут быть назначены.

Диапазон - от 2 до 240, потому что 1 используется маршрутизатором "Х" и не должен быть назначен, и адреса выше 240 зарезервированы для будущих статических пользователей.

(Если второй параметр не определен, это подразумевает, что можно присвоить все адреса.)

network  192.100.10.0 192.100.10.2-192.100.10. 240
{
option 1 255.255.255.0 * Маска подсети для класса C
option 3 193.100.10.1 * Заданный адрес gateway/маршрутизатора по умолчанию
option 6 129.35.40.5 * Заданный по умолчанию адрес сервера DNS
option 5 2 hours  * Время «арендного договора», установлено 2 часа,
                  * потому что коммерческие агенты обычно
                  * находятся в офисе в течение только одного часа.
option 15 "marketing.x.com"  * Заданное по умолчанию имя домена
}

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

network 129.35.0.0 24 * назначенный NIC адрес сети класса B 129.35.0.0
                      * используется маска подсети с 24 битами
 {
 option 1 255.255.255.0 * Маска подсети для класса B
 subnet 129.35.10.0 * Адрес подсети
  { * Можно присваивать все адреса подсети
  client 0 0 129.35.10.1 * Адрес 129.35.10.1
                         * зарезервирован для маршрутизатора
  option 3 129.35.10.1 * Заданный адрес gateway/маршрутизатора по умолчанию
  option 6 129.35.40.5 * Заданный по умолчанию адрес сервера DNS
  option 15 "producttest.x.com" * Заданное по умолчанию имя домена
  }

subnet 129.35.20.0 129.35.20.2-129.35.20.200
 { * Определенный диапазон адресов для подсети
 option 3 129.35.20.1 * Заданный адрес gateway/маршрутизатора по умолчанию
 option 6 129.35.40.5 * Заданный по умолчанию адрес сервера DNS
 option 15 "manufacturing.x.com" * Заданное по умолчанию имя домена
 }

subnet  129.35.30.0 129.35.30.2-129.35.30.215
 { * Диапазон всех присваиваемых адресов
 option 3 129.35.30.1 * Заданный адрес gateway/маршрутизатора по умолчанию
 option 6 129.35.40.5 * Заданный по умолчанию адрес сервера DNS
 option 15 "rnd.x.com" * Заданное по умолчанию имя домена
 }
}

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

network 129.35.0.0 25 * nic-назначил класс B адресует 129.35.0.0
                      * маска подсети с 25 битами используется потому что
                      * 256 адресов разделены две подсети.
{
option 1 255.255.255.128 * Маска подсети для сети класса B
subnet 129.35.40.0 129.35.40.64-129.35.40.12 6
* Определенный диапазон адресов для подсети
 { 
 option 3 129.35.40.1 * Заданный адрес gateway/маршрутизатора по умолчанию
 option 6 129.35.40.5 * Заданный по умолчанию адрес сервера DNS
 option 15 "netserver.x.com" * Заданное по умолчанию имя домена
 }

subnet 129.35.40.128 * Адрес подсети
 { 
 option 3 129.35.40.129 * Заданный адрес gateway/маршрутизатора по умолчанию
 option 6 129.35.40.5 * Заданный по умолчанию адрес сервера DNS
 option 15 "accounting.x.com" * Заданное по умолчанию имя домена
 client 0 0 129.35.40.129 * Клиентский адрес 129.35.40.129 удален
client 10x1005ACABADAE 129.35.40.130 * IP адрес 129.35.40.130  зарезервирован
* для Ethernet адреса 0x1005ACABADAE
 }
}

Ниже показан список глобальных параметров.

supportunlistedClients  yes * Поддержка всей клиентуры без явного
                            * задания их списка в этом файле
supportBOOTP            yes * Фирма «Х» имеет Х-станции и сетевые принтеры,
                            * использующие протокол BOOTP
leasetimedefault        5 days * Время «арендного договора» для адреса IP
leaseexpireInterval     1 day * Время для сервера DHCP для восстановления 
                                  * IP адреса, потерянного из-за того, что
                                  * клиент при отключении не выходил из
                                  * сеанса связи корректно

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

Данные конфигурации сохраняются в файле /etc/dhcpsd.cnf.

Сервер может стартовать автоматически используя последовательность, размещенную в /etc/rc.tcpip или, используя SMIT.

# Smit tcpip Further Configuration - > Server Network Services - > Other Available Services - > Dhcpsd Subsystem

Графический интерфейс

Графический интерфейс сервера DHCP помогает спрятать сложность синтаксиса файла конфигурации и упрощает его конфигурацию. Для старта графического интерфейса сервера используется команда dhcpsconf.

Панель графического интерфейса состоит из трех основных рабочих областей:

Option list - список выбираемых опций, поддерживаемых сервером
Key list - значения, которые описывают клиента, включая сетевую позицию, класс и идентификатор
Main window list - резюме опций для каждого ключа

Конфигурирование DHCP клиента

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

Клиенты имеющие предпочтения, могут быть разделены на две категории:

Относительно сети TCP/IP - статические маршруты, сервер имен NetBIOS и т.п.

Относительно услуг сервера - управляющая программа локального принтера и спулера (LPR), сервер имен (DNS), сетевой сервер времени (NTP) и т.п.

Конфигурационная информация содержится в двух файлах:

dhcpcd.ini - файл конфигурации DHCP, состоящий из директив, которые могут быть определены для клиента. Содержит список привилегированных опций.

/etc/rc.net - информация для интерфейса запуска.

Клиент устанавливается используя SMIT нижеследующим образом:

smit tcpip- > Use DHCP for TCP/IP Configuration & Startup

Команды SMIT могут также использоваться, чтобы конфигурировать DHCP для TCP/IP и запускать управление демоном клиента следующим образом:

smit tcpip -> Further Configuration - > Server Network Services - > Other Available Services - > Dhcpcd Subsystem

Комбинации параметров для заявлений клиента

Заявления клиента обеспечивают опции специфические конкретно для него, например, необходимость резервирования адреса IP или удаления адреса из диапазона.

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

Строка дает возможность серверу DHCP идентифицировать клиента и обеспечить его корректное обслуживание.

Синтаксис для заявления клиента показывается ниже:

Client     < тип аппаратуры>  < адрес аппаратуры >  < IP адрес >
1=Ethernet адрес <строка> <none>
6=token-ring            <any>
1=FDDI
0= <строка> on the next field

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

Тип аппаратуры Аппаратный адрес IP адрес Результат
0 0 <IP адрес> <IP адрес> должен быть удален из диапазона
0 <строка> <IP адрес> Клиенту, который идентифицирован <строкой> должен быть присвоен <IP адрес>
<type> <address> <IP адрес> Конкретному устройству <type> с адресом <address> должен быть присвоен адрес IP <IP адрес>
<type> <address> none Не давать IP адрес для конкретной аппаратуры с конкретным адресом
0 <строка> none Не отвечать для конкретного клиента идентифицированного <строкой>
<type> <address> any Предоставить любой свободный адрес IP для конкретной аппаратуры с конкретным аппаратным адресом. Используется в комбинации с выставленным параметром supportunlistedclients=no.
0 <строка> any Предоставить любой свободный адрес IP для клиента идентифицированного <строкой>. Используется в комбинации с выставленным параметромsupportunlistedclients=no.

Агент ретрансляции BOOTP

При маршрутизации сообщений BOOTP из одной подсети в другую, маршрутизатор обычно выполняет ретрансляцию; однако, AIX поддерживает прогрессивную маршрутизацию BOOTP пересылки.

Агент ретрансляции BOOTP стартует и останавливается подобно серверу DHCP.

Конфигурация завершатся внесением строки в файл /etc/dhcprd.cnffile. Агент ретрансляции пошлёт пакет всем серверам, определенным в этом файле.

Требования к дисковому пространству для сервера DHCP

Требования к дисковому пространству для сервера зависят от числа клиентов. Требуемое дисковое использование для поддержки одного клиента - 360 байт.

К содержанию Вперед Назад

Решение проблем и настройка производительности в сети TCP/IP

К содержанию Вперед Назад

Решение проблем и настройка производительности в сети TCP/IP

Декомпозиция проблемы

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

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

Если сетевая конфигурация неизвестна, используйте команду ping -R hostname и/или команды traceroute. Опция - R команды ping допускает использование возможности записи маршрута IP. Отрицательный результат выполнения ping означает, что не работает или узел или сеть. Для того, чтобы узнать, что именно не работает, требуется воспользоваться другими средствами. Команда ping также не дает информации о состоянии узла-адресата. Команда traceroute, аналогично выводит маршрут, который пакеты IP берут на сетевом узле, но накапливает информацию немного по-другому.

Команда traceroute использует два способа прослеживая передачу информации до адресата: маленькое значение ttl (время жизни) и отказавший номер порта.

Traceroute запускает пакеты UDP с маленькими значениями ttl, чтобы обнаружить промежуточные маршрутизаторы. Команда traceroute была создана для сетевого тестирования, измерения и управления. Вы должны использовать её прежде всего для обнаружения неисправности вручную. Из-за нагрузки, которую она налагает на сеть, вы не должны использовать команду traceroute в течение нормальных операций или из автоматизированных сценариев.

При нормально работающей сети задокументируйте параметры, выдаваемые вам вышеуказанными командами. Это позволит вам сравнить с ними изменение параметров сети, возникшие при добавлении новой аппаратуры или программ.

Чтобы создания полного обзора эффективности и конфигурационной информации сети, используйте пакет PerfPMR. Чтобы получать наиболее полные данные о сети вы должны выполнить команду perfpmr 3600 в тот час, когда нагрузка на сеть является максимальной. Выходные файлы этой команды появятся в каталоге /var/perf/tmp.

Если возможно, установите, что является "нормалью" для вашей сети, контролируя трафик в течение нескольких месяцев.

Поймите проблему

Ограничивают производительность TCP/IP в AIX обычно следующие факторы:

· недостаточное относительное быстродействие аппаратных средств;
· количество циклов CPU, необходимых для выполнения данной части кода ;
· размер пакетов передаваемых данных ;
· производительность, с которой данные кэшируются в клиентской памяти, промежуточном звене и системах сервера;
· качество кода пользователей, который обращается к подсистеме локальной вычислительной сети.

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

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

Настройка эффективности работы CPU является предметом особого рассмотрения и в этой книге не приводится.

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

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

Выбор "правильного" инструмента

Для контроля и настройки современных гетерогенных сетей администраторы должны иметь соответствующие инструментальные средства.

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

Для физического уровня: тестер (TDR)

Для сетей Ethernet, вероятно, наиболее полезный инструмент - тестер (TDR). TDR присоединяется к сети вместо одного из терминаторов. Затем тестер испускает сигнал известной мощности и формата и измеряет ответ. Каждый тип сетевой неисправности дает специфический тип ответа на TDR. Вы должны ознакомиться с документацией на тестер, чтобы интерпретировать эти ответы. Вы должны правильно установить параметры TDR для разных типов кабелей.

Для канального уровня: команда ifconfig

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

Для сетевого уровня: команда tokstat

Команда tokstat отображает статистику, определенного драйвера устройства Token-Ring.

Для сетевого уровня: команда ping

Команда Packet InterNet Groper (ping) посылает дейтаграмму ECHO_REQUEST протокола ICMP (не требует наличия серверных процессов на зондируемом узле) на конкретный узел, чтобы определить является ли этот узел доступным. Часть ответа, которую вы получаете от ping - это время передачи дейтаграммы туда и обратно.

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

Для сетевого уровня: команда traceroute

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

Для сетевого уровня: команда iptrace

Вы должны использовать команду iptrace всякий раз, когда вы должны рассмотреть пакеты, которые машина посылает и получает. Но следует учитывать следующее: эта команда захватывает все передаваемые и получаемые пакеты на сетевом уровне в соответствии набору фильтров в команде iptrace. Так как эта команда является пользовательским процессом она должна конкурировать с другими процессами за CPU. Следовательно, на сильно загруженной машине, iptrace может не захватывать все пакеты. И так как iptrace отслеживает пакеты на сетевом уровне, то нет никаких доказательств того, что пакет попал в кабель, так как прежде пакет должен пройти через драйвер и адаптер, чтобы добраться до кабеля.

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

Для транспортного уровня: команда tcpdump

Команда tcpdump следит за трафиком в сети и регистрирует заголовки пакета, которые соответствуют булеву выражению, задаваемому пользователем. Если никаких параметров не задано, команда будет отслеживать все пакеты в сети.

Для канального, сетевого и транспортного уровней: команда netstat

Команда netstat возвращает набор статистики относительно состояния сети. Команда netstat - хороший инструмент, чтобы помочь определить размещение проблемы.

Как только проблема изолирована, вы можете использовать более сложные инструментальные средства, чтобы продолжить её решение. Например, вы могли бы использовать команды netstat -i и netstat -v, чтобы определить, имеется ли проблема с конкретным аппаратным интерфейсом и затем выполнить диагностику, чтобы ещё более изолировать проблему.

Или, если команда netstat -s показывает, что существуют ошибки протокола, вы могли бы затем использовать команду iptrace для детализированного анализа.

Для канального, сетевого и транспортного уровней: команда netpmon

Этот инструмент контролирует и выдаёт статистику сетевого ввода-вывода и связанного с обслуживанием сети использования CPU.

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

Для канального, сетевого и транспортного уровней: сетевые анализаторы

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

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

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

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

Для уровней от канального до прикладного: Performance Reporter

Ранее было невозможно получить сводное представление обо всех системах и сетевой эффективности в сложной и распределенной среде. IBM SystemView for AIX Performance Reporter (Performance Reporter) устраняет эту проблему обеспечивая эффективные, информативные отчеты основанные на данных, сгенерированных из встроенной базы данных. Этот инструмент позволяет часто обнаруживать возможные проблемы до их возникновения.

Данные, собранные Performance Reporter помогут вам узнать то, какие пользователи используют какие ресурсы и проанализировать узкие места и другие проблемы производительности.

Вы можете собрать информацию о производительности с узлов под управлением AIX, Sun Solaris, и HP-UX. Вы можете легко использовать данные из базы данных Performance Reporter в других прикладных программах. Модель данных хорошо зарегистрирована и просто изменяется.

Performance Reporter поддерживает СУБД DB2/6000 и Oracle.

К содержанию Вперед Назад

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

К содержанию Вперед Назад

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

Система безопасности AIX соответствует уровню безопасности С2. Этот стандарт предъявляет к системе основные шесть требований:

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

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

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

Политика безопасности

"Безопасность - функция управления". Это утверждение повторяется при любом обсуждении проблем безопасности - и… часто игнорируется. Никакая комбинация аппаратных средств и программ защиты программного обеспечения не будет эффективна без соответствующей среды управления, включая все уровни управления.

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

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

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

· Какие типы данных должны быть ограничены для конкретных людей?
· Какие данные разделяется между отделами или другими группами?
· Что является доступным каждому в организации?
· Что является доступным для внешнего мира?
· Как должна организация разделена по группам (в смысле достижения целей безопасности)?
· Какие уровни безопасности необходимы для этих различных групп?
· Где раздел между удобством в работе и требуемой защитой?
· Какова стоимость безопасности?
· Что такое для вас приемлемая стоимость безопасности? (Затраты на администрирование и доставляемое неудобство пользователям - это также части общей стоимости безопасности).
· Какова стоимость потерянных, разрушенных или скомпрометированных данных?
· Сопоставима ли она со стоимостью затраченных средств на обеспечение безопасности?
· Кто будет управлять обеспечением информационной безопасности?
· Кто будет осуществлять контроль? Эти функции требуют времени и квалификации. Ведь пока нет таких интеллектуальных автоматизированных средств которые сами собой поддерживали бы необходимый уровень безопасности
· Как важно соблюдать политику безопасности сотрудниками?
· Каковы механизмы принуждения? Например, в некоторых организациях человека могут только пожурить за нарушение им требований безопасности. В других организациях этот человек был бы уволен немедленно за то же самое нарушение.

От кого защищаемся?

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

1. Ошибки. Например, пользователь может ошибочно удалить файл. Защищенные важные файлы и хорошая процедура резервирования (которая является также элементом безопасности) уменьшат эти проблемы.

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

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

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