Вопросы к экзамену (не скрины учебника а сам текст) / Источники-книги / Администрирование_в_информационных_системах_Беленькая_М_Н_

—ASA (Average Speed To Answer) — среднее время (обычно в секундах), требующееся для ответа на поступивший звонок;

—TSF (Time Service Factor) — число звонков (в процентах), обслуженных за определенный временной период (например 80 % за 20 с);

—FCR (First Call Resolution) — число звонков (в процентах), сообщающих о проблемах, которые могут быть решены без повторного звонка.

Обычно SLA содержит перечисленные ниже разделы. Services (услуги). Информация этого раздела SLA определя-

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

Performance Management (управление производительностью). Ключевая часть SLA, включает в себя мониторинг и измерение уровня качества поставляемых услуг. Каждая услуга должна быть измеряема и должна существовать возможность анализа результатов этого измерения. Все метрики, используемые для измерения, должны быть представлены в договоре.

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

Customer Duties and Responsibilities (обязанности и ответственность пользователя). В этом разделе оговариваются обязанности и ответственность пользователя.

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

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

Disaster Recovery and Business Continuity (восстановление после аварий и непрерывность бизнеса) могут иметь критическое значение. Этот факт должен быть отражен в договоре.

Termination (прекращение действия договора). Этот раздел SLA обычно содержит следующие ключевые темы: завершение оказания услуги в конце установленного срока, завершение оказания услуги для удобства клиента, завершение оказания услуги по какой-либо причине, взаиморасчеты.

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

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

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

11.4.Технические и бизнес-метрики

âсовременных сетевых технологиях

Всовременных ИС применяется комбинация бизнес- и технических метрик. Приведем ее на примере технологии MetroEthernet. Рекомендации по использованию различных метрик ведущей организации по разработке стандартов Ethernet MetroEthernet Forum (MEF) описаны в специальных документах Technical specification — MEF 10.1.1. Traffic management specification — MEF 5, MEF service model — MEF1 и пр.

Сетевым службам администрирования систем следует изучить эти документы.

Рассмотрим некоторые из указанных форумом метрик.

Задержки (Frame Delay Ratio). Задержка — критичный параметр, имеющий большое значение для приложений, работающих в реальном масштабе времени. Этот параметр уже рассматривался как техническая метрика для 100 Base Ethernet. В документах форума приведен теоретический расчет данного параметра для Metro Ethernet. На практике достаточно проблематично рассчитать подобную метрику (особенно учитывая сложность современных систем).

Потери фреймов FLR (Frame Loss Ratio). Потери фреймов — это доля фреймов, не доставленных получателю, от общего числа переданных фреймов за отчетный период (час, день, месяц).

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

Соответственно потери могут по-разному влиять на качество обслуживания QoS в зависимости от приложений, услуг или телекоммуникационных протоколов высокого уровня, используемых для обмена информацией. Например, потери, не превышающие 1%, приемлемы для приложений типа Voice over IP (VoIP) [14], однако их увеличение до 3 % делает невозможным предоставление этого сервиса.

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

Математические описания FLR также представлены в документах форума.

Вариации задержки FDV (Frame Delay Variations) — это один из критичных параметров для приложений, работающих в режиме реального времени.

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

Пропускная способность (Throughput) рассматривалась в разделе 11.2.

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

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

Время подъема системы (Uptime). Эта метрика обсуждалась в главе 8.

Доступность услуги (Service Availability) оказывает прямое влияние на фактическое качество услуги, потребляемой пользователем. Существуют три наиболее важных критерия, определяющих доступность услуги: время внедрения услуги (Service Activation Time), доступность соединения (Connection Availability), время восстановления услуги после сбоя (Mean Time to Restore Service — MTTR).

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

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

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

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

11.5. Дополнительный инструментарий администратора системы для измерения производительности ИС

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

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

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

11.6. Практические рекомендации службам администратора системы по контролю производительности ИС

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

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

Обычно по умолчанию NMS конфигурируется таким образом, чтобы выполнялись три дополнительные попытки запроса SNMP с возрастающими в геометрической прогрессии тайм-аутами, начиная с 0,8 с (0,8; 1,6; 3,2 и 6,4 с), что составляет в общей сложности для четырех тайм-аутов 12 с. Но повторные попытки могут вызвать перегрузку «медленных» SNMP-агентов. А интервалов опроса в 1 с следует избегать, они меньше, чем интервалы тайм-аута.

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

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

