Архитектура Аудит Военная наука Иностранные языки Медицина Металлургия Метрология
Образование Политология Производство Психология Стандартизация Технологии


Назначение компьютерных сетей



Назначение компьютерных сетей

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

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

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

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

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

Лекция 2. Физические и логические аспекты эксплуатации сети.

Этапы проектирования компьютерной сети

  1. Описние предметной области
  2. Анализ административного деления
  3. Анализ территориального деления предприятия
  4. Построение физической структуры сети предприятия (проводка кабеля – транспорта, маршрутизатор, etc)
  5. Построение логической инфрастуктуры сети предприятия
  6. Анализ информационных потоков (моделирование, поиск узких мест, распределение каналов)
  7. Подбор оборудования (желательно одной марки/фирмы, во избежании конфликтов оборудования)
  8. Расчет стоимости, создание или модернизация сети
  9. Определение регламентов работы с сетью

10.

    • насройка сетевых служб (DNS, DHCP, …)
    • спецификация оборудования

 

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

Инфраструктура определяется:

  • проектом
  • наследованием от ранее используемых сетей
  • внешние обстоятельства (подключение к глобальной сети интернет)

Определение инфраструктуры сети

Инфраструктура сети — это набор физических и логических компонентов, которые обеспечивают связь, безопасность, маршрутизацию, управление, доступ и другие обязательные свойства сети. Чаше всего инфраструктура сета определяется проектом, но многое определяют внешние обстоятельства и * наследственность*. Например, подключение к Интернету требует обеспечить поддержку соответствующих технологий, в частности протокола TCP/IP. Другие же параметры сети, например физическая компоновка основных элементов, определяются при проектировании, а затем уже наследуются позднейшими версиями сети.

Физическая инфраструктура

Под физической инфраструктурой сети подразумевают ее топологию, то есть физическое строение сети со всем ее оборудованием: кабелями, маршрутизаторами, коммутаторами, мостами, концентраторами, серверами и узлами. К физической инфраструктуре также относятся транспортные технологии: Ethernet. 802.11b, коммутируемая телефонная сеть обшего пользования (PSTN), ATM — в совокупности они определяют, как осуществляется связь на уровне физических подключений. Предполагается, что вы знакомы с основами физической инфраструктуры сети, и эта тема в настоящей статье не рассматривается.

рис. 1-1

Логическая инфраструктура

Логическая инфраструктура сети состоит из всего множества программных элементов, служащих для связи, управления и безопасности узлов сети, и обеспечивает связь между компьютерами с использованием коммуникационных каналов, определенных в физической топологии. Примеры элементов логической инфраструктуры сети: система доменных имен (Domain Name System. DNS), сетевые протоколы, например TCP/IP. сетевые клиенты, например Клиент для сетей NetWare (Client Service for NetWare), а также сетевые службы, например Планировщик пакетов качества службы (QoS) |Quality of Service (QoS) Packet Scheduler].

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

В средних и крупных сетях у администраторов более сложные задачи: настройка удаленного доступа по телефонной линии и виртуальных частных сетей (VPN), создание, настройка и устранение неполадок интерфейсов и таблиц маршрутизации, создание, поддержка и устранение неполадок подсистемы безопасности на основе открытых ключей, обслуживание смешанных сетей с разными ОС. в том числе Microsoft Windows. UNIX и Nowell NetWare.

Рекомендации по эксплуатации ЛВС:

Физические аспекты ЛВС:

Для обеспечения правильной работы ЛВС недопустимо несанкционированное ИСПОЛНИТЕЛЕМ физическое вмешательство в инфраструктуру сети (активное и пассивное сетевое оборудование - кабельные каналы, кабель, патч-панели, розетки, и т.п.).

 

Логические (информационные) аспекты работы ЛВС:

Недопустимость использования несанкционированного ПО (в том числе сетевого).

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


 


Производительность

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

Надежность

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

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

Управляемость

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

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

Прозрачность

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

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

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

 

Интегрируемость

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

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

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

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

Расширяемость (extensibility) означает возможность сравнительно легкого добавления отдельных элементов сети (пользователей, компьютеров, приложений служб), наращивания длины сегментов сети и замены существующей аппаратуры более мощной. При этом принципиально важно, что легкость расширения системы иногда может обеспечиваться в некоторых весьма ограниченных пределах. Например, локальная сеть Ethernet, построенная на основе одного сегмента толстого коаксиального кабеля, обладает хорошей расширяемостью, в том смысле, что позволяем легко подключать новые станции. Однако такая сеть имеет ограничение на число станций — их число не должно превышать 30-40. Хотя сеть допускает физическое подключение к сегменту и большего числа станций (до 100), но при этом чаще всего резко снижается производительность сети. Наличие такого ограничения и является признаком плохой масштабируемости системы при хорошей расширяемости.

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


 


Выполнение аудита

После того, как сеть установлена и начала нормально работать, не расслабляйтесь. Теперь самое время упорядочивать документацию. Познакомьтесь с вашей сетью поближе именно сейчас, пока все работает так, как надо. Это не слишком благодарная работа, и не всегда она кажется приятным времяпрепровождением, но окупается при возникновении неисправностей. Во-первых, если вы будете знать, что собой представляет сеть во время нормальной работы, вам будет легче обнаружить неисправность, когда она не работает. " Не работает" не обязательно из-за неисправностей в результате каких-то изменений в сети. Может быть, например, что часть сети работает, но с пониженной производительностью. Так будет продолжаться до тех пор, пока не будет определена и устранена причина. Во-вторых, для поддержания работоспособности больших и протяженных сетей знание схемы физической компоновки вашей сети может быть весьма важным при установлении причины возникновения нарушений или при определении неисправной части сети. Можно выделить две основные разновидности аудита локальных сетей: физический и нематериальный (intangible). Аудит имущества и оборудования чаще всего является физическим — используйте его для определения того, что имеется в наличии, и локализации местонахождения оборудования. Аудит производительности, эффективности и безопасности в большинстве случаев имеет нематериальную природу.

Создание карты сети

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

Аппаратное резервирование

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

Кластеризация дает ряд преимуществ, основные из которых — это:

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

В ИС применяются кластеры как с центральной точкой отказа, так и без нее. Пока наиболее распространены кластеры с центральной точкой отказа. Устранение единой точки отказа обычно выполняется уже на втором этапе, в ходе усовершенствования существующей системы. В целом комплект оборудования для устранения центральной точки отказа обходится примерно в 10 тыс. долл. (для кластера Microsoft на Intel-серверах Compaq).

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

Сетевое копирование

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

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

Протоколы управления

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

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

· CMIP — протокол управления, рекомендованный ISO в качестве базового, не получил широкого распространения вследствие своей сложности;

· TMN — концепция сетевого управления, включающая в себя множество протоколов управления и вводящая понятие уровней управления;

· LNMP — протокол управления для ЛВС;

· ANMP — протокол управления для сетей специального назначения.

SNMP (англ. Simple Network Management Protocol — простой протокол сетевого управления) — стандартный интернет-протокол для управления устройствами в IP-сетях на основе архитектур TCP/UDP. К поддерживающим SNMP устройствам относятся маршрутизаторы, коммутаторы, серверы, рабочие станции, принтеры, модемные стойки и другие. Протокол обычно используется в системах сетевого управления для контроля подключенных к сети устройств на предмет условий, которые требуют внимания администратора. SNMP определен Инженерным советом интернета (IETF) как компонент TCP/IP. Он состоит из набора стандартов для сетевого управления, включая протокол прикладного уровня, схему баз данных и набор объектов данных.

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

Обзор и основные понятия

Principle of SNMP Communication

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

Менеджеры SNMP обрабатывают данные о конфигурации и функционировании управляемых систем и преобразуют их во внутренний формат, удобный для поддержания протокола SNMP. Протокол также разрешает активные задачи управления, например, изменение и применение новой конфигурации через удаленное изменение этих переменных. Доступные через SNMP переменные организованы в иерархии. Эти иерархии, как и другие метаданные (например, тип и описание переменной), описываются базами управляющей информации (базы MIB, от англ. Management information base).

Управляемые протоколом SNMP сети состоят из трех ключевых компонентов:

· Управляемое устройство;

· Агент — программное обеспечение, запускаемое на управляемом устройстве, либо на устройстве, подключенном к интерфейсу управления управляемого устройства;

· Система сетевого управления (Network Management System, NMS) — программное обеспечение, взаимодействующее с менеджерами для поддержки комплексной структуры данных, отражающей состояние сети[1].

Управляемое устройство — элемент сети (оборудование или программное средство), реализующий интерфейс управления (не обязательно SNMP), который разрешает однонаправленный (только для чтения) или двунаправленный доступ к конкретной информации об элементе. Управляемые устройства обмениваются этой информацией с менеджером. Управляемые устройства могут относиться к любому виду устройств: маршрутизаторы, серверы доступа, коммутаторы, мосты, концентраторы, IP-телефоны, IP-видеокамеры, компьютеры-хосты, принтеры и т.п.

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

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

CMIP (англ. Common Management Information Protocol - протокол общей управляющей информации) — стандарт управления сетью OSI. CMIP оперирует управляющей информацией в виде управляемых объектов. Управляемые объекты описываются на основе GDMO (англ. Guidelines for Definition of Managed Objects - стандарт описания управляемых объектов). CMIP определяет некоторые функции, отсутствующие в SNMP и SNMPv2. В силу своей сложности данный протокол имеет гораздо меньшее распространение и привлекает меньший интерес, нежели SNMP, но иногда его использование необходимо.


 


