Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
Лекция 14. Принципы управления сетями.
В предыдущих лекциях были рассмотрены компоненты, из
которых состоит сеть — кабели, транспортные протоколы, компьютеры,
операционные системы и приложения. Объединение всего этого не явля-
ется самой сложной частью задачи организации сети. После установки и
запуска сети следует ожидать иных трудноразрешимых проблем, связанных
с поддержкой сети в ее нормальном состоянии. Пользователи часто настаи-
вают на применении того, что обслуживается весьма хлопотно, и это тоже
создает проблемы.
В логической последовательности со всем рассмотренным ранее в
этой лекции рассмотрим основные принципы управления сетями, включая
несколько смежных вопросов.
• Что может произойти и где именно.
• Инструменты для наблюдения за сетевым графиком и состоянием оборудования.
• Концепция средств нулевого администрирования (zero administration).
• Методы внесения изменений в сети, не приводящие к "восстанию" пользователей.
• Технические средства диагностики неисправностей.
Перечисленные вопросы — это большой объем информации, но идея,
стоящая за концепциями управления, одна и та же: узнать, что у вас есть в
наличии, и взять все под контроль. Если вы научитесь это делать, ваша
работа значительно облегчится.
Источник знаний о сети - документация производителя
Первый шаг на пути к эффективному управлению сетью — получение
разнообразной информации, начиная с инвентарных номеров плат, схемы
компоновки всей сети и сведений о ее производительности. Ранее было
сказано о важности документирования параметров конфигурации плат
расширения, установленных в ПК. Принцип документирования остается
неизменным и на более высоких уровнях: каким иным образом вы сможете
узнать, будут ли совместно работать различные сетевые компоненты, если
вы не знаете точно, что они собой представляют? Следует целенаправленно
собирать сведения об организации вашей сети, ее производительности и
физических компонентах, и тогда при возникновении проблем вы будете
лучше подготовлены к их разрешению.
Выполнение аудита
После того, как сеть установлена и начала нормально работать, не
расслабляйтесь. Теперь самое время упорядочивать документацию. Позна-
комьтесь с вашей сетью поближе именно сейчас, пока все работает так,
как надо. Это не слишком благодарная работа, и не всегда она кажется
приятным времяпрепровождением, но окупается при возникновении
неисправностей.
Примечание
Документация особенно необходима для аварийного восстановления.
Во-первых, если вы будете знать, что собой представляет сеть во время
нормальной работы, вам будет легче обнаружить неисправность, когда она
не работает. "Не работает" не обязательно из-за неисправностей в резуль-
тате каких-то изменений в сети. Может быть, например, что часть сети
работает, но с пониженной производительностью. Так будет продолжаться
до тех пор, пока не будет определена и устранена причина.
Во-вторых, для поддержания работоспособности больших и протя-
женных сетей знание схемы физической компоновки вашей сети может
быть весьма важным при установлении причины возникновения нарушений
или при определении неисправной части сети.
Можно выделить две основные разновидности аудита локальных сетей:
физический и нематериальный (intangible). Аудит имущества и оборудо-
вания чаще всего является физическим — используйте его для определения
того, что имеется в наличии, и локализации местонахождения оборудо-
вания. Аудит производительности, эффективности и безопасности в боль-
шинстве случаев имеет нематериальную природу. Каков реальный уровень
графика локальной сети? Работает ли локальная сеть так эффективно, как
это допускают ее возможности, или же следует перераспределить ее ресурсы
с тем, чтобы требования пользователей были полностью удовлетворены?
Какой уровень безопасности необходим для локальной сети и удовлетво-
ряет ли она этим требованиям? В следующих разделах будет описано, что
именно следует определять при проведении аудита локальной сети.
Физические аспекты организации сети
Самая легко выполнимая часть аудита сети заключается в инвентари-
зации оборудования: что имеется, и где оно находится. Такая работа может
потребовать много времени, но она, в основном, исполняется неквалифици-
рованным персоналом. По большей части эта работа состоит в составлении
таблиц, содержащих описание компонентов вашего аппаратного и програм-
много обеспечения без всякой связи со средой, в которую они установлены.
Проведение инвентаризации.
Сначала точно определите, что у вас есть. Соберите информацию о каждом компьютере.
• Тип оборудования и общее назначение (ПК, маршрутизатор, мост),
название фирмы-изготовителя и номер модели.
• Серийный номер машины.
• Данные о пользователе машины.
• Информация о конфигурации машины, в том числе все имеющиеся у нее ресурсы, протоколы и подключенные устройства.
Проверьте установленное программное обеспечение
• Типы операционных систем клиентных и серверных компьютеров,
номера их версий, а также все инсталлированные на них вставки
(patch) и исправления (fix)
• Установленные приложения и (если возможно) даты установки и версии.
Примечание
Какое значение имеет время установки приложений"? Иногда ответ может быть
ключом к определению причины некорректного функционирования приложения
Многие приложения Windows имеют предварительно созданные библиотеки
данных или программ, называемые динамически подключаемые библиотеки, или
DLL (Dynamic Link Libraries) Для работы большинства приложений достаточно
одной DLL-библиотеки Однако при этом могут возникнуть проблемы, особенно
если DLL-файлы одного приложения будут заменены одноименными DLL-файлами другого с устаревшей информацией Отслеживание дат создания и записи файлов при инсталляции поможет вам избежать или своевременно диагностировать такие конфликты DLL
• Кто имеет доступ к этим приложениям
• Сколько существует лицензий для программного обеспечения.
Результаты инвентаризации оборудования могут быть поистине бес-
ценными при анализе состояния компонентов компьютера, места их
использования в сети, и их конфигурации Инвентаризация программного
обеспечения необходима не только для учета текущих версий, но также
может помочь и при его лицензировании.
Проведение аудита оборудования. При проведении аудита оборудования
сначала достаньте копию проекта вашего офиса и обойдите здание. На
проекте следует отметить следующее.
• Места отводов кабелей и длину их прогонов
• Места установки терминаторов, если это сеть Ethernet.
• Тип используемого кабеля в каждой части сети (например, в сети со
звездообразной топологией используют кабель UTP категории 5 для
соединений с настольными системами, но для магистральных соеди-
нений — оптоволоконный кабель).
• Сетевое оборудование (маршрутизаторы, мосты, коммутаторы и серверы)
• Цветовые или иные условные обозначения, примененные для идентификации прогонов кабеля.
Совет
Если вы еще не промаркировали прогоны кабелей, обязательно сделайте это
во время аудита оборудования
Сохраните копии проекта в сейфе, и в случае каких-либо изменений
не забудьте обновить записи Результаты аудита оборудования являются
основой построения карты вашей сети (описываемой далее в этой главе в
разделе "Создание карты сети")
Аудит оборудования — подходящий момент для ознакомления со всем
зданием, а не только с сетью. Изучите месторасположение выключателей
электропитания и водяных кранов, кондиционеров и нагревательных
устройств, а также всего того, что может потенциально воздействовать на
вашу сеть.
Нематериальные аспекты сети
Хотя и более субъективным (по сравнению с инвентаризацией средств
физического уровня и аудита оборудования), но значительно более важным
является аудит состояния сети (ее производительность и безопасность). На
этом этапе аудита вы должны оценить эффективность функционирования
и распределения сетевых ресурсов, определить степень безопасности и
зафиксировать нормальную конфигурацию сети, чтобы можно было иден-
тифицировать какие-либо отклонения от этой конфигурации.
Регистрация эффективности функционирования. Аудит функциониро-
вания — это учет всего, что может случиться в сети, но без каких бы то
ни было катастрофических последствий. В процессе аудита следует зафик-
сировать"
• величину генерируемого сетевого трафика;
• сегменты, в которых сосредоточен этот трафик;
• изменение графика и загрузки сервера в течение дня;
• наиболее перегруженные средства сервера;
• количество лицензий на приложения, используемые в каждый момент
времени;
• источники сетевого графика
Даже если сеть работает хорошо, результаты аудита ее функциониро-
вания будут весьма ценными. Имея такую информацию легко идентифи-
цировать изменения, которые могут привести к неисправности, или решить,
где именно для улучшения работы сети предусмотреть новые ресурсы
Определение сетевой эффективности. Аудит функционирования служит
для контроля процессов, происходящих в сети. Аудит эффективности
заключается в анализе полученной информации и определении эффектив-
ности работы сети. Этот аудит выполняется путем анализа результатов
проверки операционной среды.
Задайте себе несколько вопросов.
• Равномерно ли загружена сеть, или же некоторые сегменты имеют небольшой график, в то время как другие перегружены?
• Можно ли маршрутизировать некоторую часть графика иным образом с целью выравнивания нагрузки в сети?
• Насколько заняты серверы? Могут ли они удовлетворять требованиям пользователей все дневное время?
Сравните результаты аудита функционирования с аудитом эффектив-
ности, чтобы определить, как можно перераспределить сетевые ресурсы.
Определение установок системы защиты. Наконец, осталось только
провести аудит системы защиты. Далее рассмотрим основные причины
появления лазеек в системе защиты и способы их поиска, а здесь перечис-
лим общие вопросы, на которые следует обратить внимание.
• Может ли каждый пользователь легко получить доступ к нужным ему ресурсам?
• Защищены ли ресурсы сети от пользователей, не имеющих к ним доступ
как изнутри, так и извне компании, если ваша компания владеет
внешней частью сети (extranet)?
• Какие меры предприняты для защиты от вирусов?
• Какие меры предприняты для защиты данных?
Для выполнения аудита системы защиты требуется объединить операции
инвентаризации существующих систем и получения вводимой информации.
Аудит системы защиты не только просто блокирует доступ пользователей
к сети, но также и обеспечивает им гарантированный доступ к требуемым
ресурсам. Определите, что именно на самом деле требуется пользователям
для работы, и, если это практично и необходимо для дела, ослабьте защиту
ресурсов, чтобы сделать их более доступными.
Хранение аудиторской информации
Получив всю упомянутую выше информацию, сохраните ее в одном (общем) месте.
По многим соображениям не рекомендуется делать записи на бумаге
(исключая чертежи). Бумажные отчеты трудно обновлять, легко потерять
или испортить, на них могут появиться неразборчивые надписи, сделанные
вручную (а если они подготовлены на компьютере, то зачем нужно печатать
все эти записи?), и они не всегда доступны. Единственный случай, когда
полезно иметь твердую копию — во время планерок (planning meetings), на
которых предполагается представить их руководству и подразделению,
обслуживающему сеть.
Наилучшим местом хранения информации, по-видимому, являются
базы данных. Они удобочитаемы, их легко обновлять, в них предусмотрены
средства для проведения поиска, они всегда находятся под рукой и содержат
достоверную информацию (пока вы регулярно их обновляете).
С этой целью можно приобрести какую-либо имеющуюся на рынке
аудиторскую базу данных Однако нетрудно и самому создать внутрифир-
менную аудиторскую базу данных, которая, скорее всего, больше вас
устроит, поскольку вы сами ее разработаете. Для облегчения ввода инфор-
мации можно даже создать формы для внешнего интерфейса с соответст-
вующими таблицами данных. Если вы никогда не создавали приложение
для ввода данных, то познакомьтесь с этим процессом.
1. Идентифицируйте главную тему каждой таблицы (например, аудиты
инвентарных принадлежностей, оборудования, функционирования, и т.д.)
и создайте таблицу.
2. Идентифицируйте категории данных, заносимых в каждую таблицу (тип
устройства, серийный номер, число пакетов, посылаемых в час, даты
установки и т д.) и создайте соответствующие поля.
3. Создайте средства внешнего интерфейса с каждой таблицей, предусмотрев позиции для ввода пользовательских данных.
Совет
Для полей, имеющих заранее определенное множество допустимых значений,
можно создать поля со списками выбранных пользователем пунктов Это поможет
предотвратить внесение в данные грамматических ошибок, которые могут помешать проведению поиска
Создайте все это, и тогда при открытии базы данных вы сможете
выбрать одну из таблиц в отображаемом списке (рис 14.1).
Откройте таблицу, для которой вы создали форму, и вы увидите нечто,
напоминающее форму, показанную на рис 14.2
Создание базы данных может показаться сложным делом, но это не
так, и вполне доступно тем, кто этим не занимался ранее Наиболее
сложной частью такой работы является идентификация информации,
вводимой в базу После того как вы это сделаете, создание таблиц и форм
в основном будет заключаться во вводе с клавиатуры имен полей и рисо-
вании элементов внешнего интерфейса, удобных для восприятия. Конечно,
чтобы создать базу данных соответствующего формата, может потребоваться
некоторое время. Однако если это сделать, вы получите приложение, с
помощью которого можно легко хранить и обновлять данные (и результаты)
аудита, а также базу данных, позволяющую создавать отчеты в любое
нужное время.
Создание карты сети
Часть данных по аудиту можно не только записывать в базу данных, но и хранить в форме карты, позволяющей легко определить связь частей сети друг с другом. Карта может быть выполнена в виде твердой копии или храниться в электронном виде и содержать описание сети на физическом уровне вместе с ее логической организацией.
Рис. 14.1. База данных содержит одну несколько таблиц, каждая из которых посвящена определенной теме
Рис. 14.2. База данных аудита инвентарных принадлежностей,
созданная с помощью Access 97.
Представление сети на физическом уровне
Фактически можно иметь несколько физических карт вашей сети в
зависимости от ее размера и сложности. Физическая карта напоминает
карту оборудования, показывающую местонахождение компонентов сети
относительно друг друга. Поэтому на одной карте можно показать разме-
щение сети в здании, идентифицируя каждый узел сети, например имена-
ми пользователей (рис. 14.3). На другой карте можно показать всю сеть,
вплоть до ее выхода в глобальную сеть (рис. 14.4). Назначение карт
различное: к каждой из них следует обращаться для получения ответов
на различные вопросы.
Рис. 14.3. Пример физической карты сети для двухэтажного здания.
Рис. 14.4. Пример физической карты сети предприятия.
Логическая схема сети
Физическая карта сети показывает размещение компонентов относи-
тельно друг друга. В отличие от нее логическая карта сети (logical network
тар) показывает организацию сетевых ресурсов (рис.14.5). Какие клиенты
и к каким серверам имеют доступ? Какую информацию содержат те или
иные серверы или группа серверов? Какие репликации выполняются в
сети? Ответы на эти вопросы могут быть на физической карте, хотя и не
всегда.
Рис. 14.5. Логическая карта структурной организации сети
И все же для демонстрации различных уровней сети во всех деталях
может потребоваться несколько различных карт. Например, необходимо
узнать, какие клиенты подключились к конкретному серверу входной
аутентификации (authentication server) или какие базы данных реплици-
руются посредствами глобальной сети для контроля потоков сетевого
трафика.
Обзор средств управления сетями
Теперь вы представляете, какую информацию о сети необходимо иметь
под рукой. Однако, вы не сможете получить всю нужную информацию,
просто прогулявшись по зданию. Такой обход сети может оказаться физи-
чески невозможен, и в любом случае не вся информация выявляется так
просто. Читайте дальше, и вы узнаете больше о тех средствах, которые
можно использовать для сбора информации о вашей сети, чтобы далее
заставить ее делать именно то, что вам нужно.
Средства для контроля работы сервера
Одним из ключевых условий успешной работы сети является произво-
дительная работа сервера. Если сервер не соответствует предъявляемым к
нему требованиям, то даже при достаточной полосе пропускания соедини-
тельных линий производительность сети не будет высокой. Для отслежи-
вания работы компонентов сервера и поступающих на него запросов, а
также для наблюдения за текущими значениями параметров или регистра-
цией результатов входов в сервер с целью последующего изучения можно
использовать соответствующее инструментальное средство для наблюдения
за сервером.
При использовании системы Windows NT вы получите в ее составе
один из инструментов для наблюдения за сервером — Performance Monitor
(Монитор производительности). Рассмотрим этот инструмент в качестве
примера реализации подобных средств. Дополнительные инструменталь-
ные средства наблюдения за сервером (включая используемые в Windows
NT) устроены если не точно так же, то весьма схоже.
На экране монитора производительности ресурсы группируются в виде
объектов и счетчиков внутри этих объектов. К объектам относятся ресурсы
основных категорий, таких как процессор, рабочие очереди сервера, физи-
ческие диски, файл подкачки (paging file). Счетчики внутри этих категорий
контролируют такие специфические величины, как номера прерываний,
обрабатываемых процессором каждую секунду, количество клиентов, запросы
которых были обслужены отдельным процессором, время, затраченное на
чтение с диска, или процент используемого файла подкачки в данный
момент времени. Некоторые счетчики подразделяются на копии (instance).
Например, один из счетчиков для объекта Process (Процесс) измеряет
процессорное время, отведенное каждому исполняемому процессу на
выбранном компьютере. У этого счетчика имеются копии — это значит,
что можно наблюдать или за суммарной процентной долей полного
процессорного времени, используемого всеми процессами, или выбрать
для наблюдения отдельные процессы.
Для организации наблюдения за системой с помощью монитора произ-
водительности следует выбрать наблюдаемый компьютер, найти интере-
сующий объект и выбрать счетчик (или счетчики). Щелкните на кнопке
Add (Добавить) и добавьте линию, с помощью которой на диаграмме будет
отображаться выбранный счетчик. Как показано на рис. 14.6 линия каждого
счетчика будет иметь отличающийся от других цвет, так что вы сможете
без труда за ней проследить.
Рис. 14.6. Используйте монитор производительности Windows NT для построения диаграммы запросов к серверным ресурсам
Наблюдайте за производительностью сервера дистанционно, если это
возможно. В противном случае монитор сам станет использовать ресурсы
сервера, что приведет к искажению результатов, поскольку некоторая
часть памяти и циклов процессора будет выделена для поддержки монитора.
Совет
Если вы должны запускать монитор производительности на наблюдаемом сервере, то обязательно следите за копией PERFMON счетчика Processor Time (Процессорное время) объекта Process. Это даст вам, по крайней мере, некоторое представление относительно того, как много процессорного времени выделяется монитору производительности.
Чтение выводимых монитором данных не вызывает затруднений. Трудности могут возникнуть в понимании скрытого смысла читаемой информации. Следует знать, как именно осуществляется взаимодействие различных частей сервера и какое оборудование задействовано для поддержки различных запросов к серверу. Чтобы узнать о работе сервера
как можно больше, следует иметь некоторое представление об архитектуре серверов Вы не получите никакой полезной информации, наблюдая за ростом значения счетчика Threads (Потоки), если не будете знать, что такое поток, почему число потоков может расти и что означает такое поведение счетчика. Эта лекция не может научить вас всему тому, что связано с наблюдением за сервером, но в табл. 14.1 описаны несколько основных счетчиков
Используя знания функций сервера, вы сможете идентифицировать и осмыслить показания других счетчиков.
Таблица 14.1.
Некоторые счетчики и их описание
|
Объект: счетчик |
Описание |
Дополнительная информация |
|
Logical Disk % |
Доля |
Используйте эту информацию для |
|
Free Disk Space |
неиспользуемого |
определения свободного дискового |
|
(Логический диск |
дискового |
пространства В Windows NT 4 вы |
|
% свободного |
пространства на |
не можете использовать эту |
|
дискового |
выбранном |
информацию для распределения |
|
пространства) |
логическом томе |
дискового пространства по |
|
пользователям, если только у каждого |
||
|
из них нет отдельного тома |
||
|
Logical Disk Avg |
Среднее количество |
Используйте эту информацию для |
|
Disk Queue Length |
запросов на чтение и |
определения загрузки диска на |
|
(Логический диск |
запись к тому |
протяжении всего дня |
|
средняя длина |
логического диска в |
|
|
очереди диска) |
течение указанного |
|
|
интервала времени |
||
|
Memory. |
Доля памяти, |
Показывает процентную долю |
|
% Committed Byte |
используемой тем или |
виртуальной памяти, используемой |
|
in Use (Память |
иным процессом в |
в определенный момент времени |
|
% использования |
сравнении с той, что |
|
|
выделенных |
могла бы быть |
|
|
байтов) |
использована |
- |
|
Memory Page |
Частота обращения к |
Некоторое количество ошибочных |
|
Faults/Sec |
данным в файле |
страниц предусматривается заранее, |
|
(Память Ошибки |
подкачки на диске |
но большое количество означает |
|
страницы/С) |
вместо обращений к |
недостаточный размер виртуальной |
|
оперативной памяти |
памяти по сравнению с |
|
|
предъявляемыми запросами |
||
|
Physical Disk- Avg |
Среднее количество |
Используйте эту информацию для |
|
Disk Queue Length |
запросов на чтение и |
определения нагрузки на диск в |
|
(Физический диск: |
запись к физическому |
течение дня. В зависимости от этой |
|
Средняя длина |
диску в течение |
информации вам может |
|
очереди диска) |
заданного интервала |
потребоваться возложить часть |
|
времени |
нагрузки на более быстрый диск |
|
|
Physical Disk: Disk |
Скорость чтения и |
Показывает скорость ответов |
|
Transfer/sec |
записи данных на |
выбранного диска на запросы |
|
(Физический диск: |
отдельный |
пользователя |
|
среднее время |
физический диск |
|
|
обращения, с) |
||
|
Processor: |
Показатель того, как |
Показывает степень загрузки |
|
% Processor Time |
часто процессор |
процессора. Загруженность |
|
(Процессор: % |
занят полезной |
процессора не обязательно означает |
|
нагрузки) |
работой, а не |
нечто плохое, а отслеживание |
|
находится в простое |
степени загрузки позволяет ^ |
|
|
• предотвратить появление "узких |
||
|
мест" |
||
|
Server: Bytes |
Количество байтов, |
С его помощью можно |
|
Total/sec (Сервер: |
передаваемых и |
проанализировать количество |
|
Всего байтов/с) |
получаемых каждую |
операций чтения и записи, чтобы |
|
секунду |
посмотреть, как быстро сервер |
|
|
отвечает на запрос определенного |
||
|
* |
типа и как много запросов данного |
|
|
" типа поступает |
||
|
Server: Errors |
Неудавшиеся |
Высокое количество может означать |
|
Logon (Сервер: |
попытки входа на |
попытку получения |
|
Ошибки входа) |
сервер |
несанкционированного доступа |
|
путем угадывания пароля или с |
||
|
помощью специальных программ |
||
|
для его подбора |
||
|
Server: File |
Количество процедур |
Эта величина характеризует |
|
Directory Searches |
поиска файла, |
занятость сервера |
|
(Сервер: Число |
выполненных за |
|
|
поисков каталога |
выбранный интервал |
|
|
с файлом) |
времени |
|
|
Server Work |
Текущее количество |
Более четырех ожидающих |
|
Queues: Queue |
запросов, ожидающих |
запросов в каждый заданный |
|
Length (Рабочие |
получения |
момент времени может означать |
|
очереди сервера) |
процессорного |
перегрузку процессора |
|
времени. Если в |
||
|
системе установлено |
||
|
несколько |
||
|
процессоров,этот |
||
|
счетчик работает |
||
|
отдельно для каждого |
||
|
из них |
Вам может потребоваться и другая информация, причем в достаточно
большом объеме, средства получения которой не предусмотрены в мони-
торе производительности. Но приведенные сведения позволят вам почув-
ствовать, какого типа информацию вы можете получить с помощью
средств наблюдения за сервером
В определенной степени тип информации, которая может представлять
для вас наибольший интерес, зависит от роли отслеживаемого вами сервера.
Например, наблюдение за дисковым пространством на файловом сервере
будет более полезным, нежели контроль сервера приложений, а количество
обслуженных CGI-запросов имеет значение только для Web-сервера.
Однако некоторые ресурсы важны для серверов любых типов — циклы
процессора, объекты, использующие память, полезная доля оперативной
памяти или файла подкачки, а также количество запросов в очереди — все
это примеры таких ресурсов.
В принципе, вы можете использовать столько счетчиков и в таком
количестве объектов, сколько пожелаете. Однако поскольку с помощью
инструментов наблюдения за сервером можно собрать очень большой объем
данных, лучше всего сконцентрироваться на получении именно тех данных,
которые важны для вас в текущий момент времени. Особенно важно
сфокусировать свое внимание во время сбора информации. Сколько
запросов в секунду обрабатывает ваш сервер в каждый данный момент
рабочего дня? Как этот показатель изменяется на протяжении дня или'
месяца? Определите нормальные значения параметров и запишите их, чтобы
при отклонениях вы могли идентифицировать изменения и обнаружить их
источник.
Сетевые мониторы
В своей работе вы обязательно будете использовать программные
средства, использующие протоколы управления сетью, для сбора информации
о сети и иногда для отправки команд удаленным компьютерам. Это не просто
средства пассивного наблюдения. Они могут быть использованы для
уведомления ответственного лица о возникновении проблемы.
Сетевые мониторы состоят из двух частей: клиентной, расположенной
на наблюдаемом устройстве, и серверной, расположенной на устройстве,
выполняющем наблюдение и запись собранной информации. Взаимодей-
ствие клиентной и серверной частей зависит от протокола наблюдения.
Несмотря на это, все программное обеспечение для наблюдения за сетью
спроектировано с одной целью — сбора информации о сети. Для выполнения
такой работы может потребоваться"
• транспортный протокол сбора статистической информации;
• идентификация узлов сети;
• сбор данных о конфигурации программного обеспечения и оборудования;
• сбор статистической информации о производительности и загруженности
каждого сервера Internet (host);
• запись статистической информации об использовании приложений;
• запись сообщений о событиях и ошибках.
Содержание собираемой информации зависит от элементов, за состоя-
нием которых можно наблюдать и обслуживать отдельными программными
продуктами для наблюдения/управления сетью. Каждый сервер Internet
(host), допускающий управление такого типа, для каждого наблюдаемого
элемента имеет текстовый файл, называемый административной базой
данных (MIB — Management Information Base). Файл MIB содержит следую-
щую информацию.
• Список наблюдаемых объектов.
• Синтаксис наблюдаемых объектов.
• Предоставляемый для наблюдения доступ (только для чтения, или же
для чтения/записи).
• Статус (обязательный или нет) объектов.
• Описание объекта.
Короче, файл MIB содержит список наблюдаемых объектов системы и
их характеристики. Комплект средств Windows NT Resource Kit содержит
файл MIB (ведущий свою родословную от списка адресов SNMP), назы-
ваемый TOASTER.MIB, который иллюстрирует синтаксис. Ниже приведен
один из объектов файла MIB.
toasterDoneness OBJECT-TYPE
SYNTAX INTEGER (1..10)
ACCESS read-write
STATUS mandatory
DESCRIPTION
"This variable controls how well done ensuring toast should be on a scale of 1 to 10. Toast made at 10 is generally considered unfit for human consumption; toast made at 1 is lightly warmed.(Этот параметр указывает, насколько хорошо был сделан тост, его значение лежит в диапазоне от 1 до 10. Тост, сделанный при параметре 10, обычно считается непригодным для употребления; 1 означает лишь легкий подогрев) " := (toaster 4)
Таким образом, значение, ассоциированное с объектом toasterDoneness, указывает, насколько хорошо был приготовлен тост. Монитор может также оценить, попадает ли это значение в некоторый интервал (скажем, между 3 и 7 для хорошо сделанного тоста) и выдает предупреждение сетевому администратору при выходе величины за допустимые границы. Значение в скобках внизу ({toaster 4}) — номер объекта. Таким образом, toasterDoneness является четвертым типом объектов, определенным в файле MIB.
Примечание
Этот пример соответствует стандарту, называемому М1В-11. Для того чтобы за устройством можно было наблюдать или управлять им с помощью последней версии SNMP-списка, оно должно использовать этот формат для своих файлов М1В
Для применения наиболее популярного метода сбора данных (когда
вам требуется информация сразу о нескольких управляемых объектах), вы
можете запросить ее у сетевого монитора. Монитор, в свою очередь, запра-
шивает информацию у сервера Internet (host), используя при этом имя
объекта. Сервер производит поиск имени, определяет связанное с ним
значение и возвращает монитору отчет.
Не все протоколы средств наблюдения за сетью используют одинаковые
файлы М1В и даже не все протоколы одного типа работают с одинаковыми
файлами М1В. Для того чтобы средство наблюдения соответствовало
стандартному протоколу, при разработке средства следует придерживаться
руководящих принципов сбора данных, указанных в стандарте протокола.
Если в программном продукте для наблюдения используется, как минимум,
один определенный М1В, то он должен быть согласован со стандартом.
С практической точки зрения это значит, например, что не все исполь-
зующие SNMP-список сетевые мониторы созданы одинаковыми (равными).
Требуется тщательно проверять, какую именно информацию позволяет
собирать тот или иной программный продукт.
Простой протокол сетевого управления (SNMP)
Простой протокол сетевого управления (SNMP — Simple Network Management
Protocol) является примером события, часто встречающегося в мире сетей:
появившееся как временная "затычка" средство становится стандартным,
поскольку предназначенная ему на замену усовершенствованная технология
несколько опоздала к тому времени, когда это средство стало доступным.
Изначально протокол SNMP был спроектирован как простой, облегченный
метод наблюдения за интрасетями, в которых используется протокол
TCP/IP. Более совершенный протокол CMIP (Common Management Information
Protocol — общий протокол передачи управляющей информации), соответст-
вующий модели OSI, предназначался в качестве замены SNMP, но этого
так и не произошло по двум причинам. Первая: CMIP и в самом деле более
мощный протокол, чем SNMP, и позволяет собирать информацию, которую
SNMP собрать не может. Но такое расширение возможностей привело к
недопустимой перегрузке ресурсов сети и сервера. Вторая: к тому времени,
когда протокол CMIP стал пригодным для использования, протокол
SNMP настолько широко распространился, что стоимость его замены
стала превышать выгоду от применения протокола CMIP. Таким образом,
SNMP стал самым распространенным стандартным протоколом для инстру-
ментов сетевого управления.
Протокол CMIP - претендент № 2
Ранее была упомянута технология SMDS, служащая примером мощной
технологии, вытесненной менее мощной Frame Relay, изначально предна-
значавшейся для временного заполнения определенной ниши до окончания
разработки SMDS. Это довольно обычная история — то же самое случилось
и со CMIP-протоколом.
Протокол CMIP задумывался как более мощное средство, призванное
заменить протокол SNMP. CMIP поддерживает функции, которые в
SNMP отсутствуют; он может работать на любой платформе (версия для
взаимодействия только с TCP/IP называется СМОТ). Он может предоста-
вить такие средства управления, которые отсутствуют в SNMP. В сущности,
он работает совершенно иначе, чем SNMP. Вместо опроса устройств для
определения их статуса или получения о них какой-либо информации,
CMIP ждет, пока устройства сами не предоставят отчеты диспетчеру
CMIP.
По иронии судьбы, причиной отказа от CMIP стала его мощность. Он
требует больше серверных ресурсов, чем может позволить большинство
сетей. В конце 90-х гг. — все это уже история. По поводу протокола CMIP
публикуется многообещающая информация: "Если CMIP поступит в
коммерческое пользование, он будет иметь огромное число заказчиков,
поскольку над его разработкой продолжают работать все учебные инсти-
туты". Однако кажется маловероятным, что CMIP сможет вскоре заменить
SNMP. Протокол SNMP широко распространен и пользуется признанием,
чтобы его в данный момент можно было легко заменить, и хотя он не
такой мощный, как CMIP, зато не так требователен к ресурсам.
Как работает протокол SNMP. При работе протокола SNMP используют
файлы MIB подобно тому, как при переписи населения — опрос. Через
регулярные промежутки времени (или по сигналу запроса) серверная часть
SNMP запрашивает у устройства информацию о его статусе, используя
данные из MIB-файла устройства. Когда агент получает такой запрос, он
возвращает требуемые значения. Между клиентной и серверной частями
монитора информация перемещается с помощью протокола UDP (User
Datagram Protocol — протокол пользовательских дейтаграмм), являющегося
компонентой транспортного уровня протокола TCP/IP. UDP — протокол
без соединения (точнее без подтверждения). Это значит, что он позволяет
передавать сообщения, не заботясь об их приеме, и поэтому не вносит
большого вклада в сетевой график. Конечно, протокол SNMP или какое-либо
другое средство наблюдения за сетью увеличивают сетевой трафик, но все
они спроектированы так, чтобы это воздействие было минимальным.
Устройства для наблюдения за сетью, которые требуют большого сетевого
трафика (и, следовательно, "несут ответственность" за большую часть
графика), не особенно полезны.
Примечание
Хотя существует стандарт, регламентирующий применение SNMP в сетях с протоколом IPX/SPX (в котором для передачи сообщений применяется протокол IPX вместо UDP), но гораздо более вероятно, что вы столкнетесь с протоколом SNMP в сетях TCP/IP. Не все версии протокола SNMP поддерживают передачу сообщений посредством IPX-протокола.
Вспомните, что протоколы наблюдения за сетями содержат два компо-
нента: диспетчер, расположенный на сервере, и агент — на управляемом
устройстве (рис. 14.7). В этом простом примере диспетчер запрашивает у
агента (возможно, исполняемого на файловом сервере) информацию о
количестве поддерживаемых им соединений. Получив этот запрос, агент
отыскивает на FTP-сервере данные и передает их диспетчеру.
Рис. 14.7. Сетевое взаимодействие по протоколу SNMP между
диспетчером и агентом
Не в каждом устройстве сети имеется агент SNMP. Он есть только в
тех, за которыми необходимо наблюдать, и сконфигурированных для
поддержки SNMP. Поддерживающие протокол SNMP устройства, например,
маршрутизаторы или мосты, всегда снабжены агентами SNMP, но если вы
хотите наблюдать за компьютером определенного (возможно, нестандарт-
ного) типа, вам следует самому установить агента. В NT это делается
путем запуска средств SNMP как на наблюдаемом устройстве, так и на
диспетчерском компьютере.
По умолчанию (и согласно рекомендациям стандарта) агенты SNMP
конфигурируются следующим образом: для приема сообщений назначается
порт 161, для пакетов перехода (traps) — порт 162. Если вам требуется
установить на отдельном компьютере несколько агентов SNMP, вы можете
изменить назначенный порт. В NT, например, информация о назначенных
портах хранится в файле SERVICES (файл без расширения; но вы можете
открыть этот файл с помощью редактора Notepad), который находится в
папке System32\Drivers\Etc. Поищите там, например, такие записи:
snmp 161/udp snmp
snmp-trap 162/udp snmp
Первый столбец описывает средство обслуживания, для которого пред-
назначен порт, второй — задает номер порта, третий — указывает протокол
для передачи информации, четвертый — определяет псевдоним указанного
средства.
Предупреждение
Это средство не имеет "защиты от дурака" Редактируйте файл SERVICE (или
иным образом изменяйте конфигурацию какого-либо другого порта), только если
вы абсолютно уверены в том, что вы делаете, и твердо знаете, что не измените
установки других портов устройства
Агент SNMP ждет дейтаграммы от диспетчера SNMP с запросом
информации. Когда агент получает такое сообщение, то выполняет одну
из указанных ниже операций
get — отыскивает указанный параметр управляемого объекта;
get next — отыскивает следующий параметр в файле MIB,
set — изменяет параметр управляемого объекта, пользуясь привилегией
на чтение/запись.
Когда диспетчер SNMP получает от агента данные, он может либо
просто отобразить их, либо сохранить в базе данных для дальнейшего
использования '
Операции get и set выполняют только в ответ на запрос от диспет-
чера SNMP. Без запроса агент SNMP посылает сообщение только в двух
случаях когда узел останавливается или запускается, или когда значения
некоторых контролируемых параметров выходят за пределы допуска и
требуется передать сигнал тревоги Эти сообщения называют пакетами
переходов (traps) Они отправляются по IP- и IPX-адресам или по адресу
сервера Internet (host), указанному вами во время установки средств обслу-
живания SNMP на данном компьютере
Сетевое взаимодействие по протоколу SNMP. Система защиты SNMP-протокола базируется на концепции среды (communities), представляющей
собой логическую структуру SNMP-машин, объединенных под общим
именем, аналогично рабочей группе Подобно рабочей группе, члены
среды часто физически расположены близко друг от друга, но это не
обязательное условие По сути дела, имя среды — пароль и должно тракто-
ваться только таким образом
Лишь те агенты и диспетчеры, которые входят в одну среду, могут
общаться друг с другом. Когда монитор посылает агенту сообщение с
запросом на получение информации, имя среды является составной
частью сообщения. Когда он принимает сообщение, то проверяет коррект-
ность полученного имени среды. В случае несовпадения агент отбрасывает
сообщение и, при необходимости, может зарегистрировать факт неудавшейся
аутентификации Только в случае, если агент и диспетчер используют
одинаковое имя среды, сообщение будет обрабатываться
По умолчанию все серверы NT, поддерживающие SNMP-протокол,
изначально являются частью открытой (public) среды Для дополнительной
безопасности вы можете удалить имя среды или создать другую среду.
Машина SNMP — агент или диспетчер — может быть членом одновременно
нескольких сред. Если диспетчер SNMP не входит в состав ни одной среды,
он уподобляется устройству, не имеющему защитного пароля, и любой
клиент SNMP может взаимодействовать с диспетчером независимо от
того, членом какой именно среды является клиент.
Удаленное наблюдение (RMON)
На протяжении всей истории сетей, помимо средств наблюдения за
сетью, предоставляемых протоколом SNMP, применялись также и аппа-
ратно реализованные устройства удаленного наблюдения, например, сетевые
мониторы и сетевые зонды (probe). Обычно (но не всегда) эти устройства
представляют собой автономные инструментальные средства для решения
задачи сбора сетевых данных, и они должны быть установлены в каждом
сегменте маршрутизированной сети.
RMON (Remote Monitoring — удаленное наблюдение) — средство работы с
оборудованием, предназначенным для выполнения сложных функций
управления сетью. RMON — это протокол для сбора информации обо всей
сети из единственного узла, применение которого позволяет отказаться от
услуг специалиста, непосредственно наблюдающего за объектом, который
подозревается в неисправности, и анализирует сетевые данные. Вместо
этого центрального узла можно активировать удаленный монитор и пору-
чить ему направлять информацию об определенном сегменте на централь-
ную консоль. Единственное ограничение здесь то же самое, что и в случае
применения протокола SNMP: наблюдаемое устройство должно иметь
установленный агент RMON.
Хотя в обоих протоколах RMON и SNMP используются файлы MIB,
это вовсе не одна и та же вещь. Оба они — средства управления сетями, но
RMON обеспечивает поддержку расширенного набора файлов MIB,
позволяющих собирать больше информации, чем SNMP. Основная функция
SNMP заключается в получении подтверждения о том, что все части сети
работают нормально. RMON предназначен для большего — он фактически
является сетевым анализатором, используемым для измерения трафика
данных в определенном сегменте локальной сети с целью определения его
структуры и причины появления сколько-нибудь существенных узких
мест. В определенных случаях RMON может использоваться не только для
чтения данных, но и для записи, в зависимости от того, имеет ли какой-
либо смысл задание значений параметров отдельного объекта. Как и при
использовании протокола SNMP вам не следует наблюдать за процессом
сбора данных в реальном масштабе времени. Инструментальные средства
RMON позволяют подавать сигнал тревоги при выходе значений некоторых
параметров за предварительно установленные допустимые границы или
записывать данные в специальный журнал для последующего просмотра.
Первая версия протокола RMON позволяла собирать информацию
только на канальном уровне. Но в версии RMON2, стандартизованной в июне 1997 г., предусмотрен сбор информации уже на сетевом уровне,
вплоть до уровня портов, если это необходимо. RMON2 также поддержи-
вает работу с некоторыми (специфическими для глобальных сетей) типами
данных и позволяет идентифицировать ситуации, возникшие из-за каких-
либо проблем на сетевом уровне, например, обрыва кабеля. RMON не
фиксирует ошибки в пакетах на канальном уровне, поскольку данные из
MIB-файла позволяют идентифицировать их только путем "разборки"
кадра и его последующего чтения. Если на канальном уровне имеются
ошибки, объем получаемой полезной информации будет относительно
невелик. Однако на сетевом и вышележащих уровнях RMON может иден-
тифицировать ошибки протокола и сообщать о них.
Данные, собираемые с помощью RMON, могут быть получены от одного
из следующих источников.
Каталог протокола. Список имеющихся протоколов, которые удаленный
монитор в состоянии отслеживать.
Распространенность протокола. Процентная доля пакетов, созданных в
сегменте с помощью каждого из протоколов.
Установление соответствия адресов. Списки установленного соответствия
адресов канального уровня адресам сетевого вместе с информацией о том,
где это соответствие отслеживалось в последний раз.
Сервер Internet (host) сетевого уровня. Управляет величиной трафика
между каждой парой сетевых адресов, определенных с помощью зонда
(probe).
Матрица сетевого уровня. Подсчитывает величину трафика между
каждой парой сетевых адресов, определенных с помощью исследования.
Сервер Internet (host) прикладного уровня. Управляет величиной трафика
между каждой парой сетевых адресов, определенных с помощью исследо-
вания, распределяя результаты в соответствии с протоколом.
Матрица прикладного уровня. Подсчитывает величину трафика между
каждой парой сетевых адресов, определенных с помощью исследования,
распределяя резульгагы в соответствии с протоколом.
Примечание
"Прикладной уровень" в стандарте RMON не обязательно относится к протоколу,
функционирующему на 7-м уровне модели OSI. Это может быть любой протокол,
функционирующий на уровнях выше сетевого. Поэтому он включает протоколы
транспортного, сеансового, представления данных или прикладного уровней.
Предыстория пользователя. Собирает данные по каждому пользователю
сети.
Конфигурация зонда. Управляет способом, с помощью которого средства
удаленного наблюдения могут быть запрограммированы с главной консоли.
Совместимые с RMON устройства не обязаны поддерживать обработку
всех этих категорий данных, но если уж они поддерживают какую-либо категорию, то должны делать это полностью. Совместимое с RMON
устройство может и не предоставлять некоторую часть информации о
сервере Internet (host) на сетевом уровне из всего определенного в
стандарте набора. К тому же некоторые группы зависят от других групп.
Также совместимые с RMON устройства не могут использовать файлы
MIB, связанные с матрицей прикладного уровня, если они не применяют
матрицу сетевого уровня. Вы не сможете подсчитать график между узлами
в соответствии с протоколом, если не в состоянии подсчитать трафик
между узлами, независимо от транспортного протокола.
RMON важен не только потому, что позволяет собирать разнообразные
данные, но также и потому, что обеспечивает непрерывный процесс сбора
данных, независимо от того, функционирует ли в данный момент времени
соединение между средствами удаленного наблюдения и главной консолью.
Такой непрерывный поток собираемых данных поддерживает систему в
состоянии, максимально соответствующем текущему моменту.
Например, вы не можете гарантировать, что удаленно управляемое
устройство будет всегда соединено с главной консолью наблюдения. В случае
прерывания такого соединения как по причине сбоя, так и вследствие
запланированного отключения (что особенно вероятно, если монитор и
главная консоль отделены друг от друга глобальной сетью WAN), будет
наблюдаться разрыв связи между главной консолью и наблюдаемым
устройством. Но использование файлов MIB для сбора данных означает,
что удаленная система может быть сконфигурирована для сбора своих
данных даже в случае, если она не находится в данный момент в контакте
с главной консолью.
Примечание
Поскольку состояние сети можно отслеживать из разных мест, RMON поддерживает средства передачи данных на несколько консолей
Протокол RMON можно использовать для осуществления непрерывной
диагностики неисправностей, сбора информации, не отслеживаемой в
данный момент, с целью ее последующего использования. Даже если сеть
начинает отказывать, удаленный монитор будет записывать все параметры
состояния системы, которые привели к возникновению проблемы —
вплоть до момента полного прекращения работы сети. Когда появится такая
возможность, с главной консоли можно будет просмотреть эту информацию
для идентификации условий, приведших к сбою в работе сети. Поддержи-
вающие RMON устройства могут также быть запрограммированы для
записи определенных параметров системы. Устройства будут постоянно
собирать информацию. Когда значения записываемых данных превысят
заданные границы, монитор может распознать проблему и уведомить об
этом главную консоль. Все эти данные весьма полезны, поскольку облег-
чают работу сетевого администратора. Чем больше данных вы можете
получить, тем легче будет изолировать проблему в случае, когда сервер
Internet (host), генерирующий большее число ошибок трафика, чем какой-
либо другой сервер, пришлет последнее сообщение и остановит работу
части сети.
Единственным недостатком RMON являются проблемы совместимости
с другими устройствами. RMON1 не полностью согласован, поскольку
отдельные производители добавляют различные новые средства к прото-
колу. Эти средства предоставляют расширенные возможности получения
информации с помощью протокола, однако, делают несовместимыми между
собой различные реализации RMON. Перед покупкой устройств RMON
удостоверьтесь, совместимы ли они друг с другом и можно ли контролиро-
вать их состояние с помощью ваших средств наблюдения.
Другие средства наблюдения за сетью
А что если вы не используете в своей сети протоколы SNMP или
RMON? Это не такая уж большая беда — есть и другие возможности. Вы
можете выбрать себе инструмент из поистине неисчерпаемого множества
средств управления. Два описываемых далее средства предназначены для
решения важных задач: отслеживание содержимого пакетов плюс выявление
и определение местонахождения разрывов кабелей.
Анализаторы
Анализатор (sniffer) (в сетях TCP/IP его также называют анализатором
пакетов (packet sniffer)) — это компьютер или устройство, которое отсле-
живает данные, перемещающиеся по сети, путем перехвата пакетов, которые
посылаются не только к ним самим. Такое функционирование называют
работой в смешанном режиме (promiscuous mode).
Примечание
Вы можете запускать программу-анализатор не в смешанном режиме, но в этом
случае вы будете способны только наблюдать за данными, посылаемыми в и из
машины, на которой запущен анализатор.
Анализаторы являются весьма популярными инструментами* взлома,
поскольку они способны читать содержимое закрытых пакетов. Они могут
также использоваться на законных основаниях для анализа данных сете-
вого трафика, в том числе различных типов широковещательной передачи,
пересылаемой через сеть, для определения компьютера, пославшего данные,
и по какому адресу, и т.д Это та самая информация, которая нужна для
эффективного руководства и проверки функционирования сети. Вам не
требуется читать всю информацию, поэтому вы можете устанавливать
фильтры для захвата только того трафика, который вы хотите увидеть.
Короче говоря, анализаторы один из методов отслеживания графика,
если ваша сеть не поддерживает RMON. Приложение Network Monitor
(Сетевой монитор) фирмы Microsoft, входящее в состав Windows NT,
является примером коммерческого анализатора. Имеются и другие анали-
заторы, как коммерческие, так и доступные на сетевых узлах с различной
степенью легитимности.
Доменные рефлектометры
Доменные рефлектометры (TDR — Time Domain Reflectometer) функцио-
нируют подобно локатору и позволяют вам определить все "узкие места" в
сети. Устройство выполняет широковещательную передачу сигнала, назы-
ваемого зондирующим импульсным сигналом (fast ri^e time pulse), распростра-
няемым по сети через регулярные интервалы, и ждет отраженного сигнала.
Промежуток времени, прошедший до момента получения отраженного
импульса, записывается и отображается в виде функции длины кабеля.
Допустим, по результатам аудита оборудования вы знаете, что данный
кабель имеет длину 20 футов (6м), а результаты теста TDR покажут длину
кабеля 15 футов. Это позволит вам определить наличие разрыва кабеля на
отметке 15 футов. Устройства TDR ранее использовались только для
проволочных соединений (коаксиальных кабелей и типа "витая пара"), но
теперь они стали доступными также и для оптоволоконных сетей (рис. 14.8).
Рис. 14.8. Доменные рефлектометры (TDR) посылают сигналы для
тестирования сети
Устройства TDR, мягко говоря, недешевы: TDR для проводных кабелей
стоят несколько тысяч долларов, а для оптоволоконных — 20 000 $ и выше.
Это может заставить вас подумать о применении других методов выявления
проблем с кабелями (см. следующую вставку), если только вы не работаете
с крупной сетью, что позволит оправдать такие расходы.
Ping - дешевый способ выявления разрывов сети
Если вы используете в своей сети протокол TCP/IP, вам не стоит
начинать поиск неисправностей в сетевых связях с применения устройства
TDR. Сначала попробуйте использовать всегда доступный программный
кабельный детектор, управляемый с помощью клавиатуры. В наборе средств
TCP/IP имеется диагностический инструмент "Ping", который просто
посылает пакеты по указанным адресам и ждет ответов, подтверждающих
прием пакетов в пунктах назначения. Если вы не можете подсоединиться
К какому-либо адресу, попытайтесь использовать указанную ниже проце-
дуру для сужения местонахождения неисправности.
1. В компьютере, который не может подсоединиться к другому компьютер введите ping 127 0.0 1 для отправки сообщения самому себе. Если эта процедура сработает, значит, компьютер подключен к сети и сетевая плата функционирует нормально.
2. Выполните тест Ping для стандартного шлюза вашего сегмента. Если это сработает,
значит, проблема лежит вне сегмента.
3. Запустите тест Ping для сервера DNS. Если сработает, значит, проблема заключается не в определении имен.
4. Выполните тест Ping для сервера Internet (host) в другом сегменте. Если сработает, значит, проблема не связана с протоколом TCP/IP.
И только после выявления вызвавшего несрабатывание сегмента восполь-
зуйтесь устройством TDR для нахождения обрыва, если вы подозревает
его наличие, но не можете обнаружить.
Тест Ping может выполнять и другие диагностические функции, например,
показывать время, затрачиваемое пакетом на прохождение определенного
расстояния, но эти возможности зависят от конкретной реализации
средств протокола TCP/IP. Поэкспериментируйте с ними для определения
существующих возможностей. Простейший Ping проще в эксплуатации
(и дешевле) приобретения специализированных аппаратных средств для
определения местонахождения разрывов кабеля.
Снижение расходов на администрирование
Как было показано ранее, снижение общей стоимости содержания
сети является весьма актуальной задачей. Там же говорилось о том, что
наибольшие расходы на содержание сети приходятся не на стоимость
оборудования, а на стоимость управления ею.
Реально можно выбрать одну из двух возможностей: продолжать
удаленную техническую поддержку или же установить программное обес-
печение удаленного управления на взаимодействующие компьютеры и
управлять компьютером на расстоянии. Последняя идея является
примером использования средств нулевого администрирования (zero
administration)
Примечание
Novell называет эти средства "организацией сети с нулевыми усилиями" (zero
effort networking), но слово "администрирование" кажется более содержательным,
поэтому мы будем использовать терминологию Microsoft даже при описании
средств фирмы Novell Оба названия звучат не слишком оптимистично (нулевое
администрирование7 Я думаю, вряд ли это возможно), но, по крайней мере,
указывают на попытку уменьшить время на поддержку клиентного компьютера в
работоспособном состоянии
Нулевое администрирование представляет собой не одну уникальную
концепцию, а целый набор инструментов и средств конфигурирования,
снижающих расходы на администрирование Суть идеи состоит в передаче
управления ПК от пользователя к администратору с целью'
• уменьшить количество запросов на предоставление помощи из-за
ошибок пользователя,
• централизовать загрузку приложений или сделать приложения доступ-
ными из любого узла сети;
• разрешить администратору управлять клиентными компьютерами
удаленно, загружать требуемое программное обеспечение или переза-
гружать их в случае необходимости.
Технические средства нулевого администрирования обычно применя-
ются в серверных операционных системах типа NetWare или Windows NT
Свойства программных продуктов, допускающих применение этих средств,
зависят от операционной системы Вообще, технология нулевого админи-
стрирования будет обеспечивать управление тем, что пользователь может и не может делать в операционной системе, включая указание на то, какие
программы пользователь может выполнять: установку приложений из
централизованного источника, удаленную инвентаризацию программного
и аппаратного обеспечения, операции удаленной диагностики.
В нулевом администрировании имеется важная особенность, требующая
осторожного обращения: для выполнения этой работы на стороне клиента
сначала следует получить его права на серверной стороне. По этой причине
все эти средства не выполняют настоящего нулевого администрирования:
чем более "неинтеллектуальны" ваши клиенты, тем более "интеллекту-
альным" должен быть ваш сервер. Поэтому при конфигурировании
серверной стороны с помощью средств нулевого администрирования
соблюдайте особую осторожность в работе и тщательно все проверьте,
прежде чем применить тот или иной программный продукт.
Продукт Z.E.N.works фирмы Novell
Предлагаемые фирмой Novell средства с нулевыми усилиями по адми-
нистрированию называются средствами ZEN (Zero Effort Networking —
организация сети с нулевыми усилиями) или, используя название соответ-
ствующего продукта, Z.E.N.works. Впервые они были предложены в мае
1998г. и представляют собой набор инструментов для передачи основной
части работы по администрированию с клиентной машины на сервер.
Клиентные компьютеры могут быть сконфигурированы автоматически с
помощью новых и обновленных старых приложений, загружаемых клиен-
тами. Эти приложения распространяются по сети, так что они вовсе не
обязательно должны быть инсталлированы на единственном сервере.
Вместо этого, когда клиент попытается обратиться к приложению, будет
задействован ближайший к клиенту сервер. Кроме того, все пользователь-
ские установки, процедуры и права системы защиты поддерживаются
средствами обслуживания каталога именно для того, чтобы они были
распределены по сети, а не хранились в одном-единственном месте.
Пока все эти средства весьма похожи на предлагаемые Microsoft средства
ZAW (описываемые ниже). В настоящее время они существенно отличаются
лишь добавкой, привнесенной в ноябре 1998 г. в Z.E.N.works. Версия 1.1
этого средства содержит поддержку режима удаленной диагностики аппа-
ратного и программного обеспечения для решения проблемы 2000 года.
Продукт ZAW фирмы Microsoft
Если вы не знакомы в достаточной степени с литературой по марке-
тингу фирмы Microsoft, то можете подумать, что продукт ZAW (Zero
Administration Windows — нулевое администрирование Windows) является
новым средством следующего поколения NT. Как раз наоборот. ZAW был
частью NT, пока не была реализована версия NT 4. Немного позже эти
средства превратились в сервер управления системами SMS (System
Management Server), предназначенный для поддержки системных правил и профилей пользователя, а летом 1997г. — в комплект инструментов нуле-
вого администрирования ZAK (Zero Administration Kit). Многие не видят
смысла в использовании именно таких средств операционной системы, но
это не вполне справедливо. Приведенные ниже сведения не являются
руководством по использованию Microsoft ZAW, но содержат суть идеи,
заложенной в эти инструментальные средства, которые можно использовать
для уменьшения времени и усилий, требуемых для администрирования
сети.
Правила и профили
Правила и профили являются ответами на один вопрос: как следует
организовать согласованную поддержку пользовательского интерфейса?
При неверном конфигурировании компьютеров возникает множество
проблем с отображением информации у пользователя, параметрами обору-
дования, установленным программным обеспечением или с другими
параметрами конфигурации. Поэтому, если хотите предохранить компью-
теры от некорректного конфигурирования, вы должны заблокировать
возможность конфигурирования в них чего бы то ни было пользователям,
или же не позволять внесенным изменениям становиться постоянными.
Примечание
Профили могут быть заданы или на клиентом компьютере (подразумевается, что в клиентном компьютере установлен жесткий диск), или загружены с сервера при входе пользователя в сеть Правила всегда помещаются на сервер - они просто не могут быть использованы в одноранговой сети. Этим сервером может быть как сервер NT, так и сервер NetWare - в зависимости от типа сети.
Профили пользователя. Профили содержат набор пользовательских
опций (установок), таких как параметры приложений, цветовые палитры,
хранители экрана и тому подобное. В компьютерах, работающих под
управлением Windows 95, профили являются набором данных, хранимых
в файле USER. DAT, используемом системным реестром (Registry) —
центральной базе данных всей информации о конфигурации системы.
Пользовательская информация не может быть загружена до тех пор, пока
- кто-либо не войдет в компьютер. По умолчанию профили всех пользовате-
лей одного компьютера в Windows 95 одинаковы. Итак, пусть один пользователь
войдет в компьютер, изменит цветовую схему со стандартной
(Windows Default) на Storm и выйдет. Когда в этот же компьютер войдет
другой пользователь, то увидит вместо стандартной цветовой схемы Windows
Default схему Storm. Тем не менее, если дать возможность второму пользователю изменить цветовую схему, то изменения, внесенные первым пользователем, будут потеряны.
Такой способ работы является стандартным: изменения в цветовой
схеме сохраняются в общем файле USER.DAT, и когда кто-либо входит в
компьютер, то загружается именно этот файл. Если же вы разрешите
применение пользовательских профилей, то для каждого пользователя,
вошедшего в компьютер, будет подготовлена пользовательская версия
файла USER.DAT. Когда Джо поменяет цветовую схему, то эти изменения
будут сохранены не в общем файле конфигурации, а в его персональном
файле {изменения конфигурации системы, сделанные одним пользователем,
не воздействуют на установки других). В сущности, пользовательские
профили ограничивают ущерб, который один человек может нанести
компьютеру, используемому многими людьми.
Примечание
Изменение профилей пользователя выполняется при его выходе из системы
Для радикального ограничения воздействий на компьютер любого
пользователя следует обязательно использовать профиль для каждого из них,
получаемый путем переименования файла USER.DAT в USER.MAN Он
предоставляет системе общедоступный набор пользовательских параметров.
При этом вы не сможете создать несколько обязательных профилей поль-
зователя для одной машины. Однако эти параметры доступны в режиме
"Только для чтения". Если Джо изменит цветовую схему в обязательном
пользовательском профиле и затем выйдет из системы, эти изменения не
появятся при входе в систему Тома. Так и Том может изменять свою
систему для текущего сеанса работы, но изменения не сохранятся при его
выходе.
Профили пользователя фактически представляют собой низкоуровневый
инструмент ZAW и применяются только по отношению к полному набору
параметров пользователя. Они не содержат параметры, "привязанные" к
компьютеру, и не ограничивают доступ к какому-либо инструменту
конфигурирования, например, к панели управления. Однако они уменьшают
расходы на поддержку функционирования сети, неизбежные в случае,
когда один пользователь приводит в беспорядок/параметры, установленные
другим пользователем. Если же вы хотите применить более тонкие средства
управления, то вам необходимо использовать системные правила, к описанию
которых мы и приступаем.
Системные правила. Позволяют при управлении рабочим столом
продвинуться на шаг дальше. Вместо предоставления или отмены разре-
шений на изменение набора параметров пользователя, они воздействуют
на определенные компоненты пользовательского интерфейса. К тому же
системные правила могут быть использованы для определения способа
конфигурирования самого компьютера. Параметры правил сохраняются на
центральном сервере в файлах с расширением .ро1 и могут быть загружены
клиентом при входе в систему.
Конфигурирование уровней пользовательского доступа к любым, в том
числе весьма тонким, деталям системной конфигурации, может потребовать
серьезных усилий, поэтому системные правила их не регламентируют.
Вместо этого вы можете явно разрешить или запретить доступ к средствам,
вызывающим у вас особое беспокойство, а остальную их часть оставить
доступными для определения параметров пользователя. Для того чтобы
системные правила работали, необходимо разрешить использование
профилей пользователя. Например, вы можете установить системные
правила, запрещающие совместное использование файлов, но разрешающие или запрещающие совместное использование принтеров (по выбору
пользователя).
Сервер управления системами (SMS)
Правила и профили предназначены для блокирования параметров
конфигурации с целью уменьшения вероятности проникновения в них
ошибок пользователя. Сервер управления системами SMS является более
прогрессивным средством администрирования, способным эффективно
контролировать содержимое каждого клиентного компьютера. Используя
сервер SMS, вы можете проводить удаленную инвентаризацию програм-
много и аппаратного обеспечения, устанавливать приложения или даже
операционную систему, а также перезагружать клиентный компьютер с
консоли SMS.
Комплект инструментов нулевого администрирования (ZAK)
Комплект инструментов нулевого администрирования (ZAK — Zero
Administration Kit) представляет собой надстройку Windows NT, доступную
для загрузки с Web-узла фирмы Microsoft. Эти средства расширяют идею,
заложенную в концепцию описанных выше правил и профилей, и предна-
значены для предоставления стандартного доступа (двух типов) к клиентным
компьютерам: станцию для задач и станцию для приложений. Комплект
ZAK устанавливается на клиентной машине (которая должна работать под
управлением Windows NT 4 Workstation или Windows 95/98) в одной из
двух указанных конфигураций.
Различие между этими конфигурациями заключается в количестве
приложений, к которым пользователь может получить доступ (конфигури-
рование системы не имеет к этому отношения). Режим TaskSheduler
(Планировщик заданий) предназначен для работы пользователей с проблем-
но-ориентированными средами. Таким пользователям, как правило, требу-
ется доступ всего к одному приложению (например, к системе управления
базой данных). Когда вы загружаете компьютер, сконфигурированный
таким образом, он загружается прямо в Internet Explorer или любое другое
предварительно указанное приложение. Рабочий стол будет полностью
заблокирован: пользователи не смогут использовать кнопку Start (Пуск),
приложение Task Manager (Диспетчер заданий), Control Panel (Панель
управления) или Explorer (Проводник Windows). Режим AppStation
(Станция приложений) предназначен для тех пользователей, которые рабо-
тают с тремя-четырьмя офисными приложениями, но не хотят (или не
могут) конфигурировать систему или устанавливать новые приложения.
При загрузке клиентного компьютера с помощью такого режима он сразу
же попадает в ограниченные администратором средства пользовательского
интерфейса, предоставляющие доступ только к требуемым приложениям.
Приложение Диспетчер заданий (Task Manager), Панель управления
(Control Panel) и Проводник (Explorer) при этом недоступны. Приложения
выполняются на сервере, а не на клиентной машине.
Новые средства ZAW
Некоторые функциональные средства ZAW уже реализованы в NT4
или в комплекте ZAK, а появление новых средств связано уже со следующим
поколением NT: Windows 2000 Server. Компоненты, имеющие отношение
к управлению сетями и не представленные в предыдущих версиях опера-
ционной системы, содержат следующие функции:
• автоматическое обновление системы и установка приложений с помощью
технологии IntelhMirror;
• унифицированный интерфейс консоли управления Microsoft (ММС -
Microsoft Management Console)
Конечно, Windows 2000 содержит средства поддержки и для доступных
в данное время средств ZAW Правила и профили предназначены для
облегчения работы по блокированию различных компонентов системы.
Установки станции задач (ZAK TaskStation) и станции приложений (ZAK
AppStation) будут доступными в Win2K для всех, кто не установил ZAK.
Сервер SMS 2 все еще будет поддерживать удаленное управление.
Автоматическое обновление и установка. Автоматическое обновление и
установка базируются на технологии IntelliMirror, в которой предусмотрена
загрузка данных клиенту без всяких запросов с его стороны с использо-
ванием предварительно заданного множества параметров. Именно так
работает броузер каналов. Цель применения такого рода средств для автома-
тизации обновления и установки приложений очевидна Пользователь не
должен знать, как выполняется установка Администратор не должен
входить в клиентный компьютер для выполнения установки.
Когда пользователи входят в сеть Windows 2000, центральный сервер
программ определяет версию клиентной операционной системы и с
помощью предварительно установленных разрешений пользователя и/или
администратора загружает все программы обновления на рабочий стол
клиента.
Консоль управления Microsoft (ММС — Microsoft Management Console).
Сама по себе не является инструментом, но предоставляет средства
внешнего интерфейса для базового комплекта инструментов NT и сменных
комплектов инструментов (snap-ins) различных производителей Они пред-
назначены для обеспечения централизованного управления сетью взамен
нынешней системы, в которой сначала делается что-то одно и закрывается
соответствующее управляющее приложение. Затем делается что-то другое
и снова закрывается это управляющее приложение. А затем делается что-то
третье и, наконец, закрывается и это управляющее приложение. Хотя
такая унифицированная консоль, как представляется, не лишена недос-
татков, она экономит время на получение доступа к инструментам из
централизованного источника.
Дополнительное программное обеспечение
Последнее замечание относительно ZAW касается не только прило-
жений. Одна из частей проекта ZAW посвящена созданию более простых в
управлении компьютеров. Его авторы отказались от сложных проектов
оборудования и предусмотрели взаимозаменяемость компьютерных
устройств.
Большая часть теоретического фундамента ZAW относится к тонким
клиентным системам, в которых функции клиентных ПК могут быть не
просто низведены до уровня терминалов, но могут и на самом деле пред-
ставлять собой терминалы. Устройства Net PC почти что "выбросили" из
себя компьютер. Они не имеют жесткого диска, а их корпус опечатан (это,
вероятно, не очень хорошее решение, поскольку усложняет их модерниза-
цию). Предполагается, что вам следует забыть об этом устройстве после
его включения, или же заменить его другим клиентным компьютером в
случае поломки.
Технология PnP (Plug and Play — Подключи и Работай) представляет
собой другую часть проекта ZAW, поскольку она уменьшает время на
установку оборудования. Соответствующим образом спроектированное
устройство PnP автоматически распознается при загрузке системы, что
значительно проще возни с адресами ввода/вывода и установками преры-
ваний. Мониторы стандарта DD2 и видеоплаты могут конфигурироваться
автоматически для установки оптимальных параметров отображения, так
что вам не придется об этом беспокоиться.
Средства диагностики неисправностей
В хорошо ли, плохо ли документированной, в удаленно управляемой
или нет, но рано или поздно в какой-то части локальной сети произойдет
сбой. Часто наиболее сложной частью работы с локальной сетью является
не само восстановление работоспособности, а выявление и определение
компонента, вызвавшего нарушение. С этой точки зрения от вас требуется:
• знать свою сеть и все относящиеся к ней данные;
• уметь локализовать неисправности, возникающие в сети;
• иметь доступ к данным отчетов по ранее возникавшим неисправностям, чтобы вам не пришлось повторно решать одни и те же задачи.
Читайте дальше, чтобы познакомиться с информацией по выявлению
неисправностей в сети и их исправлению.
Web могущественнее, чем TDR
Наилучшим инструментом в вашем арсенале средств диагностики
неисправностей должна быть не дорогостоящая аппаратура, а информация.
В этой лекции много места отводится описанию методов сбора информации о
вашей сети и данных. Если по мере изучения материала вы следовали предла-
гаемым здесь советам (вряд ли так получалось всегда, но, быть может, вы
все же пытались собрать некоторые данные о сети), то сейчас у вас должна
быть информация о поведении сети, ее структуре, организации ресурсов
и т.п.
Источники диагностической информации
Ваша сеть сама по себе может предоставить вам только часть требуемых
данных. Эти данные расскажут о характерных особенностях вашей сети,
структуре графика, оборудовании и т.д. Другую часть информации предос-
тавят внешние данные. Следует знать, что происходит в вашей сети, а
также вам необходимо определить характеристики аппаратных и програм-
мных средств, которые должны работать в сети совместно.
Текущая поддержка. Наиболее актуальную информацию по интере-
сующим вас операционным системам и оборудованию, вероятно, можно
найти в бюллетенях с перечнями отдельных вопросов. Используя такую
книгу в качестве онлайнового руководства, можно получить некоторые
советы, а также просмотреть и другие бюллетени.
Предупреждение
Учтите, что все прочитанное в переговорной комнате, онлайновом форуме и
пользовательском списке рассылки отнюдь не обязательно соответствует дейст-
вительности. Некоторые их авторы и в самом деле являются опытными специа-
листами, но вы не должны заранее считать всех, кто ответил на ваш вопрос,
экспертами.
Другими источниками текущей информации являются бюллетени,
выпускаемые производителями продуктов, которые или рассылаются по
электронной почте, или находятся на Web-узлах компаний.
Примечание
Не совсем актуальным, но значительно более упорядоченным источником
информации является ежемесячная подписка на компакт-диски, например,
TechNet фирмы Microsoft, содержащие "Белую книгу" в виде поисковой базы
данных, информацию по исправлению повреждений и другие технические данные.
Кое-кто находит также полезными группы новостей, но соотношение
полезная/бесполезная в группах новостей самое низкое. Одна половина
графика групп технических новостей состоит из тематических заголовков
типа "Делай деньги сейчас!". Другая половина — обычно не упорядочена и
не обязательно имеет отношение к основной теме. Существуют различные
онлайновые хранилища информации, совместно используемые профес-
сионалами. Просмотрите упомянутый список рассылки, дискуссионные
форумы или переговорные комнаты, присоединенные к Web-узлу (рис. 14.9).
Рис. 14.9. Откажитесь от бесполезной информации в группах новостей форумов Web
Сбор справочной информации. Самая актуальная информация не всегда
популярна. Для более глубокого ознакомления читайте отраслевые издания.
Еженедельные выпуски приносят новости или отдельные мнения, техни-
ческие же детали обычно приберегают для месячных изданий. Хотя
журналы не так оперативны, как рассылаемые по электронной почте
бюллетени, но они содержат справочную информацию, которой нет в
списках рассылки или в других местах хранения информации. Журналы
могут быть прекрасными учебными пособиями, советами по отдельным
проблемам и рекомендациями по применению нового оборудования.
Читайте также отраслевые издания с обзорами по конкретной продукции.
Обзоры могут содержать комментарии по неисправностям, с которыми
пользователь встретился при работе с этим продуктом, и методы поиска
неисправностей.
Книги вряд ли предоставят вам ультрасовременную информацию по
сравнению с бюллетенями или журналами, поскольку на их публикацию
требуется время. Однако они могут быть прекрасным руководством по уже
известным (и изученным) проблемам и источником справочной информации,
который поможет вам решить собственную проблему или же подаст идеи
для поиска дополнительной информации.
Поддержание знаний на современном уровне
Всякий, кто попытается сориентироваться в водопаде информации
по новым технологиям, вероятно, может немного испугаться, подумав
"Я никогда не смогу полностью познакомиться со всем этим!". И он будет
прав. Нет никого, кто был бы экспертом по всем вопросам. Самое большее,
на что мы можем рассчитывать, так это на то, что станем достаточно
образованными специалистами, знающими, где можно найти ответы на
поставленные вопросы.
Вы можете более эффективно управлять потоком информации, используя
различные тактики. Во-первых, подберите себе источники, которые помогут
вам в наибольшей степени, и постарайтесь как можно лучше ознакомиться
с их содержимым. Ведь если какая-либо информация была напечатана, это
вовсе не означает, что она полезна для вас или требуется вам для дела.
Microsoft, например, в течение года выпустила сотни статей с базами
знаний, посвященными известным проблемам. Большинство из нас не нашло
нужным прочитать 90 процентов этих статей, поскольку все они применимы
только для отдельной модели сетевой платы или для неиспользуемых нами
приложений. Ищите статьи, которые содержат только интересующие вас
ключевые слова (см. следующую вставку).
Советы по онлайновому поиску
При сортировке онлайновых изданий лучше всего ознакомиться с уже
имеющимися средствами поиска в базах данных. Многие основные меха-
низмы поиска по узлам сети и в Web содержат средства поддержки логиче-
ских операций (Boolean coding), которые впервые появились в булевой
алгебре, созданной в девятнадцатом веке английским математиком
Джорджем Булем (George Boole). Они облегчают объединение различных
ключевых слов, необходимых для точного указания интересующего вас
документа (рис.14.10а,б,в).
Для поиска документов, содержащих все слова, по которым вы произ-
водите поиск, но не какую-то их часть или в каком либо отношении с
другими словами, используйте оператор AND. Например, запрос SCSI
AND NT возвратит документы, включающие оба слова (наличие "AND"
обычно подразумевается по умолчанию). Это значит, что если в окно
механизма поиска со средствами работы с логическими операторами вы
введете SCSI NT, то компьютер будет искать документы, содержащие
оба слова.
Рис.14.10 а. SCSI AND NT
для поиска документов с любым из интересующих вас словом исполь-
зуйте оператор OR. Например, поиск по запросу SCSI OR NT возвратит
все документы, содержащие хотя бы одно из этих слов. Этот оператор
используется реже, поскольку обычно возвращает слишком много ответной информации.
Рис.14.10 б. SCSI OR NT
Пусть вам требуется найти документ, не содержащий отдельных слов. Например, если вам нужно найти все документы, в которых есть термин SCSI, и нет термина NT, вы должны использовать оператор NOT, например, так: SCSI NOT NT. Оператор NOT полезен для
сужения области поиска, если вы считаете, что она может быть обширной.
Рис.14.10 в. SCSI NOT NT
Для нахождения документа, содержащего одно или другое слово, но не
оба вместе, используйте оператор XOR. Например, запрос SCSI XOR NT
возвратит все документы, в которых есть какое-либо из этих слов, но нет
этих слов вместе. Оператор XOR напоминает оператор OR, но позволяет
исключить все документы, содержащие оба слова. Обычно он расширяет диапазон поиска, если не используются иные операторы.
Рис.1410 г. SCSI XOR NT
Логические механизмы поиска могут поддерживать два дополнительных
оператора, не входящих в состав операторов булевой алгебры: NEAR и
кавычки. Оператор NEAR работает аналогично оператору AND, за исклю-
чением того, что он производит поиск экземпляров слов, находящихся в
тексте друг от друга на некотором расстоянии. Например, запрос SCSI
NEAR NT должен возвращать список всех документов, в которых SCSI и
NT находятся друг от друга на расстоянии не более восьми слов, игнорируя
все документы, в которых появляются оба слова, но на большем расстоянии
друг от друга.
Кавычки используются для определения строки поиска, состоящей из
нескольких слов. Большинство механизмов при выполнении поиска по
строке Windows NT возвратит все документы с Windows и NT — не только
экземпляры, содержащие "Windows NT", но и фразы типа "Windows 3.1 is
a predecessor of NT" (Windows 3.1 является предшественником NT). Если
вы хотите, чтобы механизмы поиска возвращали только документы, в
которых оба эти слова появлялись точно такими, как в строке, необходимо
использовать кавычки вокруг этой строки, например, "Windows NT".
Операторы в этих примерах очень просты. В каждом из них исполь-
зуется всего два слова и один операнд. Однако запросы могут состоять из
нескольких слов и множества операторов, если это необходимо. Например,
запрос SCSI AND NT NOT network будет возвращать все документы,
содержащие слова SCSI и NT, но не слово "network".
Во-вторых, общайтесь друг с другом с целью обмена информацией.
Очень полезно использовать списки адресов и онлайновых форумов — ведь
если вы чего-то не знаете, то другие могут это знать. Вы можете вернуть
оказанную вам любезность, когда кто-либо спросит у вас нечто, прозву-
чавшее для вас пустяковым вопросом, но ставшее причиной двухдневного
кошмара для спросившего.
Исправления и обновления
Как вы относитесь к обновлению не только вашего электронного
"мозга", но и программного обеспечения? Не бывает программного обес-
печения — драйверов, приложений или операционных систем — которое
можно считать "готовым". Производители часто предоставляют исправления
или усовершенствования для своих продуктов в виде новых драйверов и
оперативных исправлений (hotfix) для решения какой-либо конкретной
проблемы, или же в виде служебных пакетов (Service Pack), предназна-
ченных для решения нескольких проблем, которые могут содержать
некоторые дополнительные средства, не входящие в исходный продукт.
Знакомство с этими обновлениями является основным способом поддержки
знаний об оборудовании и программах на современном уровне. Большая
часть обновлений доступна на Web- или FTP-узлах соответствующих
производителей или на подписных компакт-дисках, например, TechNet.
Вам следует ознакомиться со всеми этими обновлениями, но вовсе не
обязательно тотчас же их устанавливать. Во-первых, не вносите исправления,
если у вас нет достаточного опыта в решении тех проблем, которые эти
исправления должны откорректировать.
Во-вторых, если вы решили внести оперативное исправление или уста-
новить служебный пакет, сначала удостоверьтесь, что это обновление не
приведет к усугублению проблемы и вы сможете восстановить состояние
системы, существовавшее до обновления, если это понадобится. (Всякий,
кто помнит имеющий дурную репутацию служебный пакет Service Pack 2
для Windows NT 4, поймет, почему это важно. В двух словах эта длинная
история сводится к описанию тяжелого труда многих людей по восстанов-
лению резервных копий их систем после установки SP2, поскольку это
обновление испортило все текущие установки.) Следует очень внимательно
следить за системой в течение одной-двух недель после обновления.
Познакомьтесь с мнениями других пользователей, приведенными в бюлле-
тенях производителей, о возникающих при этом проблемах или послушайте,
что говорят производители, когда им звонят по телефону и сообщают о
какой-то проблеме. Если можно, самостоятельно протестируйте результи-
рующую программу на компьютере, которая может быть повреждена без
дополнительного вреда для окружающих. В общем, делайте все, что только
можно, чтобы обновление было вам полезным.
Даже если программы обновления не нанесут вреда, иногда они не
представляют собой завершенного продукта и не полностью устраняют
проблемы, для решения которых предназначены, и похожи на типичную
программу, сопровождаемую таким "советом": "Фирма Microsoft настоя-
тельно рекомендует всем заинтересованным заказчикам, включая тех, кто
загрузил исходное исправление перед 18 ноября, загрузить и установить
обновленное исправление для защиты своих компьютеров".
Очевидно, можно найти себе лучшее занятие, чем дважды загружать и
устанавливать исправления для одной и той же программы на свою систему.
Если вы хотите использовать все функциональные возможности данного
обновления программного обеспечения, то установите его немедленно.
В противном случае подождите с установкой, как минимум, несколько дней.
Несмотря ни на что, создайте резервную копию всех данных и информации
о конфигурации системы перед установкой какого-либо обновления. При
этом в случае какой-либо аварии вы сможете, по крайней мере, восстано-
вить работоспособность системы в прежней конфигурации.
Обращение в службу поддержки
Залогом успешной диагностики неисправностей является справочная
информация, помогающая вам отслеживать неисправности, и содержащая
рецепты для их поиска. Если ее нет, вам ничто не сможет помочь, и
придется потратить большее количество времени на получение данных о
неисправности, нежели на ее устранение. В этом разделе рассматривается
важность документирования обращений в службу поддержки и описыва-
ются два способа успешного решения этой задачи.
Одним из наибольших благодеяний, которые вы можете сделать для
себя — это завести журнал аварийных вызовов, нарушений работоспособности
и их устранения. Частично поводом для этого служит инстинкт самосо-
хранения: отслеживание вызовов документально фиксирует ваш вклад в
работу организации. Также это неплохой повод продемонстрировать необ-
ходимость приобретения дополнительного оборудования или приема на
работу персонала, или же возможность наглядно доказать, что сделанные
изменения привели к разрушению сети. Если вы будете в состоянии доку-
ментально показать, что количество обращений в службу поддержки
"взлетело до небес" после того, как в одной части сети были сделаны
изменения, то вы сможете предотвратить распространение этих изменений
по всей остальной части сети до их отменены.
Другой повод заключается в предупреждении или устранении нару-
шений проблем путем отслеживания уже замеченных. Это может касаться
отдельных индивидуумов ("Мистер Х звонил нам по причине отсутствия
доступа к принтеру") или отдельных ситуаций ("Мы можем ожидать вызовов
по поводу файлов, называемых 'Y', от всех пользователей WordPerfect").
Справочная информация такого сорта может быть полезна при обучении
новых специалистов службы поддержки или сетевых администраторов.
Итак, вам требуется записывать на бумаге или (как это делаю я) в файле
все обращения в службы поддержки. Отчет о каждой неисправности
должен содержать следующую информацию.
• Идентификационный номер (ID) отчета о неисправности.
• Предварительная информация.
• Кто сообщил о возникновении неисправности?
• Когда поступило сообщение о неисправности?
• Каким образом поступило сообщение (электронная почта, телефон, устно)?
• Связано ли это с предыдущими аварийными вызовами?
• Откуда было отправлено сообщение о неисправности?
• Какова специфика жалобы?
• Воспроизводима ли такая неисправность? Способен ли ваш клиент/сотрудник воспроизвести ситуацию у вас перед глазами?
• Когда это впервые проявилось?
• Что необычное происходило непосредственно перед и сразу после появления неисправности?
• Случается ли это периодически? С какой периодичностью?
• Информация об узле сети.
• Комментарии по поводу окружающей ПК среды: электропитание, температура, другие.
• Результаты обследования неисправности.
• Действия, производившиеся на узле.
• Информация о проведенных ремонтах ПК (если таковые выполнялись).
• Даты выполнения ремонтов?
• Какие работы были выполнены?
• Каковы результаты проведенных работ?
• Был ли компьютер возвращен клиенту/сотруднику? Когда?
• Итоговая информация/ключевые слова.
• Связана ли эта проблема с оборудованием или программным обеспечением,
и/или с пользователем?
• Если с программным обеспечением, то с каким именно пакетом (пакетами)?
• Если с оборудованием, то с каким именно устройством (устройствами)?
Совет
Для решения типичных проблем предусмотрите создание системы FAQ, сообщения которой пользователь сможет просматривать перед началом работы. Эти средства могут быть использованы персоналом службы поддержки, особенно новыми сотрудниками.
Разделяй и властвуй
Итак, вы получили нужную информацию по состоянию сети и уверены,
что используете современную технологию. Вы разработали базу данных
известных вам сведений. Что же осталось?
Ну что ж, теперь самое время начать устранять неисправность в сети.
Нашел причину неисправности - исправь ее
Принцип разделения и властвования включает в себя два аспекта.
Первый, достаточно очевидный, состоит в выявлении места неисправности.
Находится ли она в сети? Где? В каком сегменте? Или неисправность
возникла на сервере, скажем, в его памяти, в процессоре, в жестком диске?
Вторым, менее очевидным, аспектом является определение неисправности.
У вас больше шансов обнаружить ее, если кто-либо сообщит вам о ней,
нежели в ходе обычной проверки. После получения такого сообщение ваша
работа будет заключаться в детализации полученной информации, чтобы
вы могли изолировать реально возникшее нарушение работоспособности.
Вы не уловили разницы между этими двумя задачами? Например, если
кто-то обратится к вам и сообщит, что он не может получить
свою электронную почту, фактически вы не будете знать, где именно
возникла проблема. Без дополнительной информации вы не сможете
определить, что же случилось — то ли кто-то не может получить доступ к
сети, то ли не может войти в почтовый сервер, то ли не может найти
почтовое клиентное приложение, или (что бывает с несобранными людьми)
она просто не может загрузить свой компьютер.
Когда вы услышите звонок и снимете трубку, сначала постарайтесь
добыть побольше информации о случившемся, а затем последовательно
обойдите весь офис, пытаясь отследить, насколько это возможно, источник
проблемы. Это нетрудно сделать, а результаты будут весьма продуктивными.
В заключение дадим вам пару советов по сбору информации: если вы
не знаете, в чем состоит проблема и как ее можно решить, не советуем
вам что-либо делать и высказывать "конфиденциальные" предположения.
Во-первых, это будет раздражать пользователей, если ваш совет не приведет
к успеху, поскольку они должны будут повторить свой вызов. Один ответ:
"Я пока не знаю, в чем тут дело, и позвоню вам через час после изучения
проблемы", — стоит дороже шести советов типа: "Проблема заключается в
Х — делайте Y. Не получилось? Не работает? Попытайтесь сделать Z. Тоже
не работает? Попытайтесь сделать А". Ведь если вы и в самом деле ответите
на вопрос, первый из указанных выше ответов сохранит конфиденциальность.
А второй — нарушит ее.
Во-вторых, если вы составляете предварительный отчет о возникшей
проблеме, то перенесите свои усилия с решения проблемы в сторону
обеспечения своих прав. Неважно, были ли вы правы с самого начала, или
нет ~ пользователи простят ошибки, если вы все-таки сможете исправить
проблему.
Выявление затруднений
Ну, хорошо, вы составили более детальное описание ситуации. Теперь
следует отследить причину ее возникновения. Спросите себя:
• Кто страдает от этой неисправности? Один человек, рабочая группа, домен, сегмент или вся сеть?
• Какие действия привели к возникновению нарушения? Что пользователь
пытался сделать, и из-за чего возникло нарушение? Возникает эта
ситуация лишь при одном-единственном сочетании обстоятельств или
проявляется в различное время? Прослеживается ли здесь какая-либо
тенденция?
• Возникала ли эта неисправность ранее? Что было ее причиной, как она была разрешена?
• Какое различие между вчерашним днем (или каким-то другим, когда
нарушения еще не было) и сегодняшним (или тем, в который неис-
правность возникла).
Короче говоря, вы должны подумать, выявить тенденции и найти
примеры подобных случаев.
Подготовка к изменениям
Даже оптимально управляемая и максимально свободная от аварий
сеть, в конце концов, должна подвергнуться изменениям. Со временем
появляются новое оборудование, новые приложения или новые версии
уже существующих приложений, да и сами компании претерпевают изме-
нения. Рано или поздно вы будете вынуждены делать большие или малень-
кие изменения в сети. Ваша задача состоит в максимально возможном
упрощении этой работы. Для этого вы должны слить воедино все свое техническое мастерство с тактичностью дипломата. Однако заметим, что
работа дипломата состоит отнюдь не в хождении вокруг да около, а,
наоборот, в умении идти своим путем, чтобы другие участники процесса
общения относились к этому с пониманием.
В дальнейшем описании некоторая часть сеансов сетевого планирования
отделена от других, и, начиная с описания переходов на новое оборудование
или программное обеспечение, изложение будет более подробным. Переход
на новое оборудование или программное обеспечение почти всегда выпол-
няется одинаково.
1. Определяются требования к новой системе.
2. Планируются компоновки (аппаратная или программная).
3. Тестируется новая система, и устраняются возникшие нарушения работоспособности.
4. Реализуется новая система.
5. Осуществляется обратная связь с пользователями.
Рассмотрим все эти вопросы более детально.
Анализ требований к системе
Первым шагом при планировании изменений сети должно быть опре-
деление новых средств решения текущих и будущих задач. Необходимо
отыскать новую технологию или продукт, которые смогут принести пользу
системе. Как мне представляется, наиболее правильный подход заключается
в использовании принципа: "Как бы нам облегчить себе жизнь?", — вместо: "Это что-то новенькое. Как бы нам включить это средство в сеть?".
Подготовка с помощью регулярных совещаний
С целью выполнения анализа многие компании, особенно крупные,
проводят регулярные совещания в сети. В процессе этих совещаний они
оценивают сетевую производительность, удовлетворенность пользователей
работой системы и т.п. Если стала доступной новая технология, то, значит,
пора кратко сообщить об этом сотрудникам. На таких совещаниях должен
присутствовать не только управленческий персонал (MIS staff) — это
совещания управляющих с участием пользователей и обслуживающего
персонала, вносящих предложения о том, что им требуется и что для этого
можно сделать. Точное число участников зависит, конечно, от размеров
компании. В одной компании в совещании могут участвовать 8—10 человек
(надеемся, у вас их будет не больше, иначе вы ничего толком не сможете
сделать). В другой — вы встретите трех, каждый из которых является
"единым во многих лицах" специалистом. Как бы то ни было, на совещаниях
должны быть представители:
• сетевых администраторов;
• администрации здания;
• группы обслуживания оборудования;
• группы поддержки программного обеспечения;
• персонала поддержки сети;
• пользователей.
Совет
Чем меньше число участников сетевых совещаний, тем более вероятно, что вам
удастся сделать что-нибудь полезное Если некоторые участники нужны лишь
"постольку поскольку", предоставьте им возможность выступить в качестве гостей
и сделать доклад по вопросам, относящимся к их компетенции.
Описанные выше обращения в службы поддержки, отслеживаемые
вами, являются одним из источников информации о пользовательских
требованиях. Если вы зафиксировали множество звонков по поводу отдель-
ного текстового процессора, а по вашим данным имеется новая версия
сервисного пакета, исправляющая недостатки текущей версии, значит,
настало время приобрести новую версию текстового процессора. Или,
если вы получаете множество нареканий на плохую реакцию системы при
запуске программ под Windows в режиме эмуляции, то вам следует поме-
нять операционную систему на ту, которая поддерживает уже используемые
приложения.
Другим потенциальным источником информации являются отзывы
пользователей о работе системы и список их потребностей. Это одна из
причин, по которой необходим представитель пользователей. Такой человек
не всегда является представителем всех пользователей, но мнение людей,
использующих сеть, о тех средствах, которые могут облегчить им жизнь,
вероятно, имеет большое значение даже в том случае, если их взгляды
будут не очень четко сформулированы.
Предложите пользователям ввести данные
Если вы планируете внести большие изменения, о них следует расска-
зать пользователям сети, чтобы узнать, какие приложения им нужны для
выполнения своей работы и какая необходима образовательная подготовка.
Ниже приведен пример списка вопросов, используемого для опроса, про-
веденного накануне перехода правительственной организации с рабочих
станций UNIX на Windows NT.
1. Поскольку мы собираемся покупать инструментальные средства MS Office Suite,
отметьте все перечисленные ниже приложения, которые вам понадобятся при
переходе на новую систему NT. Если возможно, перечислите версии, которые вы
используете в настоящее время.
Applix Mail;
Applix Spreadsheet;
Applix Word;
Corel Draw;
Corel Presentation;
Frame Maker;
PhotoShop;
WordPerfect.
Примечание
Это всего лишь пример. Конкретные пункты этого списка не имеют значения.
Здесь вы должны главным образом постараться получить ответ на вопрос "Если
ваш компьютер завтра исчезнет, какие приложения потребуется восстановить,
чтобы вы могли продолжать работу?"
2. Требуется ли вам программное обеспечение, не приведенное в списке п.1?
3. Нужен ли вам какой-либо макрос для конвертирования старых файлов?
4. Требуют ли ваши заказчики сохранения файлов в определенном формате?
5. Какие средства интерфейса с базой данных вам необходимы для перехода на новую операционную систему?
6. Какая подготовка вам потребуется? Укажите, пожалуйста, ваш уровень знаний по
данному вопросу.
7. Имеются ли у вас какие-либо дополнительные комментарии или замечания относительно перехода?
Когда вы будете приглашать пользователей ввести данные, помните о следующем. Во-первых, то, что кто-то затребовал определенные средства, вовсе не означает, что их следует предоставить. В данном частном примере пара пользователей из одного подразделения захотели получить программное обеспечение для моделирования трехмерной графики. Они не имели его на момент обследования, и характер их работы не предусматривал каких-либо задач, требующих программного обеспечения для моделирования трехмерной графики. Но они потребовали его, поскольку знали, как его
можно использовать (данный запрос был отвергнут).
Во-вторых, это связано с первым: введенная пользователем информация
носит исключительно рекомендательный характер, так что и вы (человек,
проводящий опрос), и пользователь должны это понимать. Каждый раз
при изменении части сети вы будете как приобретать какие-то преимуще-
ства, так и терять некоторые из них. Если вы попытаетесь придерживаться
нереального замысла, позволяющего пользователям диктовать основные
принципы организации сети, то добьетесь лишь появления множества
обиженных, так как сеть или приложение не будут нормально работать.
Помните: достижение состояния работоспособности и эффективной
управляемости сети являются итогом работы всей команды. Хотя вы и
вносите изменения, облегчающие жизнь всем пользователям, за принятые
решения отвечаете только вы. Иногда требуется принимать компромиссные
решения, ухудшая одни параметры за счет других.
Планирование инфраструктуры сети
После того как вы выяснили запросы пользователей сети, и у вас
появились какие-то идеи относительно технологии, которая может удов-
летворить этим требованиям, приходит время складывать воедино все
компоненты сетевой инфраструктуры. Для этого необходимо ответить на
несколько вопросов, которые могут меняться в зависимости от природы
выполняемых в сети изменений, но чаще всего вопросы выглядят следующим
образом.
• Работа каких приложений должна поддерживаться в сети?
• Кому необходим доступ к этим приложениям?
• Какие возможности управления своими компьютерами могут (должны) получить пользователи?
• В какой степени должны быть защищены данные?
• С какими другими сетями вам требуется организовать связь?
• Какое оборудование необходимо поддерживать? Какое должно быть заменено? Какое добавить?
• В каком направлении будет далее развиваться сеть? Можем ли мы
определить свои потребности, нереальные сейчас, но доступные через
год или два?
На основе ответов на эти вопросы вы можете выбрать оборудование и
программное обеспечение, и их конфигурацию, обеспечивающую эти
потребности. Если вы в состоянии быть в курсе всех технологических
новинок ("Смотрите, про это приложение я недавно читал в отраслевом
издании!"), то поиск инструментов, которые соответствуют вашим запросам
и годятся для совместного использования, не будет слишком сложен и
продолжителен. Для решения проблем, выходящих за рамки вашей
компетенции, вам может потребоваться некоторое время на поиск самых
последних предложений или прибегнуть к посторонней помощи.
Совет
Не забывайте о сетевом взаимодействии, когда планируете инфраструктуру своей сети. Львиная доля проблем возникает из-за того, что эта часть сети не взаимодействует с другой. Сэкономьте себе время и определите части сети, которые могут взаимодействовать друг с другом или это можно сделать в будущем
Одна из задач планирования инфраструктуры — обучение клиентов
работе с новыми компонентами сети. Это не всегда необходимо — если вы
установите новую серверную операционную систему, то пользовательский
интерфейс может вообще не измениться Однако если каких-либо пользо-
вателей необходимо обучать работе с новыми приложениям, сейчас для
этого самое время.
Тестирование компонентов
Итак, вы уже подобрали компоненты для своей сети и даже знаете, как
сложить их вместе. Установите же их! Изменения будут сделаны, и вы
спокойно начнете работать с завтрашнего утра!
Но, быть может, лучше сначала удостовериться, что эти изменения
работоспособны, перед тем как вносить их в уже функционирующую сеть?
Успешная установка — это протестированная установка. Характер
тестирования зависит от объема сделанных изменений, ресурсов компании,
которые могут быть отведены для тестирования, и, возможно, от опыта
клиентов, но тестирование является обычной составной частью процесса
модернизации сети. И для этого имеются веские основания. Если вы не
протестируете изменения, то сможете лишь теоретически предполагать, что
все работает нормально, и не будете знать, как это работает на самом деле.
Для проверки безопасности внесенных изменений в сети вы можете
сначала выполнить их в лабораторных условиях, если у вас, конечно,
имеются таковые. Лабораторное тестирование фактически и будет предва-
рительным тестированием. Во время его выполнения вы сможете экспери-
ментально выбрать наилучший способ установки изменений, попробовать
различные конфигурации и, вообще, поработать с системой для достижения
наибольшей производительности, не беспокоясь о том, что ваши действия
скажутся на пользователях. Загрузку данных можно сымитировать с помощью
автоматических генераторов пакетов, так что можно будет легко определить,
как ваша сеть работает в критических условиях, не привлекая для этого
"живых" пользователей. Лабораторное тестирование также является
подходящим случаем для обнаружения конфликтов при взаимодействии
сетей, так что вы сможете разрешить их заранее, не причиняя беспокойства
кому-либо, кроме персонала подразделения IS (Information Systems).
Совет
Вы можете подсоединить компьютеры лаборатории к основной сети, если объе-
дините их в собственный сегмент, подключаемый с помощью повторителя,
маршрутизатора или моста. В этом случае проблемы в лабораторной сети не будут воздействовать на остальную сеть, но вы сможете получить любую нужную вам информацию, доступную по сети.
Животные, живущие в зоопарке, не ведут себя как звери, живущие на
воле. Лабораторная сеть не всегда ведет себя так, как "живая". Серьезным
испытанием стабильности изменений является работа в производственных
условиях, иначе вам трудно будет судить, как сеть поведет себя в пиковых
ситуациях на протяжении рабочего дня. Вы сможете перейти в рабочий
режим (не преодолевая одним прыжком всю дистанцию, разделяющую
лабораторные испытания и реализацию этих изменений во всей сети)
несколькими способами.
Если изменения фактически являются включением в сеть нового
элемента (или если сеть сама только что создана), вы можете организовать
тестовый узел. На тестовом узле эти изменения должны быть реализованы
так же, как если бы они были внесены в сеть и использовались в обычном режиме. Результаты работы тестового узла могут быть зафиксированы и
оценены. Если необходимо сделать какие-либо дополнительные изменения,
вы можете внести их и опробовать на тестовом узле. После того как сеть
будет готова и начнет работать на тестовом узле, вы можете распространить
изменения на другие узлы.
Если тестирование отдельных узлов невозможно, вы можете ограничить
область внесения изменений одним тестовым сегментом или тестовой
группой в зависимости от того, имеет ли изменение логическую или физи-
ческую природу, или же обе сразу. К тому же, если внесенные локально
изменения работают так, как ожидается, то вы можете распространить их
по всей сети. Однако учтите, что такому тестированию подвергается только
ограниченная часть всей сети, что позволяет вам найти и изолировать
нарушения, когда они воздействуют еще на ограниченное количество
пользователей
Третий подход к тестированию состоит в постепенном наращивании
изменений, т.е. в частичном добавлении изменений в сеть. Такой способ
реализации может потребовать некоторых дополнительных усилий, но он
позволяет изолировать компоненты сети, а не пользователей. В этом случае,
если установленный компонент не работает, вы сможете легко выявить
причину, поскольку новые элементы вводятся по одному за один раз, а не
сразу всей группой.
Эти методы тестирования не исключают друг друга — вне всякого
сомнения, их можно комбинировать. Можно придумать и свои, новые
способы тестирования сети. Однако, независимо от используемого метода,
принципы остаются неизменными: ограничение отрицательных последствий
до тех пор, пока вы не удостоверитесь, что сеть работает так, как ожидалось.
Значительно проще удалить неисправность в малом масштабе и затем
реализовать такое изменение во всей сети, чем исправлять нарушение
работоспособности всей крупной и сложной сети.
Реализация сети
Итак, наконец-то вы готовы применить (и сохранить) сделанные
изменения. Если это возможно, завершите выполнение этой задачи или
где-нибудь в стороне от большинства клиентов сети, или тогда, когда все
они отсутствуют (предусмотрите достаточный резерв времени) Внесение
изменений, как правило, занимает больше времени, чем мы предполагаем,
и если вы будете ограничены во времени, то, скорее всего, начнете
нервничать и пропускать отдельные действия, что может привести к
возникновению новых проблем.
Даже если вы заранее протестировали все изменения, следует подождать
некоторое время, чтобы "сгладились" все неисправности, которые не
проявились до полномасштабной их реализации. Однако если вы протес-
тировали все достаточно тщательно, то можете ожидать уменьшения
количества неисправностей.
Выводы
Как уже было сказано, объединение компонентов сети в единое целое
часто представляется сравнительно легкой задачей. Самое тяжелое время
настанет, когда пользователям потребуется поработать с какими-то средст-
вами, и вы должны будете или исправлять результаты работы, или вносить
изменения.
Чтобы сделать работу по ремонту сети настолько легкой, насколько это
возможно, вам следует задокументировать сеть до того момента, как она
прекратит работу: изучите все компоненты вашей сети и ее схему так
хорошо, как только сможете, с тем, чтобы в тот момент, когда что-то
станет работать не так, вам было бы проще выявить источник нарушения.
Дополнением к этому может быть блокирование пользовательских рабочих
столов. Храните приложения централизованно и препятствуйте попыткам
пользователей выполнить конфигурирование (возможно, ошибочное)
своих компьютеров. Старайтесь проводить все инвентаризации и установки
из одного центрального пункта, чтобы не пришлось слишком много бегать
при выполнении этой работы. Суть такого подхода заключается в том,
чтобы с помощью адекватной информации о своей сети и соответствующего
уровня контроля над ней сделать работу по управлению сетью значительно
проще, чем если бы она была свободной для всего и вся.
Управление, т.е. поддержка работающей сети в должном состоянии —
это значительная часть одной общей задачи: облегчения жизни сетевых
пользователей. В следующей главе расскажем о другом аспекте этой
задачи — о защите данных.
Упражнение к лекции 14.
Вы пытаетесь определить количество клиентов, использующих файловый
сервер в будний день в послеполуденное время. Дополните эти пункты.
1. Какого типа аудит вы должны выполнить?
2. Какой инструмент, описанный в этой лекции, поможет вам опреде-
лить, сколько клиентных запросов ожидают обработки в данный момент
времени?
3. Какой инструмент вы используете, чтобы определить клиентные компьютеры, которые связывались с вашим сервером?
4. Для идентификации компьютера в отдельном сегменте вы должны использовать __________ сетевую карту.
5. Чем хороша идея удаленного запуска инструмента наблюдения за сервером?
6. Информационной базой для управления является _______ файл.
А. Текстовый.
В. Двоичный.
С. Читаемый с помощью компьютера.
D. Никакой из указанных
7. На каком протоколе без установки соединения базируется протокол
SNMP?
8. Вы хотите наблюдать за графиком IPX/SPX на одном из сегментов сети. Каким инструментом следует воспользоваться?
А. SNMP
В. CMIP
С. RMON
D.TDR
9. Ответьте: "Да" или "Нет". Для работы SNMP требуется поддержка протокола TCP/IP.
10. Какая технология нулевого администрирования в данный момент поддерживает проверку решения проблемы Y2K через сеть?
11. Какое из следующих средств ZAW не является внешней частью NT 4?
А. Системные правила
В. Конфигурация TaskStation
С. Контроль совместимости Y2K
D. Профили пользователей
12. Какие именно документы будут найдены в результате применения
следующего логического оператора поиска: "NetWare 5" NEAR Zero
Administration?
13. Напишите запрос, по которому будет возвращен список документов, содержащих ссылки на NT или NetWare, но не оба сразу.
14. Перечислите три способа тестирования изменений перед полной их реализацией.