Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:

Bileti_po_AvIS / Avis_bilet_02

.doc
Скачиваний:
39
Добавлен:
27.04.2015
Размер:
52.74 Кб
Скачать

Билет №2.

1. Вопрос 1. Модели управления открытыми системами: TMN. ITIL. FCAPS.

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

TMN Telecommunication Management Network.- описана в М.3010

Стандартизирующая организация ITU создала модель управления и администрирования TMN – Telecommunication Management Network. TMN создавалась для телекоммуникационных компаний (операторов связи).

Нужно создавать сеть, чтобы управлять всем остальным.

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

Управление и объектами, и процессами.- это то, из-за чего не исп-ся

Объект- иерархическая структура.

- уровень элементов сети.- оборудование (сервера, коммутационное оборудование)

- уровень управления элементами (ОС).

- уровень управления сетью. (сетевая ОС)

- уровень управления услугами. (сопровождение услуг)

- уровень управления бизнесом.

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

Функции можно разбить на 4 класса:

  1. конфигурация элементов;

  2. проблема производительности и поиска ошибок;

  3. администрация приложений (сервисов);

  4. управление бизнесом.

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

В конце 90-х годов ITU решили, что они будут использовать модель FCAPS, разработанную ISO.

ITIL

Модель управления инф системами ITIL (IT Infrastructure Library) была создана английским правительством для описания управления бизнес-процессами IT-компаний. т.к были большие потери бизнеса

В 80-х годах XX-го столетия Британское правительство создало агентство OGC (Office of Government Commerce), которое занялась разработкой модели эффективного управления IT-службами и ресурсами. Целью было создание рекомендаций для организаций, работающих в области IT. Результатом работы стала библиотека решений ITIL - IT Infrastructure Library-что надо делать для осущ-я IT-услуг. Основная модель управления IT-услугами. Процессы разделены на 3 группы:

- стратегические (организация IT-служб)

- тактические (планирование и контроль IT-услуг)

- оперативн управления (поддержка IT-услуг)

Существует 10 базовых процессов управления для поддержки и предоставления IT-сервисов.

  1. процесс управления и инициализирования

  2. - // - управления проблемами

  3. - //- управления конфигурациями

  4. -//- управления изменениями

  5. - // - релизами

  6. - // - уровнем услуг

  7. - // - мощностью

  8. - // - доступностью

  9. - // - непрерывностью

  10. - // - безопасностью

  11. процесс финанс управления

  12. служба HELP DESC

Пользователь системы- заказчик IT-услуг.

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

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

В современных крупных компаниях применяется модель ITIL

eTOM: TMF (Tele Management Forum)- создали модель функционирования инф сист для оператора связи- eTOM. Более новое решение, чем ITIL. Говорит, какие процессы должны работать в компании оператора связи, какие долж быть прикладн и системн процессы. Полностью отражает все аспекты деятельности оператора связи. Представлена архитектура для классификации и систематизации бизнес-процессов компании связи.

4 основных процесса:

- бизнес-процессы, котор представляют потоки работ и требов к инф

- 2 гр. процессов отражает моделирование системн решения

- 3 гр процессов добавляет параметры внедрения и автоматизац

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

На базе модели eTOM делаются сист сопровождения и поддержки у операторов связи- BSS(Business Service Support) /OSS (Operation Service Support). Прикладная часть создается согласно тем процессам, котрые для отрасли связи определил eTOM.

М.3050- рекомендации ITU. Здесь повторяются основные документы eTOM.

Центральный документ: eTOM TMF GB921

FCAPS

Это на сегодняшний день основная модель. ЩЫШ очнулась и решила сделать что-то современное.

ISO разработала свою модель FCAPS (Fault Configuration Account Performance Security), в которой все объекты – данные. Эта модель ограничивается перечисленными в аббревиатуре функциями, т.е. решает задачи:

– поиска неисправностей;

– конфигурации;

– учёта;

– производительности;

– защиты от несанкционированного доступа.

Эта модель администрирования наиболее распространена.

В ней не рассмотрены все функции администрирования, выделены следующие 5 функций:

  1. Fault – диагностика и поиск неисправностей;

  2. Configuration – конфигурация. В современных устройствах все управление осуществляется с помощью ПО. Пусть, например, в сети 250 пользователей, на них приходится примерно 9 серверов и 10 коммуникационных устройств, у каждого из которых около 300 параметров, которые нужно настроить. Поэтому конфигурация в этой средней система представляется весьма трудоемкой задачей.

До 50 портов – маленькая система;

До 800 портов – средняя система;

Более 800 портов – большая система;

  1. Account – учет. Должны быть решены проблемы аудита: кто и когда работает, с какими ресурсами и имеет ли на это право (но задача не включает учета стоимости ресурсов);

  2. Performance – производительность. Сбор статистики, мониторинг, оптимизация, метрики измерения производительности системы. Главное – понять, по каким именно параметрам (критериям) считать производительность системы. Эти критерии называются метриками;

  3. Security – безопасность. Решение задач и функций защиты от НСД. По мнению OSI это наиболее простая из всех задач.

Эта модель не включает в себя никаких бизнес-функций.

Вопрос №2. Дайте методику обнаружения ошибок в системах передачи данных.

Разработчики ИС дают базовую модель поиска ошибок:

Есть базовые правила поиска ошибок:

  1. Убедиться в том, что ошибки действительно есть (не смотрим никаких журналов и т.д.);

  2. Провести инвентаризацию (при этом NMS может помочь, а может и не помочь, она дает план системы). У администратора должен быть worksheet - там карта сети и все параметры. Нужно убедиться, что все на месте и согласно плану;

  3. Остановить все и сделать backup. Причем не пользуемся утилитой backup-ирования, а копируем «том в том» или «диск в диск»;

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

  5. Если система загрузилась, нужно проверить права и привилегии, версии ПО (никогда не работаем на последней версии), нужно убедиться в том, что никто из пользователей не поставил себе никаких обновлений (хотя и непонятно, как у него это могло получиться);

  6. Смотрим журналы (логии- syslog);

  7. Записываем, что могло быть- строим гипотезы, т.е. по каким причинам может не работать (внешние шумы, возросли объемы информации);

Можно строить от прикладного уровня к физическому, и наоборот. А можно и по-другому:

Самые частые ошибки (1 место)- кабельные

2 место- ошибки прикладного софта

3 место- ошибки системного софта

4 место- ошибки hardware

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

  2. Задокументировать и коррелировать.

Есть две стратегии выявления ошибок: активная и пассивная.

Пассивная. После того, как что-нибудь уже случилось, посылаем сообщения по SNMP.

Активная. NMS посылает команды по сети и смотрим, что МОЖЕТ случиться. Протокол UDP или ICMP.

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

Нужно решить, сколько часов в сутки система должна работать. Это определяется SLA (Service Level Agreement).

Например, из 20 из 24 часов. Если это требование выполняется, считается, что ошибок нет.

Соседние файлы в папке Bileti_po_AvIS