Типичные функции

Большинство анализаторов сетевых протоколов работают по схеме, представленной на рис. 1, и отображают, по крайней мере в некотором начальном виде, одинаковую базовую информацию. Анализатор работает на станции хоста. Когда анализатор запускается в беспорядочном режиме (promiscuous mode), драйвер сетевого адаптера, NIC, перехватывает весь проходящий через него трафик. Анализатор протоколов передает перехваченный трафик декодеру пакетов анализатора (packet-decoder engine), который идентифицирует и расщепляет пакеты по соответствующим уровням иерархии. Программное обеспечение протокольного анализатора изучает пакеты и отображает информацию о них на экране хоста в окне анализатора. В зависимости от возможностей конкретного продукта, представленная информация может впоследствии дополнительно анализироваться и отфильтровываться.

Рисунок 1. Анализатор протоколов выполняет мониторинг сетевого трафика

Обычно окно протокольного анализатора состоит их трех областей, как, например, показано на экране 1, демонстрирующем продукт Ethereal. Верхняя область отображает итоговые данные перехваченных пакетов. Обычно в этой области отображается минимум полей, а именно: дата; время (в миллисекундах), когда пакеты были перехвачены; исходные и целевые IP-адреса; исходные и целевые адреса портов; тип протокола (сетевой, транспортный или прикладного уровня); некоторая суммарная информация о перехваченных данных. В средней области показаны логические врезки пакетов, выбранных оператором. И наконец, в нижней области пакет представлен в шестнадцатеричном виде или в символьной форме — ASCII.

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

Обзор анализаторов

На рынке программного обеспечения и программных продуктов среди анализаторов сетевых протоколов я, к своему удивлению, обнаружил большое количество сильных программ, вполне достойных друг друга. Оценивая анализатор протоколов, рекомендую особое внимание обратить на такие его свойства, как точность перехвата пакетов, диапазон декодируемых протоколов (с учетом условий работы конкретной сети), степень детализации декодеров, наличие экспертного анализа, модель размещения (распределенная или нет), цена и техническая поддержка. Далее мы рассмотрим шесть анализаторов сетевых протоколов общего назначения: Ethereal, OptiView Protocol Expert 4.0 (производитель — Fluke Networks), Netasyst Network Analyzer WLX (производитель — Network Associates), Observer 9.0 (производитель — Network Instruments), LanHound 1.1 (производитель — Sunbelt Software) и EtherPeek NX 2.1 (производитель — WildPackets).

 

Тестеры (омметры)

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

Кабельные сканеры

Приборы позволяют определить длину кабеля, NEXT, затухание, импеданс, схему разводки, уровень электрических шумов и оценить полученные результаты. Цена на них варьируется от $1.000 до $3.000. Существует достаточно много устройств данного класса, например, сканеры компаний Microtest Inc., Fluke Corp., Datacom Technologies Inc., Scope Communication Inc. В отличие от сетевых анализаторов сканеры могут быть использованы не только специалистами, но даже администраторами-новичками.

Для определения местоположения неисправности кабельной системы (обрыва, короткого замыкания и т.д.) используется метод кабельного радара, или Time Domain Reflectometry (TDR). Суть эго состоит в том, что сканер излучает в кабель короткий электрический импульс и измеряет время задержки до прихода отраженного сигнала. По полярности отраженного импульса определяется характер повреждения кабеля (короткое замыкание или обрыв). В правильно установленном и подключенном кабеле отраженный импульс отсутствует.

Наиболее известными производителями компактных (их размеры обычно не превышают размеры видеокассеты стандарта VHS) кабельных сканеров являются компании Microtest Inc., WaveTek Corp., Scope Communication Inc.

Рассмотрим подробнее технические воз-можности приборов для сертификации кабельных систем (так в более общем случае называют современные многофункциональные сканеры) на примере семейства моделей PentaScanner компании Microtest.

Модель кабельного сканера PentaScanner Cable Admin обеспечивает сертификацию кабельных систем категории 5 уровней точности I. Он предназначен для поиска неисправностей кабельной системы и представляет собой сравнительно дешевый и простой в использовании прибор, позволяющий быстро определить неисправность кабельной системы.

Кабельный сканер PentaScanner+ предназначен, главным образом, для специалистов компаний сетевых интеграторов или сотрудников отделов автоматизаций предприятий, которым необходимо устанавливать и сертифицировать кабельные системы категории 5. TSB-67 требует измерение NEXT с обоих концов линии. Используя PentaScanner+ совместно с двунаправленным инжектором - 2-Way Injector+, измерения NEXT можно производить с обоих концов линии одновременно. При использовании PentaScanner+ совместно со стандартным инжектором - Super Injector+, необходимо менять местами PentaScanner+ и Super Injector+ для проведения полной сертификации линии (рис. Кабельный сканер PentaScanner+ с двунаправленным инжектором - 2-Way Injector+).

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

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