Как показывает практика при опросах с интервалами в одну секунду, десять секунд и одну минуту фиксируются все нужные отклонения сетевых показателей, но интенсивность опросов велика и приводит к рассмотренным выше проблемам. При опросах с 10-минутными интервалами теряется значительная часть необходимой информации. Опыт внедрения систем показывает, что удовлетворителен пятиминутный интервал для фиксирования достаточного числа изменяемых статистических данных [51]. Это не перегружает ИС, систему управления и сетевые устройства.

Дополнительная информация

1.www.ietf.org/rfc/rfc2544 — метод тестирования производительности TCP/IP сетей

2.www.juniper.net — информация об измерениях производительности

3.www.metroethernetforum.org

4.www.sla-zone.co.uk

Контрольные вопросы

1.Перечислите 4 шага по управлению производительностью.

2.Зачем устанавливать базовую производительность ИС?

3.Как проводить контроль изменений параметров производительности?

4.В чем суть коррекции производительности?

5.Что является метриками производительности?

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

7.Назовите метрики производительности файл-сервера.

8.В чем суть бизнес — метрик производительности?

9.Поясните сущность Соглашения об уровне обслуживания SLA?

10.Из каких частей обычно состоит SLA?

11.В каком документе определяются метрики для технологии Metro Ethernet?

12.Зачем администратору системы генераторы и анализаторы трафика ИС?

13.Чем и почему опасно внедрение средств контроля производительности?

Глава 12

ПРОТОКОЛЫ, ИСПОЛЬЗУЕМЫЕ ДЛЯ ПРОГРАММИРОВАНИЯ СИСТЕМ АДМИНИСТРИРОВАНИЯ. СИСТЕМЫ АДМИНИСТРИРОВАНИЯ, СОПРОВОЖДЕНИЯ И ПОДДЕРЖКИ

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

Раздел 12.1 посвящен протоколам, которые применяются для программирования систем администрирования. Излагается только суть обычно используемых стандартных технологий и способов программирования управляющих систем, базирующихся на сетевых протоколах управления SNMP, RMON и NetFlow. При рассмотрении протоколов основное внимание уделено вопросам архитектуры протоколов, поскольку понимание ее необходимо службам администратора ИС для поддержки и применения систем администрирования. Технологии программирования с использованием средств объектноориентированного программирования, низкоуровневых языков программирования и программных прикладных интерфейсов (API) ОС и СУБД не рассматриваются в данном учебном пособии, так как являются инструментарием разработчиков систем управления, а не средствами администратора ИС.

Раздел 12.2 посвящен информационным системам администрирования и системам сетевого администрирования (NMS). Для лучшего понимания функций, которые выполняются системой управления ИС, в подразделе 12.2.1 приведен пример системы администрирования HP OpenView, а в подразделе 12.2.2 — пример системы NetQos.

В разделе 12.3 рассматриваются системы оперативного управления и поддержки (OSS). Конкретные примеры реализации этих систем приведены в подразделе 12.3.1.

12.1. Протоколы, используемые для программирования систем администрирования

12.1.1. Протокол ISO CMIP и услуги CMIS (модель OSI)

Как уже говорилось в главе 2, согласно стандарту управления OSI доступ к управляющей информации, хранящейся в управляемых объектах, обеспечивается с помощью элемента системы управления, называемого службой CMISE (Common Management Information Service Element). Услуги, предоставляемые службой CMISE, называются услугами CMIS (Common Management Information Service — Служба общей управляющей информации). Служба CMISE построена в архитектуре распределенного приложения, где часть функций выполняет менеджер, а часть — агент. Взаимодействие между менеджером

иагентом осуществляется по протоколу CMIP (Common Management Information Protocol — Протокол общей управляющей информации) [8, 26]. ISO предполагала, что этот протокол станет основным протоколом для реализации систем управления.

Протокол CMIP и услуги CMIS определены в стандартах Х.710 и Х.711 ITU-T. Услуги CMIS разделяются на две группы — услуги, инициируемые менеджером (запросы), и услуги, инициируемые агентом (уведомления).

Протокол CMIP представляет собой набор операций, прямо соответствующих услугам CMIS. Таким образом, в протоколе CMIP определены операции M-GET, M-SET, M-CREATE

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

Формат протокольных блоков данных CMIP описывается нотацией ASN.1 (Abstract Syntax Notation One), которая была принята ISO в качестве нотации для описания терминов коммуникационных протоколов. Нотация ASN.1 служит для установления однозначного соответствия между терминами из стандартов, предназначенных для пользователей, и данными, которые передаются аппаратурой в коммуникационных протоколах. Достигаемая однозначность очень важна для гетерогенной среды, характерной для корпоративных сетей. Например,