Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Ответы Сети ЭВМ.docx
Скачиваний:
2
Добавлен:
01.04.2025
Размер:
3.84 Mб
Скачать
  1. Управление сетями. Иерархия протоколов tmn.

Это пирамида — логическая многоуровневая архитектура (LLA — Logical Layered Architecture) классифицирует задачи по сложности управляемых элементов (от отдельных устройств на сети до межкорпоративных сетей). Пирамида уровней системы управления TMN показана на рис. На рисунке условно показаны составляющие каждого уровня и их возможные взаимосвязи.

Уровень сетевых элементов (NEL — Network Element Layer) играет роль интерфейса между базой данных со служебной управляющей информацией (MIB — Management Information Base), находящейся на отдельном устройстве, и инфраструктурой TMN. Эта база данных относится к таким сетевым элементам, как, например, коммутационные станции, системы передачи, мультиплексоры, комплекты тестового оборудования. К нему относятся Q -адаптеры и собственно сетевые элементы, которые согласуют работу сети связи и TMN.

Уровень управления элементами (EML — Element Management Layer) соответствует системам поддержки функционирования (OSS), контролирующим работу групп сетевых элементов. Этот уровень позволяет управлять группами сетевых элементов. На этом уровне реализуются управляющие функции, которые специфичны для оборудования конкретного производителя, и эта специфика маскируется от вышележащих уровней. Примерами таких функций могут служить выявление аппаратных ошибок, контроль энергопотребления и т.д.

Уровень управления сетью (NML — Network Management Layer) формирует представление сети в целом, базируясь на данных об отдельных сетевых элементах, которые передаются системами поддержки операций предыдущего уровня.

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

Уровень бизнес-управления (BML — Business Management Layer) рассматривает сеть связи с позиций общих бизнес-целей компании-оператора. Здесь речь идет о проектировании сети и планировании ее развития с учетом бизнес-задач, о составлении бюджетов и пр.

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

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

  • устранение неисправностей;

  • управление качеством;

  • управление конфигурацией;

  • управление безопасностью;

  • управление расчетами.

  1. Управление сетями. Существующие методы мониторинга.

Методы мониторинга состояния сети

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

  1. проверка физической доступности оборудования;

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

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

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

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

Следующий этап – проверка принципиальной работоспособности критичных служб. Как правило, это означает TCP-подключение к соответствующему порту сервера, на котором должна быть запущена служба, и, возможно, выполнение тестового запроса (например, аутентификации на почтовом сервере по протоколу SMTP или POP или запрос тестовой страницы от веб-сервера).

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

Наконец, многие окружения требуют специфических проверок – запросов к БД, контролирующих работу некоего приложения; или значений настроек; отслеживание наличия некоторого файла (например, создаваемого при «падении» системы).

Контроль безопасности сети

Безопасность компьютерной сети обеспечивается двумя методами: аудитом и контролем. Аудит безопасности – проверка настройки сети (открытых портов, доступности «внутренних» приложений извне, надежности аутентификации пользователей);

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

  • нагрузку на серверное ПО и «железо»;

  • журналы и отчеты на наличие ошибок;

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