Для измерения перекрестных наводок между витыми парами (NEXT) источник сигналов - Super Injector+ (прибор поставляемый в комплекте с PentaScanner+) (подсоединяется к передающей паре и начинает передавать в нее сигналы различной частоты. Приемник сигналов подключается к приемной паре и измеряет сигнал, наведенный в ней, сравнивая его со стандартными величинами. Преимуществом узкополосного приемника в PentaScanner+ является измерение чистого NEXT, с отфильтровыванием всех наводок и электрического шума. Для измерения затухания PentaScanner+ использует Super Injector+ в качестве удаленного источника сигналов, генерирующего серию сигналов различной частоты. PentaScanner+ в этот момент измеряет амплитуду этих сигналов на другом конце кабеля.

И, наконец, последняя модель семейства PentaScanner - PentaScanner 350 - являет-ся сканером нового поколения, предназначенного для тестирования кабельных систем категории 5 на частоте до 350 Мгц. Penta-Scanner 350 представляет собой наиболее прецизионный на сегодняшний день кабельный сканер, полностью соответствующий Уровню точности II стандарта TSB-67. В памяти сканера PentaScanner 350 могут сохраняться результаты до 500 различных тестов.

Описаные нами устройства предназначены для тестирования кабельных систем на основе медного кабеля. У читателя может возникнуть вопрос: А как же быть с системами на основе волоконно-оптического кабеля?. Действительно, сегодня волоконно-оптические сети находят в мире все большее применение. В пользу еще более широкого распространения их в ближайшем будущем говорит, во-первых, снижение стоимости на сам волоконно-оптический кабель, а также на оборудование для сварки и инсталляции. В скором времени, по мнению зарубежных аналитиков, стоимость медного кабеля категории 5 и волоконно-оптического кабеля сравняются. Во-вторых, именно на волоконно-оптический кабель ориентируются ведущие производители сетевого оборудования при разработке новых стандартов передачи данных, в частности, так называемого, гигабитного Ethernet.

Для диагностики волоконно-оптических кабелей компания Microtest предлагает комплект Fiber Solution Kit, который состоит из двух приборов: измерителя оптической мощности FiberEye и калиброванного светового источника FiberLight (рис. Измеритель оптической мощности FiberEye и калиброванный световой источник FiberLight).

Эти приборы тестируют сети стандартов Ethernet, Token Ring и Fiber Distributed Data Interface (FDDI).

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

FiberLight - калиброванный световой источник, можно использовать с FiberEye для обеспечения эффективности диагностики волоконно-оптической сети. FiberLight состоит из двух источников световых импульсов, каждый из которых имеет свой внешний разъем для подключения к кабелю. Один источник используется для сетей Ethernet и Token Ring, a другой для сетей FDDI.


 


Режимы функционирования

ЭС может функционировать в 2-х режимах.

1. Режим ввода знаний — в этом режиме эксперт с помощью инженера по знаниям посредством редактора базы знаний вводит известные ему сведения о предметной области в базу знаний ЭС.

2. Режим консультации — пользователь ведет диалог с ЭС, сообщая ей сведения о текущей задаче и получая рекомендации ЭС. Например, на основе сведений о физическом состоянии больного ЭС ставит диагноз в виде перечня заболеваний, наиболее вероятных при данных симптомах.

Режимы функционирования

ЭС может функционировать в 2-х режимах.

3. Режим ввода знаний — в этом режиме эксперт с помощью инженера по знаниям посредством редактора базы знаний вводит известные ему сведения о предметной области в базу знаний ЭС.

4. Режим консультации — пользователь ведет диалог с ЭС, сообщая ей сведения о текущей задаче и получая рекомендации ЭС. Например, на основе сведений о физическом состоянии больного ЭС ставит диагноз в виде перечня заболеваний, наиболее вероятных при данных симптомах.

· Статические ЭС — это ЭС, решающие задачи в условиях не изменяющихся во времени исходных данных и знаний.

· Квазидинамические ЭС интерпретируют ситуацию, которая меняется с некоторым фиксированным интервалом времени.

· Динамические ЭС — это ЭС, решающие задачи в условиях изменяющихся во времени исходных данных и знаний.

Этапы разработки ЭС

· Этап идентификации проблем — определяются задачи, которые подлежат решению, выявляются цели разработки, определяются эксперты и типы пользователей.

· Этап извлечения знаний — проводится содержательный анализ проблемной области, выявляются используемые понятия и их взаимосвязи, определяются методы решения задач.

· Этап структурирования знаний — выбираются ИС и определяются способы представления всех видов знаний, формализуются основные понятия, определяются способы интерпретации знаний, моделируется работа системы, оценивается адекватность целям системы зафиксированных понятий, методов решений, средств представления и манипулирования знаниями.

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

· Реализация ЭС — создается один или несколько прототипов ЭС, решающие требуемые задачи.

· Этап тестирования — производится оценка выбранного способа представления знаний в ЭС в целом.

Наиболее известные/распространённые ЭС[править | править вики-текст]

· Simptomus — сервис онлайн-диагностики заболеваний. Пациенты указывают симптомы, а Simptomus на основе экспертной системы выводит список возможных диагнозов.

· CLIPS — весьма популярная оболочка для построения ЭС (public domain)

· OpenCyc — мощная динамическая ЭС с глобальной онтологической моделью и поддержкой независимых контекстов

· WolframAlpha — база знаний и набор вычислительных алгоритмов, интеллектуальный «вычислительный движок знаний»

· MYCIN — наиболее известная диагностическая система, которая предназначена для диагностики и наблюдения за состоянием больного при менингите и бактериальных инфекциях.

· HASP/SIAP — интерпретирующая система, которая определяет местоположение и типы судов в Тихом океане по данным акустических систем слежения.

· Акинатор — интернет-игра. Игрок должен загадать любого персонажа, а Акинатор должен его отгадать, задавая вопросы. База знаний автоматически пополняется, поэтому программа может отгадать практически любого известного персонажа.

· IBM Watson — суперкомпьютер фирмы IBM, способный понимать вопросы, сформулированные на естественном языке, и находить на них ответы в базе данных.


 


Сетевой монитор.

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

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

С помощью компонента Сетевой монитор, включенного в операционные системы Microsoft Windows Server 2003, можно собирать данные, отправленные или полученные с компьютера, на котором установлен сетевой монитор. Для сбора данных, посылаемых или получаемых с удаленного компьютера, необходимо использовать компонент Сетевой монитор, входящий в Microsoft Systems Management Server (SMS), с помощью которого можно собирать данные, посылаемые или получаемые с любого компьютера, на котором установлен драйвер сетевого монитора. Дополнительные сведения о сервере Systems Management Server см. на веб-узле корпорации Майкрософт(http: //www.microsoft.com/smsmgmt).

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

Запись данных.

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

При записи кадров сетевым монитором сведения о кадрах отображаются в окне записи данных, разделенном на четыре панели.

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

 

Сетевой монитор копирует передаваемые по сети пакеты с требуемыми характеристиками в буфер записи с помощью спецификации NDIS.

Фильтры записи.

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

Создание фильтров записи

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

Триггеры записи.

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

Типы триггеров

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

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

Действия триггера

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

  • Компьютер издает звуковой сигнал.
  • Сетевой монитор прекращает запись кадров.
  • Выполняется выбранная команда.

 

Чтобы задать команду, которая запускает программу, введите имя и путь к файлу программы, или нажмите кнопку Обзор и найдите файл программы. Для использования команды MS-DOS, такой как copy, введите CMD /K и затем введите команду.

Дизайн хранилищ данных

Существуют два архитектурных направления – нормализованные хранилища данных и хранилища с измерениями.

В нормализованных хранилищах, данные находятся в предметно ориентированных таблицах третьей нормальной формы. Нормализованные хранилища характеризуются как простые в создании и управлении, недостатки нормализованных хранилищ – большое количество таблиц как следствие нормализации, из-за чего для получения какой-либо информации нужно делать выборку из многих таблиц одновременно, что приводит к ухудшению производительности системы. Для решения этой проблемы используются денормализованные таблицы - витрины данных, на основе которых уже выводятся отчетные формы. При громадных объемах данных могут использовать несколько уровней «витрин»/«хранилищ».

Хранилища с измерениями используют схему «звезда» или схему «снежинка». При этом в центре «звезды» находятся данные (Таблица фактов), а измерения образуют лучи звезды. Различные таблицы фактов совместно используют таблицы измерений, что значительно облегчает операции объединения данных из нескольких предметных таблиц фактов (Пример – факты продаж и поставок товара). Таблицы данных и соответствующие измерениями образуют архитектуру «шина». Измерения часто создаются в третьей нормальной форме, в том числе, для протоколирования изменения в измерениях. Основным достоинством хранилищ с измерениями является простота и понятность для разработчиков и пользователей, также, благодаря более эффективному хранению данных и формализованным измерениям, облегчается и ускоряется доступ к данным, особенно при сложных анализах. Основным недостатком является более сложные процедуры подготовки и загрузки данных, а также управление и изменение измерений данных.

При достаточно большом объеме данных схемы «звезда» и «снежинка» также дают снижение производительности при соединениях с измерениями.

Процессы работы с данными

Источниками данных могут быть:

1. Традиционные системы регистрации операций

2. Отдельные документы

3. Наборы данных

Операции с данными:

1. Извлечение – перемещение информации от источников данных в отдельную БД, приведение их к единому формату.

2. Преобразование – подготовка информации к хранению в оптимальной форме для реализации запроса, необходимого для принятия решений.

3. Загрузка – помещение данных в хранилище, производится атомарно, путем добавления новых фактов или корректировкой существующих.

4. Анализ – OLAP, Data Mining, сводные отчёты.

5. Представление результатов анализа.

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

Задача словаря метаданных состоит в том, чтобы освободить разработчика от необходимости стандартизировать источники данных.

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

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

Логическая структура данных хранилища данных существенно отличается от структуры данных источников данных.

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

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

Кроме извлечения данных из БД, для принятия решений важен процесс извлечения знаний, в соответствии с информационными потребностями пользователя.

С точки зрения пользователя в процессе извлечения знаний из БД должны решаться следующие преобразования: данные → информация → знания → полученные решения.


 


Основные функции СУБД

· управление данными во внешней памяти (на дисках);

· управление данными в оперативной памяти с использованием дискового кэша;

· журнализация изменений, резервное копирование и восстановление базы данных после сбоев;

· поддержка языков БД (язык определения данных, язык манипулирования данными).

Обычно современная СУБД содержит следующие компоненты:

· ядро, которое отвечает за управление данными во внешней и оперативной памяти и журнализацию,

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

· подсистему поддержки времени исполнения, которая интерпретирует программы манипуляции данными, создающие пользовательский интерфейс с СУБД

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

Классификации СУБД

По модели данных

Примеры:

· Иерархические

· Сетевые

· Реляционные

· Объектно-ориентированные

· Объектно-реляционные

По степени распределённости

· Локальные СУБД (все части локальной СУБД размещаются на одном компьютере)

· Распределённые СУБД (части СУБД могут размещаться на двух и более компьютерах).

По способу доступа к БД

· Файл-серверные

В файл-серверных СУБД файлы данных располагаются централизованно на файл-сервере. СУБД располагается на каждом клиентском компьютере (рабочей станции). Доступ СУБД к данным осуществляется через локальную сеть. Синхронизация чтений и обновлений осуществляется посредством файловых блокировок. Преимуществом этой архитектуры является низкая нагрузка на процессор файлового сервера. Недостатки: потенциально высокая загрузка локальной сети; затруднённость или невозможность централизованного управления; затруднённость или невозможность обеспечения таких важных характеристик как высокая надёжность, высокая доступность и высокая безопасность. Применяются чаще всего в локальных приложениях, которые используют функции управления БД; в системах с низкой интенсивностью обработки данных и низкими пиковыми нагрузками на БД.

На данный момент файл-серверная технология считается устаревшей, а её использование в крупных информационных системах — недостатком[2].

Примеры: Microsoft Access, Paradox, dBase, FoxPro, Visual FoxPro.

· Клиент-серверные

Клиент-серверная СУБД располагается на сервере вместе с БД и осуществляет доступ к БД непосредственно, в монопольном режиме. Все клиентские запросы на обработку данных обрабатываются клиент-серверной СУБД централизованно. Недостаток клиент-серверных СУБД состоит в повышенных требованиях к серверу. Достоинства: потенциально более низкая загрузка локальной сети; удобство централизованного управления; удобство обеспечения таких важных характеристик как высокая надёжность, высокая доступность и высокая безопасность.

Примеры: Oracle, Firebird, Interbase, IBM DB2, Informix, MS SQL Server, Sybase Adaptive Server Enterprise, PostgreSQL, MySQL, Caché, ЛИНТЕР.

· Встраиваемые

Встраиваемая СУБД — СУБД, которая может поставляться как составная часть некоторого программного продукта, не требуя процедуры самостоятельной установки. Встраиваемая СУБД предназначена для локального хранения данных своего приложения и не рассчитана на коллективное использование в сети. Физически встраиваемая СУБД чаще всего реализована в виде подключаемой библиотеки. Доступ к данным со стороны приложения может происходить через SQL либо через специальные программные интерфейсы.

Примеры: OpenEdge, SQLite, BerkeleyDB, Firebird Embedded, Microsoft SQL Server Compact, ЛИНТЕР.

Стратегии работы с внешней памятью[править | править вики-текст]

СУБД с непосредственной записью — это СУБД, в которых все измененные блоки данных незамедлительно записываются во внешнюю память при поступлении сигнала подтверждения любой транзакции. Такая стратегия используется только при высокой эффективности внешней памяти.

СУБД с отложенной записью — это СУБД, в которых изменения аккумулируются в буферах внешней памяти до наступления любого из следующих событий:

· контрольной точки;

· конец пространства во внешней памяти, отведенное под журнал. СУБД выполняет контрольную точку и начинает писать журнал сначала, затирая предыдущую информацию;

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

· При нехватке оперативной памяти для буферов внешней памяти.

Такая стратегия позволяет избежать частого обмена с внешней памятью и значительно увеличить эффективность работы СУБД.


 

Лекция 23. Принципы планирования восстановления работоспособности сети при аварийной ситуации.

Если пришла беда...

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


Общие положения

Один из наиболее полных и логичных образцов подобного документа был разработан Национальным институтом стандартов США (NIST) в 2001 году (http: //www.anykeynow.com/services/white_papers/bcp1.htm).

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

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

Поставленная цель достигается решением следующих задач:

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


К примеру, специалисты NIST все мероприятия по выполнению Плана распределяют по трем этапам:

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

Согласно исследованию компании McKinseyQuarterly, за последний год в США значительно возросло число компьютерных атак на корпоративные IT-системы. В исследовании McKinseyQuarterly сообщается, что число компьютерных атак (действия хакеров, вирусов, червей, недобросовестных работников и др.) возросло на 150% по сравнению с 2000 годом, составив в общей сложности 53000 случаев взлома систем информационной безопасности компаний.

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

Принципы планирования восстановления

Реализуемость Плана основана на двух предположениях:

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



Допущения при разработке Плана

При разработке Плана восстановления, как правило, применяются следующие основные допущения и посылки:

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

Целью хакерской атаки обычно является хищение коммерческой информации и финансовое мошенничество, однако в Москве, по опросам специалистов, эти позиции составляют лишь 3% и 6% от общего числа хакерских атак. Эксперты Ernst & Young полагают, что масштабы проблемы намного существеннее, а низкий процент объясняется тем, что современные хакеры искусно скрывают следы. Только в Москве ущерб от электронных мошенников оценивается столичными правоохранительными органами в 12 - 15 млн долларов в месяц.

Основные требования к политике организации

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

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

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

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




Принятие решения на активацию Плана

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

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

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

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

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

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

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

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

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

Мероприятия по восстановлению работоспособности системы в резервном варианте размещения оборудования и персонала

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

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

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

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



Лекция 26. План восстановления системы.

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

Бен Смит

 

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

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

Шесть этапов планирования

В терминологии планирования действий в аварийных ситуациях фигурируют два общих понятия: планирование сохранения непрерывности бизнеса (Business Continuity Planning, BCP) и планирование послеаварийного восстановления (Disaster Recovery Planning, DRP). Эти понятия, часто используемые как равноценные, представляют различные концепции. ВСР традиционно предусматривает планирование мероприятий, обеспечивающих сохранение деловой активности организации в чрезвычайных ситуациях. Сфера ответственности DRP, по сути, представляет подмножество ВСР и касается восстановления информации и работоспособности систем в случае аварии. Например, выход из строя жесткого диска на сервере базы данных потенциально угрожает целостности бизнеса, но не является результатом катастрофических событий. Разрыв же водопроводной трубы с затоплением серверного помещения и погружением сервера базы данных в воду представляет угрозу целостности бизнеса, рассматриваемую в рамках плана послеаварийного восстановления (DRP).

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

Шаг 2. Сбор статистики.

Опрос узлов сети на предмет получения log-файлов, диагностические команды узла сети, нарушающего общее функционирование (при условии его доступности)

Шаг 3. Локализация причины

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

Шаг 4. Устранение проблемы.

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

Шаг 5. Анализ результатов.

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


Рис 1. Алгоритм поиска и устранения неисправностей


Рассмотрим подробнее основные блоки схемы, представляющие собой более разветвленные структуры.


Анализ проблемы.

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

2. Сбор статистики.

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

Локализация причины

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

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

Устранение проблемы.

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

5. Анализ результатов.

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

Процесс поиска и устранения неисправности всегда проще облегчить, имея в своем распоряжении:

- наличие полной актуальной топологии сети;

- логическую карту адресов устройств, подсетей и соединений;

- список протоколов, запущенных внутри сети;

- правильно сконфигурированные маршрутизаторы;

- информация о внешних точках соединения сети с ISP;

- своевременное профилактика и диагностика;

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


 


Диагностические команды ОС

Таблица 5.1.

Название команды Назначение
arp Отображает или модифицирует таблицу протокола ARP (преобразование IP в MAC-адреса)
chnamsv Служит для изменения конфигурации службы имен на ЭВМ (для TCP/IP)
chprtsv Изменяет конфигурацию службы печати на ЭВМ-клиенте или сервере
gettable Получает таблицы ЭВМ в формате NIC
hostent Непосредственно манипулирует записями адресного соответствия ЭВМ в конфигурационной базе данных системы
hostid Устанавливает или отображает идентификатор данной ЭВМ
hostname Устанавливает или отображает имя данной ЭВМ
htable Преобразует файлы ЭВМ в формат, используемый программами сетевой библиотеки
ifconfig Конфигурирует или отображает параметры сетевых интерфейсов ЭВМ (для протоколов TCP/IP)
ipreport Генерирует сообщение о маршруте пакета на основе специфицированного маршрутного файла
iptrace Обеспечивает отслеживание маршрута движения пакетов на интерфейсном уровне для протоколов Интернет
lsnamsv Отображает информацию базы данных DNS
lsprtsv Отображает информацию из базы данных сетевой службы печати
mkhost Создает файл таблицы ЭВМ
mknamsv Конфигурирует службу имен клиента (для TCP/IP)
mkprtsv Конфигурирует службу печати ЭВМ (для TCP/IP)
mktcpip Устанавливает требуемые величины для запуска TCP/IP на ЭВМ
namerslv Непосредственно манипулирует записями сервера имен для локальной программы DNS в базе данных конфигурирования системы
netstat Отображает состояние сети
no Конфигурирует сетевые опции
rmnamsv Удаляет TCP/IP службу имен из ЭВМ
rmprtsv Удаляет службу печати на машине клиента или сервере
route Служит для ручного манипулирования маршрутными таблицами
ruptime Отображает состояние каждой ЭВМ в сети
ruser Непосредственно манипулирует записями в трех отдельных системных базах данных, которые регулируют доступом внешних ЭВМ к программам
securetcpip Активизирует сетевую безопасность
setclock Устанавливает время и дату для ЭВМ в сети
slattach Подключает последовательные каналы в качестве сетевых интерфейсов
timedc Присылает информацию о демоне timed
trpt Выполняет отслеживание реализации протокола для TCP-сокетов

 

Для того чтобы диагностировать ситуацию в сети, необходимо представлять себе взаимодействие различных ее частей в рамках протоколов TCP/IP и иметь некоторое представление о работе Ethernet [4]. Сети, следующие рекомендациям Интернет, имеют локальный сервер имен (DNS, RFC-1912, -1886, -1713, -1706, -1611-12, -1536-37, -1183, -1101, -1034-35; цифры, напечатанные полужирным шрифтом, соответствуют кодам документов, содержащим описания стандартов), служащий для преобразования символьного имени сетевого объекта в его IP-адрес. Обычно эта машина базируется на ОС UNIX. DNS-сервер обслуживает соответствующую базу данных, которая хранит много другой полезной информации. Многие ЭВМ имеют SNMP-резиденты (RFC-1901-7, -1446-5, -1418-20, -1353, -1270, - 1157, -1098), обслуживающие управляющую базу данных MIB (RFC-1792, -1748-49, -1743, -1697, -1573, -1565-66, -1513-14, -1230, -1227, -1212-13 ), содержимое которой поможет также узнать много интересного о состоянии вашей сети. Сама идеология Интернет предполагает богатую диагностику (протокол ICMP, RFC- 1256, 1885, -1788, -792 ).


 


AnetTest 1.0 --1

Автоматизированное тестирование сетевых устройств и приложений (генератор пакетов и сниффер - sniffer)

Net Runner 1.0

Net Runner is an accurate and fast performing analyzer for testing the performance of a network

Port Detective 2.0 +1

The Port Detective performs a remote port scan on your IP address.

TrafficEmulator 1.4

Stress test servers, routers and firewalls under heavy network load

CheckHost 1.5 +5

Network management tool continuously monitors specific host availability.

PingMaster 0.9

PingMaster pings computers in its database and monitors their response times

Graph-A-Ping 1.0.10

Graph-A-Ping is a free application design to graph a ping to any host

Актуальность диагностики сети Причина, вследствие которой мы изменили свои планы, заключается в следующем. В ходе проведения выставки Internetcom’98 мы (компания " ПроЛАН" ) решили изучить рынок диагностических средств в России. С этой целью посетителям нашего стенда было предложено письменно ответить на ряд вопросов относительно организации процесса диагностики локальной сети в их компании. Нас, в частности, интересовала актуальность проблемы диагностики сетей и ассортимент применяемых диагностических средств. Участие в опросе приняли более 400 посетителей, среди которых около половины представились как администраторы или технические специалисты по обслуживанию сети, а около трети — как представители компаний-системных интеграторов. Сразу оговоримся, что мы не знакомы с теорией проведения подобных опросов и не можем гарантировать, что приводимые ниже цифры можно экстраполировать на весь отечественный рынок. Тем не менее полученные нами результаты столь парадоксальны, что заслуживают того, чтобы о них написать. Обработав результаты опроса, мы получили, в частности, следующие цифры. Более 70% опрошенных ответили, что для их компании задача диагностики сети сегодня актуальна. Оставшиеся 30% — это, как правило, представители компаний, сеть которых состоит менее чем из 15 компьютеров. В то же время около 86% опрошенных из числа тех, кто имеет непосредственное отношение к обслуживанию или установке локальных сетей, никогда не пользовались каким-либо средством диагностики. Оставшиеся 14% опрошенных в качестве используемого средства диагностики чаще всего называют HP OpenView (сама по себе эта платформа управления не является диагностическим средством), кабельный сканер, MS Network Monitor, LANalyzer for Windows компании Novell и, о чем нам было очень приятно узнать, FTest компании " ПроЛАН". Учитывая естественное желание каждого человека не выглядеть невеждой, мы включили в анкету несколько вопросов, совокупность ответов на которые позволяет сделать вывод о действительном использовании интервьюируемым в своей работе указанных им средств. Исключив из рассмотрения " подозрительные" анкеты вместе с анкетами, где в качестве диагностического средства был указан только кабельный сканер, мы пришли к заключению, что только около 5% опрошенных, имеющих непосредственное отношение к обслуживанию или установке сетей, действительно пользуются диагностическими средствами. Естественно, нам было интересно узнать, в каких компаниях работают эти люди (назовем их для краткости профессионалами). Мы предполагали, что большинство профессионалов должны работать в компаниях-системных интеграторах. Однако, как показали результаты опроса, около 3% профессионалов являются администраторами сетей крупных коммерческих структур, и только немногим более 2% работает в компаниях, которые занимаются системной интеграцией. Многие администраторы сетей признавались нам в частных беседах, что их компания купила дорогостоящее средство управления сетью, но в своей работе они его практически не используют, так как либо у них нет времени, либо " у них и так все работает", и они не понимают, " зачем им это надо", либо на их аппаратной платформе оно периодически " виснет". Таким образом, мы сделали вывод, что, несмотря на явный интерес администраторов сетей к вопросам диагностики сетей, рынок диагностических средств в России в настоящее время находится в зачаточном состоянии. Причина, с нашей точки зрения, заключается в недостатке практического опыта и теоретических знаний у администраторов сетей и, как следствие этого, в неумении правильно организовать диагностику своей сети. Именно по этой причине мы решили посвятить данную статью описанию методов и средств для эффективной диагностики локальных сетей.
Вопросы терминологии Чтобы правильно организовать диагностику своей сети, вы должны знать, какую задачу какими средствами предпочтительнее решать. Многообразие имеющихся на рынке диагностических средств можно классифицировать по двум основным признакам.
- Средство предназначено для диагностики сети или для тестирования сети.

-

Средство предназначено для реактивной диагностики или для упреждающей диагностики.

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

Диагностика бывает двух типов: упреждающая (proactive) и реактивная (reactive). Упреждающая диагностика должна проводиться в процессе эксплуатации сети ежедневно. Основная цель упреждающей диагностики — предотвращение сбоев в работе сети. Реактивная диагностика выполняется, когда в сети уже произошел сбой и надо быстро локализовать источник и выявить причину.

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

Тестирование можно условно разделить на несколько видов в зависимости от цели, ради которой оно проводится. Это тестирование кабельной системы сети на соответствие стандартам TIA/EIA TSB-67; стрессовое тестирование конкретных сетевых устройств с целью проверки устойчивости их работы при различных уровнях нагрузок и различных типах сетевого трафика; тестирование ПО, в частности для определения его требований к пропускной способности сетевых ресурсов (к характеристикам канала связи, сервера и т. п.); стрессовое тестирование сети (конкретных сетевых конфигураций) с целью выявления " скрытых дефектов" в оборудовании и " узких мест" в архитектуре сети, а также с целью определения пороговых значений трафика, допустимых в данной сети.

Тестирование прикладного ПО с целью определения требований к пропускной способности сетевых ресурсов проводят (во всяком случае должны проводить) компании-разработчики ПО. Такое тестирование осуществляется в рамках комплексной проверки ПО перед выпуском его на рынок и называется тестированием на соответствие качеству (Quality Assurance Test, QAT). К сожалению, отечественные разработчики занимаются этим очень редко. Более того, разрабатывая прикладное ПО, многие вообще не задумываются об эффективности его работы в сети. Но это тема отдельной статьи (мы планируем сделать ее следующей в данном цикле).

Стрессовое тестирование сетевых устройств обычно проводится независимыми специализированными лабораториями. Примерами таких лабораторий являются организации LANQuest (http: //www.lanquest.com) и Data Communications (http: //www.data.com). Обычно стрессовое тестирование устройств проводится с целью проверки заявленных технических характеристик и выявления различного рода дефектов. Перед принятием окончательного решения о покупке какого-то устройства мы советуем познакомиться с результатами стрессового тестирования этого устройства в независимой лаборатории.

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

СТРЕССОВОЕ ТЕСТИРОВАНИЕ СЕТИ Основное отличие стрессового тестирования сети от тестирования устройств (в лабораторных условиях) заключается в том, что его задача состоит в проверке работоспособности уже купленных вами устройств в конкретных условиях эксплуатации (для конкретной кабельной системы, уровня шума, качества питающего напряжения, используемого оборудования и ПО и т. п.). Как и тестирование кабельной системы, стрессовое тестирование сети должно быть обязательной процедурой перед вводом сети в промышленную эксплуатацию. В настоящее время это делается крайне редко. Единственным обнадеживающим моментом остается тот факт, что еще несколько лет назад и кабельная система очень редко тестировалась перед вводом сети в эксплуатацию. Цель стрессового тестирования сети состоит, во-первых, в выявлении дефектов оборудования и архитектуры сети и, во-вторых, в определении границ применимости существующей архитектуры сети. Замечание №1. Стрессовое тестирование сети всегда должно предшествовать постановке сети на обслуживание. Результаты стрессового тестирования сети являются ориентиром при проведении упреждающей диагностики. Чтобы сделать правильные выводы о состоянии сети по результатам наблюдения за параметрами ее работы с помощью средств диагностики, вы должны знать, каковы максимально допустимые значения этих параметров именно для вашей сети. Достоверные выводы о причинах неадекватного поведения сети сделать очень сложно, если вы точно не знаете, какова допустимая утилизация канала связи для обеспечения нормального времени реакции эксплуатируемого прикладного ПО или как пропускная способность вашего коммутатора или сервера зависит от длины кадров, типа протоколов, числа широковещательных и групповых пакетов, режима коммутации и т. п. Замечание №2. Основными инструментами для стрессового тестирования сети являются генераторы трафика, анализаторы сетевых протоколов и стрессовые тесты. Генераторы трафика могут быть чисто программными или программно-аппаратными. Суть работы генератора трафика заключается в том, что, задавая параметры, направление и интенсивность трафика, вы создаете в сети дозируемую нагрузку с определенными параметрами трафика (длиной кадров, типом протокола, адресом источника и приемника и т. п.). Примером программного генератора трафика является Frame Thrower компании LANQuest. Он работает на обычном ПК и может генерировать трафик для сетей Ethernet, Token Ring, FDDI, ATM. Примером аппаратного генератора трафика является устройство PowerBits компании Alantec для сетей Ethernet и FDDI. Генераторы трафика встраиваются во многие анализаторы сетевых протоколов, например в Sniffer компании Network Associates, DA-30 компании Wandel& Goltermann, HP Analyzer компании Hewlett-Packard, Observer компании Network Instrumens и др. На Рисунке 1 показаны параметры, задаваемые в генераторе трафика программы Observer.
  Рисунок 1. Параметр Packets/sec задает интенсивность генерируемого трафика. Параметр Packet size задает размер генерируемых кадров. Параметр Destination задает МАС-адрес, куда будет производиться генерация. Параметры IP/TCP/UDP/IPX определяют формат генерируемых данных.

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

Примерами стрессовых тестов для эмуляции работы с файлами в сети являются MS-Test компании Microsoft, NetBench и ServerBench компании Ziff-Davis, Perform3 компании Novell, FTest компании " ПроЛАН". Примерами более сложных стрессовых тестов для эмуляции работы в сети конкретных приложений могут служить EMPOWER компании Performix, QA Partner компании Segue, AutoUser Simulater компании " ПроЛАН". В данной статье мы рассмотрим, как можно провести стрессовое тестирование сети с помощью распределенного программного анализатора протоколов Distributed Observer компании Network Instruments и стрессового теста типа программы FTest компании " ПроЛАН" или Perform3 компании Novell на примере тестирования гипотетической сети, изображенной на Рисунке 2. Предлагаемая в данной статье методика не является " истиной в последней инстанции", а служит лишь иллюстрацией возможных методов решения описанных выше задач.

  Рисунок 2. Центральный анализатор протоколов подключается к зеркальному порту коммутатора. Удаленный агент анализатора протоколов, расположенный в домене А, настраивается на генерацию ТСР-трафика на МАС-адрес станции-" приемника", в домене MAIN. Агент анализатора протоколов из домена MAIN настраивается на генерацию трафика во встречном направлении. Аналогично настраиваются генераторы трафика по всем остальным портам коммутатора. На фоне генерации трафика запускается работа приложения BOSS.

ОРГАНИЗАЦИЯ СТРЕССОВОГО ТЕСТИРОВАНИЯ Предположим, что установленный в центре сети коммутатор имеет порты Fast Ethernet и Ethernet, причем серверы MAIN и BASE подключены к первым, а концентраторы и пользователи — ко вторым. Предположим также, что в сети используются различные типы протоколов, такие, как TCP/IP, NetBEUI/ NetBIOS и IPX/SPX. Для простоты описания эксперимента мы будем считать, что центральный коммутатор имеет зеркальный порт (mirror port), куда можно перенаправлять трафик с любого порта центрального коммутатора для его анализа. Замечание №3. Первым этапом стрессового тестирования сети является оценка работоспособности основных устройств в условиях высоких пиковых нагрузок. Тестированию целесообразно подвергать не все устройства, а только те, что имеют важное значение с точки зрения пропускной способности и надежности сети. Мы обычно называем этот этап тестирования " калибровкой главного устройства сети". Поскольку в сети, изображенной на Рисунке 2, надежность центрального коммутатора определяет надежность всей сети, то мы должны знать, какова способность центрального коммутатора выдерживать высокие пиковые нагрузки и какова при этом будет поддерживаемая скорость для разного типа трафика. Основной интерес представляет не само значение пропускной способности, выраженное в Мбит/с, а возможность потери кадров коммутатором. Значение совокупной пропускной способности устройства (aggregate bandwidth), которое производители приводят в документации, мало информативно, так как документация обычно умалчивает о том, при каких условиях и для какого типа трафика проводились измерения. Наверняка эти условия были наилучшими для данного устройства. Кроме этого, важное значение имеет оценка вероятности того, что при определенных условиях какой-то порт коммутатора отключится из-за высокой нагрузки (что иногда и происходит), и коммутатор необходимо будет перезапустить в " холодном режиме". Чтобы получить достоверные результаты, эксперимент по стрессовому тестированию сети должен быть правильно спланирован. Одним из возможных сценариев является описанный ниже. Центральный анализатор протоколов (Distributed Observer) подключается к зеркальному порту коммутатора, куда по очереди перенаправляется трафик с разных доменов сети. Удаленные агенты устанавливаются по одному в каждый коллизионный домен тестируемой конфигурации и настраиваются только на генерацию конкретного типа трафика в заданном направлении (по конкретным МАС-адресам). Если станции домена А должны работать c сервером MAIN по протоколу TCP/IP, то агент домена А надо настроить на генерацию TCP-трафика (далее тестовый трафик) в домен сервера MAIN. При этом генерация трафика должна осуществляться не по MAC-адресу сервера MAIN, а на MAC-адрес специально установленной для данных целей станции. Такую станцию будем называть " Приемником". Задача станции " Приемник" состоит в снятии нагрузки с сервера, так как в данном эксперименте мы проверяем устойчивость работы коммутатора, а не сервера. Для организации встречного трафика из домена MAIN в домен А удаленный агент анализатора из домена MAIN должен быть настроен на генерацию TCP-трафика по МАС-адресу станции " Приемник" из домена А. При этом генератор трафика лучше не устанавливать на сервер MAIN, дабы не создавать ему дополнительную нагрузку. Аналогично все остальные агенты настраиваются на генерацию тестового трафика интересующих вас протоколов. Чтобы создать наихудшие для коммутатора условия, размер кадров можно установить равным минимально допустимому. Чем больше портов коммутатора и, соответственно, удаленных агентов анализатора протоколов будет участвовать в эксперименте, тем большую нагрузку вы создадите и, соответственно, более точные результаты получите. Настроив и запустив генерацию тестового трафика со всех удаленных агентов, на ее фоне следует запустить одно или несколько приложений, которые вы планируете использовать в сети. Тем самым вы дополнительно проверите устойчивость работы приложений к высоким нагрузкам в сети. Например, какое-нибудь приложение, работающее с сервером MAIN, можно запустить на станции BOSS, находящейся в домене А. При этом центральный анализатор протоколов должен поочередно настраиваться на сбор и запись в файл трафика со всех портов коммутатора, где работают приложения: сначала из домена А, затем из домена MAIN, и так далее по всем доменам тестируемой конфигурации. Теоретически центральный анализатор протоколов можно установить в одном из доменов сети, а каждый удаленный агент — заставить одновременно с генерацией трафика производить запись трафика. Но этого делать не рекомендуется, так как в этом случае нет гарантии того, что агент, производящий генерацию трафика, не окажется перегружен и не будет терять кадры. После сбора и запаси в файлы пакетов со всех портов коммутатора они обрабатываются, например, с помощью программы NetSense for Observer. Цель обработки — определение числа повторно переданных пакетов на транспортном уровне во время работы конкретного приложения. Колонка Е (см. Рисунок 3) показывает число зафиксированных повторных передач пакетов при работе станции BOSS с сервером MAIN. Именно число повторно переданных пакетов является тем интегральным критерием, который свидетельствует о потере кадров.
    Рисунок 3. Режим Client/Server Expert программы NetSense for Observer (колонка Е) показывает число переповторов транспортного уровня, которые произошли при работе станции BOSS с сервером MAIN. Именно число переповторов является интегральным критерием, который свидетельствует о потере кадров.

Обнаружив потерю кадров, вы должны определить причину. В общем случае причин может быть несколько: перегрузка коммутатора, искажение данных при их передаче по каналу связи, слишком большое число эмулируемых коммутатором коллизий (эффект back pressure), несоблюдение коммутатором стандарта CSMA/CD. Эффект back pressure заключается в эмулировании коммутатором коллизий при перегрузке входного буфера. Вследствие этого после 16 последовательных коллизий драйвер сетевой платы на компьютере, где работает приложение, прекратит передачу кадра. Несоблюдение коммутатором стандарта CSMA/CD заключается в том, что коммутатор не выдерживает паузы в 9, 6 микросекунд перед посылкой очередного кадра. В результате коммутатор будет непрерывно передавать данные, и никакая другая станция в этот момент в канал связи выйти уже не сможет. Такой эффект называется " блокировкой канала".

Поэтому при обнаружении повторных передач на транспортном уровне тот же самый трафик должен быть проанализирован с целью определения числа ошибок и повторных передач на канальном уровне. Это также может быть сделано с помощью программы NetSense for Observer (см. Рисунок 4). В результате анализа трафика вы сможете установить причину потери кадров от приложения на станции BOSS.

  Рисунок 4. Режим DLC Error Expert программы NetSense for Observer позволяет определить число ошибок канального уровня и число переповторов канального уровня, которые произошли при работе станции BOSS (МАС-адресс WstDigEC4A8E). Переповторы канального уровня могут быть следствием как ошибок, так и коллизий.

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

Замечание №4. Значения параметров тестового трафика, при которых повторная передача пакетов на транспортном уровне дает о себе знать, могут служить в качестве ориентира при наблюдении за работой сети в процессе ее эксплуатации (для упреждающей диагностики). Эти значения с запасом в 10% должны быть введены как пороговые в диагностическое средство. Если в процессе эксплуатации сети значения параметров трафика превысят пороговые значения, то диагностическое средство информирует об этом событии администратора сети.

Нам часто задают вопрос, почему при низкой утилизации портов коммутатора (чаще всего Fast Ethernet или FDDI) и при отсутствии канальных ошибок сеть тем не менее периодически сбоит. Ответ прост. Наблюдение утилизации портов с помощью telnet или программ на базе SNMP дает усредненное, а не пиковое значение утилизации — так уж устроены SNMP-агенты. Однако именно при пиковых значениях утилизации коммутатор или станции могут терять кадры, вследствие чего пакеты передаются повторно на транспортном уровне.

Замечание №5. Вторым этапом стрессового тестирования сети является оценка устойчивости сервера и рабочих станций к высоким нагрузкам в сети.

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

Второй этап следует проводить после установки и подключения рабочих станций пользователей. Стрессовая нагрузка, которой сеть подвергается на втором этапе, должна быть на 10–15% меньше нагрузки, при которой пакеты на первом этапе начали повторно передаваться на транспортном уровне. Это даст вам гарантию того, что повторная передача вызывается отнюдь не потерей кадров в коммутаторе. Для этого на станциях пользователей в разных доменах сети необходимо одновременно с работой приложений запустить стрессовый тест типа Perform3 или FTest. В зависимости от размеров сети тест следует запускать в одном или нескольких доменах одновременно.

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

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

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

ДИАГНОСТИКА СЕТИ Все многообразие средств, предназначенных для диагностики сетей, можно условно разделить на две категории в зависимости от принципа их работы: средства мониторинга и управления работой сети (далее средства мониторинга — monitoring software) и анализаторы сетевых протоколов (далее анализаторы протоколов — analyzers). Принцип работы средств мониторинга основан на взаимодействии консоли оператора с так называемыми агентами, которые, собственно, и занимаются мониторингом и управлением работой устройств сети. Примерами средств мониторинга являются программы Transcend компании 3Com, Optivity компании Bay Networks (ныне Nortel), HP OpenView Net Metrix. Подобные средства имеют множество достоинств, о чем написано достаточно много и совершенно справедливо. В данной статье мы будем рассматривать средства мониторинга только с точки зрения их применения для диагностики сети. Агенты могут быть встроены в оборудование или загружены программным образом. Поскольку наиболее распространенным протоколом общения консоли оператора и агентов является SNMP, такие агенты часто называют SNMP-агентами. SNMP-агенты могут выполнять самые различные функции в зависимости от типа баз управляющей информации (Managеment Information Base, MIB), которые они поддерживают. Эти функции могут включать в себя управление конфигурацией устройства, в которое агенты встроены (configuration management), управление контролем доступа к информации (security managеment), анализ производительности устройства (perfomance managеment), измерение числа ошибок при передаче данных (fault management) и другие. Замечание №6. С точки зрения проведения диагностики сети с помощью средств мониторинга особое значение имеют следующие факторы: поддержка SNMP-агентами всех групп RMON MIB и наличие развитых функций по декодированию группы сбора пакетов RMON MIB. При покупке активного оборудования особое внимание прежде всего следует обращать на то, какие базы управляющей информации поддерживают встроенные SNMP-агенты. Наибольшие возможности с точки зрения диагностики имеют SNMP-агенты, поддерживающие RMON MIB (RFC 1757). В этом случае в процессе эксплуатации сети вы сможете получать достоверную статистику по всем типам ошибок канального уровня. Если агенты не поддерживают RMON MIB, то информация об ошибках канального уровня обычно доступна только через Enterprise MIB. Enterprise MIB — это нестандартная база производителя оборудования. По этой причине интерпретация каких-то типов ошибок может быть не всегда корректна. Например, короткие кадры одни производители могут интерпретировать как коллизии, а другие — как короткие кадры. Вся база управляющей информации RMON MIB разбита на 9 разделов или групп. Каждая группа отвечает за сбор определенной информации. Например, Statistics Group отвечает за сбор информации об ошибках канального уровня, Host Group — за сбор информации о трафике и т. д. Особое значение в эффективной организации диагностики сети имеет последняя группа Packet Capture. Поддержка устройством этой группы дает возможность производить сбор трафика в сети для дальнейшего анализа и таким образом выявлять сбои в протоколах сетевого, транспортного и прикладного уровней, что особенно важно для диагностики. К сожалению, в настоящее время встроенные в оборудование SNMP-агенты не всегда поддерживают все 9 групп, и реже всего именно эту группу. Обычно сбор пакетов осуществляется только специальными аппаратными SNMP-агентами. Развитые функции средств мониторинга по декодированию собранных пакетов повышают их эффективность при проведении упреждающей диагностики сети. К сожалению, очень немногие (в основном, только дорогие) средства мониторинга отображают информацию о собранных пакетах в удобной для анализа форме. Так, например, одна из наиболее распространенных программ сетевого мониторинга — программа Transcend for Windows компании 3Com — представляет информацию о содержимом собранных пакетов только в шестнадцатеричном виде, что очень неудобно. Замечание №7. Если оборудование вашей сети поддерживает все группы RMON MIB, средства мониторинга имеют развитые функции по декодированию собранных пакетов, и вы знаете, как значения наблюдаемых параметров влияют на работу вашей сети, то средства мониторинга позволяют осуществлять очень эффективную упреждающую диагностику сети. Если же хотя бы одно из перечисленных условий не выполняется, то эффективность использования средств мониторинга заметно снижается. Поскольку предварительное тестирование сети перед вводом в эксплуатацию проводится отечественными системными интеграторами очень редко и не все оборудование имеет встроенные SNMP-агенты с поддержкой всех групп RMON MIB, то в большинстве случаев дорогостоящие средства мониторинга используются неэффективно или вообще не используются. Однако, даже при соблюдении всех вышеперечисленных условий, средства мониторинга недостаточны для проведения реактивной диагностики сети.
Реактивная диагностика При реактивной диагностике сети с помощью средств мониторинга измерительным прибором является SNMP-агент самого диагностируемого устройства. Однако при появлении сбоев показания SNMP-агента нельзя считать достоверными. Это особенно актуально, когда сбои происходят в самом устройстве с установленным SNMP-агентом. В таких случаях наблюдатель должен быть " независим" от диагностируемого устройства. SNMP-агент устройства наблюдает за коллизионным доменом сети всегда только из одной точки и, что особенно важно для реактивной диагностики, не имеет возможности производить генерацию тестового трафика. В результате если не все оборудование имеет встроенные агенты, то часть ошибок канального уровня в домене сети может не фиксироваться. Емкость буфера для сбора пакетов у SNMP-агентов с поддержкой группы Packet Capture ограничена. Например, для концентраторов SuperStack II компании 3Com — 500 Кбайт. Этого часто недостаточно для локализации сложных дефектов в сети. Замечание №8. С точки зрения реактивной диагностики, т. е. возможности быстрой локализации дефектов в сети, применение анализаторов сетевых протоколов оказывается предпочтительным. Они представляют собой значительно более мощное средство по сравнению со средствами мониторинга сети, так как лишены всех перечисленных выше недостатков. Именно возможность эффективного проведения реактивной диагностики является сегодня актуальной задачей для администраторов сетей. Кроме того, работа с анализатором сетевых протоколов весьма поучительна. Принцип работы анализатора протоколов отличается от принципа работы средства мониторинга сети. Анализатор сетевых протоколов исследует весь проходящий мимо него сетевой трафик. Локальные сети по своей природе являются широковещательными, т. е. каждый кадр от любой станции в пределах коллизионного домена видят все станции этого домена сети. Подключая анализатор к любой точке коллизионного домена сети, вы будете видеть весь трафик в этом домене. Анализаторы протоколов предоставляют возможность собирать данные о работе протоколов всех уровней сети и, в большинстве случаев, способны производить генерацию тестового трафика в сеть. Имея большой буфер для сбора пакетов, анализаторы протоколов позволяют быстро локализовать причину сбоя в сети: например, обнаружить факт перегрузки конкретного сервера, бесследное исчезновение пакетов транспортного уровня на неисправных сетевых платах, коммутаторах и маршрутизаторах, IP-пакеты с неправильной контрольной суммой, дубликаты IP-адресов и многое другое. Анализаторы протоколов можно разделить на две категории: программные и аппаратные (или программно-аппаратные). Программный анализатор — это программа, которая устанавливается на компьютер с обычной сетевой платой. Анализатор протоколов переводит сетевую плату компьютера в режим приема всех пакетов (promiscous mode). Примерами программных анализаторов протоколов являются Observer и Distributed Observer компании Network Instruments, NetXray компании Network Associates, LANalyzer for Windows компании Novell и многие другие. Замечание №9. При проведении диагностики сети с помощью программного анализатора протоколов особое значение имеют типы сетевой платы и драйвера, на которых программному анализатору протоколов приходится работать. Типы сетевой карты и типы драйвера определяют возможность программного анализатора протоколов фиксировать ошибки в сети на канальном уровне. Если программный анализатор протоколов установлен на компьютере, сетевая плата или сетевой драйвер которого не умеют фиксировать ошибки на канальном уровне, вы не сможете получить достоверную картину наличия ошибок в вашей сети. В этом случае анализатор протоколов нельзя эффективно использовать, так как он может показывать, что ошибок в сети очень мало, в то время как на самом деле их может быть очень много. Ситуация еще усугубляется следующим фактом. Анализатор протоколов может сообщать, что драйвер умеет фиксировать ошибки канального уровня, тогда как в действительности же он их не фиксирует. Информация о том, какой тип ошибок может фиксировать конкретный тип драйвера при использовании конкретного типа сетевой платы, не является, к сожалению, общедоступной. Таким способом производители программных анализаторов протоколов пытаются защитить себя от хакеров и любителей нелицензионного ПО. Господам хакерам и любителям использовать демонстрационные версии продуктов для диагностики своих сетей следует об этом помнить. Если найти нелицензионную копию какого-то программного анализатора протоколов или " вскрыть" защиту при большом желании не составляет особого труда, то узнать, какой тип драйвера с каким типом сетевой платы предоставляет достоверную информацию об ошибках в сети, — задача отнюдь не тривиальная. Не имея проверенной информации подобного рода, проводить диагностику сети вообще не имеет смысла, так как полученные результаты не будут отражать реальное состояние сети. Аппаратный анализатор протоколов — это специализированный прибор или специализированная сетевая плата. И в том и в другом случае аппаратный анализатор имеет специальные аппаратные средства, с помощью которых он может проводить более детальную диагностику сети, чем при использовании программного анализатора. Аппаратные анализаторы выпускаются компаниями Network Associates, NetTest, Hewlett-Packard, RadCom, Wandel& Goltermann и другими. Аппаратные анализаторы протоколов имеют возможность очень точно выявлять все дефекты канального уровня. Кроме этого, многие аппаратные анализаторы производят экспертный анализ трафика " на лету", т. е. в момент сбора пакетов. При использовании программного анализатора протоколов пакеты необходимо сначала собрать, и только потом полученную информацию можно анализировать с помощью специальной программы. Замечание №10. Если задача состоит только в диагностике локальной сети, то предпочтение следует отдать программному анализатору протоколов. Если вы планируете проводить диагностику как локальных, так и телекоммуникационных сетей (ATM, SDH, frame relay и т. п.), то лучше выбрать аппаратный анализатор протоколов. С точки зрения диагностики локальной сети преимущества аппаратных анализаторов по сравнению с программными анализаторами несоизмеримы с разницей в цене между ними. Аппаратные анализаторы стоят, как правило, более чем в 15—20 раз дороже, чем программные. Именно по этой причине в настоящее время новые модели аппаратных анализаторов, предназначенные для диагностики только локальных сетей, уже не разрабатываются. Большинство выпускаемых в настоящее время аппаратных анализаторов представляет собой базовую модель (шасси) и набор модулей, каждый из которых предназначен для диагностики конкретного типа сети, как локальной, так и телекоммуникационной. Анализаторы протоколов могут быть локальными, т. е. предназначенными для диагностики только одного домена сети, или распределенными. Последние позволяют одновременно проводить анализ большого числа (как минимум двух) доменов сети. Примером программного локального анализатора может служить LANalyzer for Windows компании Novell. Примером программного распределенного анализатора протоколов — Distributed Observer компании Network Instruments. Большинство аппаратных анализаторов протоколов являются, как правило, локальными. Исключение составляет Distributed Sniffer. Распределенный анализатор протоколов представляет собой центральный анализатор и набор удаленных агентов, каждый из которых взаимодействует с центральным анализатором по специальному протоколу. В отличие от SNMP-агента, агенты распределенного анализатора являются полноценными анализаторами протоколов. Единственное их отличие от центрального анализатора заключается в том, что они не выводят собираемую ими информацию на экран компьютера, на котором работают. Вся собираемая информация передается по сети на центральный анализатор. Передача информации от агентов на центральный анализатор производится не постоянно, а только по запросу от центрального анализатора. По этой причине трафик между центральным процессором и удаленными агентами оказывается очень незначительным. Чаще всего агенты программного распределенного анализатора протоколов являются сервисами NT или процессами под Windows 95. Таким образом, они могут работать на компьютерах обычных пользователей, не мешая им и одновременно диагностируя домен сети, куда они подключены. Замечание №11. Для реактивной диагностики сети распределенные анализаторы протоколов имеют ряд существенных преимуществ перед локальными. Кроме этого, распределенные анализаторы протоколов в большинстве случаев не уступают средствам мониторинга сетей при проведении упреждающей диагностики, особенно в тех случаях, когда не все оборудование оснащено встроенными SNMP-агентами с поддержкой всех групп RMON MIB. Первое преимущество распределенного анализатора перед локальным очевидно: чтобы провести диагностику каждого домена сети, анализатор протоколов не нужно переносить или переключать из домена в домен. Однако он имеет и другие преимущества. Замечание №12. Для локализации ряда дефектов сети необходимо одновременно наблюдать за двумя и более сегментами (коллизионными доменами) сети. Это можно сделать только с помощью распределенного анализатора протоколов. Данное замечание лучше всего пояснить на примере. Предположим, что в локальной сети, изображенной на Рисуноке 5, станция BUCH, расположенная в домене А, периодически " зависает" (работает неустойчиво). При этом зависание происходит в непредсказуемые моменты времени.
  Рисунок 5. Часто достоверно определить причину неустойчивой работы станции BUCH, можно только путем анализа канальных трасс, снятых в одно и то же время в домене А и домене В.

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

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

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

КАЖДОМУ СВОЕ Следует сказать, что в данной статье мы рассмотрели далеко не все средства реактивной диагностики сетей. За рамками публикации остались мощные аппаратные средства компании Fluke, широкий спектр различных экспертных систем и многое другое. Завершая краткий обзор, мы хотели бы привести диаграмму, на основании которой читатель может судить о том, в какой степени каждое из рассмотренных выше средств позволяет решить задачи упреждающей и реактивной диагностики локальных сетей (см. Рисунок 6). Прямоугольники в нижней части рисунка символизируют задачи реактивной и упреждающей диагностики, а зонтики — средства решения данных задач.
  Рисунок 6. Прямоугольники в нижней части рисунка олицетворяют собой задачи реактивной и упреждающей диагностики. Зонтики - это средства, которые в разной степени закрывают собой решение данных задач.

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

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

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

При выборе в качестве критерия интегрального показателя (стоимость+возможности решения задач реактивной и упреждающей диагностики), наилучшими характеристиками, с нашей точки зрения, обладают распределенные анализаторы протоколов. Они иногда уступают средствам сетевого мониторинга в решении вопросов упреждающей диагностики — прежде всего, в тех случаях, когда сеть построена на базе коммутатора, у которого нет зеркального порта и отсутствуют агенты для конкретного типа ОС. Однако тенденция их развития такова, что в ближайшем будущем этот недостаток будет устранен. Так, например, компания Network Instruments объявила о выходе новой версии анализатора Distributed Observer с поддержкой SNMP-агентов с RMON MIB.

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

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

ЗАКЛЮЧЕНИЕ На протяжении ряда лет большинство вопросов повышения производительности и надежности сетей решалось закупкой новой техники. Не всегда подобное решение было технически и экономически обоснованно, но почти всегда оно позволяло достигнуть желаемой цели — сеть начинала работать быстрее и лучше. При наличии 200% запаса пропускной способности практически все " узкие места" можно без труда " расширить", а приобретая только самое дорогое оборудование лидеров сетевых технологий, вы можете с большой степенью вероятности обезопасить себя от " скрытых дефектов". Сегодня в связи с кризисом ситуация изменилась, поэтому и экономическое обоснование проектов по модернизации сетей становится актуальным. Мировой опыт показывает, что инвестиции в профессионализм специалистов дают большую отдачу, чем инвестиции в " железо", даже очень хорошее. Необходимую пропускную способность сети или ее надежность нельзя оценить без детального анализа ее нынешнего состояния. Это можно сделать только посредством диагностических средств, а главное — с помощью высокопрофессиональных администраторов сетей, вооруженных этими средствами.

 



Ускорение работы сети

Ещё одна распространенная проблема — медленная работа Windows XP с сетью. Тут особо отличились некоторые антивирусы, например антивирус Касперского, очень сильно затрудняющий работу с сетевыми папками. Для того, чтобы избавиться от этой проблемы, недостаточно выгрузить из памяти антивирусный монитор — нужно ещё остановить службу KAV Monitor Service. Разумеется, риск подцепить вирус при этом повышается.

Замечено также, что после установки пакета обновлений Rollback 1 Проводник начинает серьезно «тормозить» при просмотре сетевых папок. Помочь в этом случае может удаление ярлыков в папке My Network Places или возврат к более старой версии файла shell32.dll. Также для ускорения обзора сетевых ресурсов удалите в реестре раздел HKEY_LOCAL_MACHINE\ SOFTWARE\ Microsoft\ Windows\ CurrentVersion\ explorer\ RemoteComputer\ NameSpace\ {D6277990-4C6A-11CF-8D87-00AA0060F5BF} — он отвечает за использование Планировщика Заданий в работе с удалённым ПК и несколько замедляет работу с Проводником в сети (там же могут быть и другие ключи, например, принтера — можно попробовать удалить и их). Попробуйте также отключить поддержку динамической файловой системы, которая тоже может замедлять работу, для чего создайте такой параметр в реестре:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Mup\
" DisableDFS" =DWORD: 00000001

Иногда полезно также установить в реестре такой параметр:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters
" SizReqBuf" =" 14596"

(тип DWORD, десятичное значение, возможные значения параметра — 512—65536, оптимально обычно устанавливать 14596).

Для некоторого ускорения работы можно попробовать подключать сетевые папки как сетевые диски, а также создать в папке WINDOWS\SYSTEM32\DRIVERS\ETC файл LMHOST (без расширения) с таким примерно содержанием:

192.168.0.101 Computer1
192.168.0.100 Computer2

То есть пропишите в нём все IP-адреса вашей сети и соответствующие им имена компьютеров (использование файла LMHOSTS должно быть разрешено в настройках соединения). Кстати, путь к этому файлу можно изменить в разделе реестра HKEY_LOCAL_MACHINE\ SYSTEM\ CurrentControlSet\ Services\ Tcpip\ Parameters — проверьте значение параметра DataBasePath типа REG_EXPAND_SZ.

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


 





Резервные копии

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

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

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

Переключение по отказу

Переключение по отказу (fail-over) обеспечивает восстановление информации и сохранение производительности. Системы, настроенные подобным образом, способны обнаруживать неисправности и восстанавливать рабочее состояние (выполнение процессов, доступ к информации или соединениям) автоматически с помощью резервных аппаратных средств.

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

Примечание

Механизмы обеспечения доступности являются самыми дорогими средствами безопасности в организации. Чтобы определить состав необходимых аппаратных средств, важно учесть требования соответствующих процедур управлением риском (см. в " Управление риском" ).

Предотвращение атак

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

 

 

 

 

Назначение компьютерных сетей

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

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

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

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

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


Поделиться:



Последнее изменение этой страницы: 2019-06-19; Просмотров: 766; Нарушение авторского права страницы


lektsia.com 2007 - 2024 год. Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав! (0.922 с.)
Главная | Случайная страница | Обратная связь