Администрирование_в_информационных_системах_Беленькая_М_Н_

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

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

Система MS или NMS должна регулярно собирать значения параметров, заданных администратором системы, и выдавать сообщения при их отклонении свыше определенного предела. Обычно в управляющих системах для этого используется протокол SNMP, применяемый при диагностике ошибок. Однако в последнее время для диагностики только проблем производительности используется протокол NetFlow. Рассмотрим его подробнее в главе 12.

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

—текущее/среднее время отклика приложения;

—скорость передачи/приема информации от устройства или программного продукта (бит/с);

—процент потерянных пакетов;

—число ошибок интерфейса;

—трафик сети в пиковом режиме.

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

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

в БД не имеет смысла. Такие средства обычно есть в составе MS, NMS или ОС и СУБД. Администратору системы целесообразно иметь программные продукты, позволяющие получать не только отчеты, но и графики изменения параметров производительности ИС. Особенно это полезно при анализе производительности по часам в течение рабочего дня.

Коррекция производительности ИС. Коррекция производительности ИС заключается в действиях администратора системы по возврату базовых параметров производительности к номинальным значениям. Администратор системы делает это на основе своих знаний и отчетов управляющей системы. Действия по коррекции производительности ИС могут включать:

—добавление новых интерфейсов сетевых устройств;

—добавление каналов ввода-вывода серверов (в зависимости от возможностей ОС);

—изменение конфигурации устройств (например, маршрутизаторов);

—изменение путей трафика с обходом узких мест;

—изменение параметров загрузки ОС и СУБД;

—применение средств оптимизации СУБД;

—изменение методов доступа к данным;

—полную модификацию части ИС с изменением ее архитектуры.

Например, можно существенно влиять на производительность ИС через средства физического проектирования БД. При этом БД может размещаться на сервере БД (там, где запускается ядро СУБД) или на файл-сервере (там, где запускается ядро ОС). Если на файл-сервере система ввода-вывода является многоканальной и имеет скоростные интерфейсы (например, 5 каналов ввода-вывода SCSI), а на сервере БД один канал ввода-вывода IDE, то вариант с размещением БД на файлсервере даст большую производительность ИС. Но при этом приложения могут запускаться на сервере БД, а он в свою очередь может быть размещен администратором системы не в одном сегменте сети с файл-сервером. В этом случае выигрыш в производительности может быть потерян из-за задержек на маршрутизирующих устройствах, и АС должен предпринять усилия по «приближению» сервера БД к файл-серверу или перемещению БД на сервер БД, несмотря на его слабую подсистему ввода-вывода.

11.2. Метрики производительности ИС

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

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

11.2.1. Метрики сетевой подсистемы ИС

Для сетевой подсистемы ИС существуют пять ключевых метрик [64]. Две метрики характеризуют передачу информации от источника к принимающему устройству: это пропускная способность канала и задержка передачи данных (latency — латенция). Три метрики характеризуют состояние устройств: ошибки интерфейсов, утилизация ресурсов сетевых устройств, использование буферов сетевых устройств и файл-серверов.

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

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

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

Мгновенная пропускная способность отличается от средней пропускной способности тем, что для усреднения выбирается очень маленький промежуток времени, например 10 мс или 1 с.

Максимальная пропускная способность — это наибольшая мгновенная пропускная способность, зафиксированная в течение периода наблюдения.

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

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

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

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

Пропускная способность и задержки передачи являются независимыми параметрами: сеть может обладать, например, высокой пропускной способностью, но вносить значительные задержки при передаче каждого пакета. Пример такой ситуации — кΣанал связи, образованный геостационарным спутником. Пропускная способность этого канала может быть весьма высокой, например 2 Мбит/с, в то время как задержка передачи всегда составляет не менее 0,24 с, что определяется скоростью распространения сигнала (около 300 000 км/с) и длиной канала (72 000 км).

При использовании различных сетевых технологий возникают различные задержки и администратор системы должен уметь их рассчитывать. Рассмотрим, как это делается для технологии Ethernet 100 Base ТХ и 100 Base FХ [36].

Задержка в Ethernet называется PDV (Pass Delay Value):

PDV = ΣLSDV + ΣRDelay + DTEDelay + SM.

Здесь LSDV (Link Segment Delay Value) — задержка на каждом сегменте сети (зависит от типа кабеля). LSDV = длина сегмента ½ задержка на метр сегмента. Для оптоволокна задержка на метр сегмента составляет 1бит/м, для UTP cat 5 — 1,122 бит/м. RDelay (Repeater Delay) — задержка на сетевом оборудовании. Эти задержки приводятся производителем оборудования. Например, для хабов BAY Network (Nortel) задержка составляет 140 бит/с. DTEDelay — задержка на сетевых адаптерах каждой из двух рабочих станций в сети (принимающей и передающей), составляет 100 бит/с. SM (Safety Margin) — задержка за счет непредвиденных факторов, составляет 4—5 бит/с.

Общая задержка в Ethernet должна быть не более 512 бит.

Задержка является наиболее часто используемой метрикой для измерения производительности сети, поскольку тесно связана с утилизацией канала и легко измеряется средствами ОС сетевых устройств. Если утилизация канала высока, то и значение задержки велико (данные «ждут» отправки). Администратору системы целесообразно измерять задержку между сервером (например, сервером БД ИС) и рабочей станцией, обращающейся к БД. Каждое устройство и соединение по пути между ними (hop) будет увеличивать задержку. Пример измерения задержки с помощью утилиты Ping приведен на рис. 11.3.

Ошибки интерфейсов. Ошибки интерфейсов могут возникать из-за шумов в канале, некорректно работающего сетевого устройства, ошибок кабельной системы. При их возникновении потерянные или испорченные пакеты приходится пересылать заново на соответствующий интерфейс сетевого устройства. В этом случае возможна потеря производительности ИС в целом. Возможны ситуации, когда пакеты отбрасываются интерфейсом, например, из-за того, что администратор системы не задал для него нужной политики QoS (Quality of Service) [26]. В этом случае необходима реконфигурация устройства.

C:\>ping 65.254.250.110

Pinging 65.254.250.110 with 32 bytes of data:

Reply from 65.254.250.110: bytes=32 time=80ms TTL=237 Reply from 65.254.250.110: bytes=32 time=80ms TTL=237 Reply from 65.254.250.110: bytes=32 time=80ms TTL=237

Reply from 65.254.250.110: bytes=32 time=80ms TTL=237 Ping statistics for 65.254.250.110:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 80ms, Maximum = 80ms, Average = 80ms

C:\>

Рис. 11.3. Измерение задержки с помощью утилиты Ping

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

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

—общее число выделяемых буферов;

—число постоянно загруженных буферов;

—число свободных буферов (free list);

—число ошибок буферов.

11.2.2. Производительность файл-серверов

Для файл-сервера помимо перечисленных параметров, влияющих на производительность, важны следующие параметры [54]:

—утилизация процессора;

—параметры работы дисковой подсистемы ввода-вывода;

—параметры ввода-вывода шины процессора;

—параметры ввода-вывода сетевых адаптеров. Утилизация процессора не должна превышать 70—80% [54].

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

имеющими возможность одновременной работы в режиме записи в CPU-память и диск-память. Кроме того, любая ОС выделяет буфера ввода-вывода в оперативной памяти и организует очередь команд к контроллеру. Между ними должно быть соответствие. Например, если буфера ввода-вывода загружены, а очередь команд — большая, то низкая производительность системы естественна и требует модификации дисковой подсистемы, описанной выше. Если при низкой производительности буфера загружены, а очередь команд контроллера невелика, это свидетельствует о неверной конфигурации параметров ОС. Разобраться в причинах низкой производительности системы (является виновником процессор или шина процессора) бывает крайне сложно. Операции ввода-вывода на шине процессора и доступ к оперативной памяти осуществляются через кэш-память и работают значительно медленнее, чем CPU. Однако в современных серверах обычно реализована возможность одновременного доступа к оперативной памяти и к шине процессора. Если это не так, то АС должен рассмотреть вопрос замены сервера. Проблемы сетевого ввода-вывода могут возникать в приложениях, обрабатывающих изображения, большие файлы данных и файлы печати. Для администратора системы это должно быть заметно по сообщениям ОС (например, Receive packet overflow count или Send packet miscellaneous errors OC Novell Netware). АС должен либо изменить конфигурацию буферов сетевого ввода-вывода, либо установить сетевые адаптеры с более чем одним каналом работы с шиной процессора, либо сегментировать сеть с помощью сетевых устройств.

11.3. Бизнес-метрики производительности

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

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

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

—время подготовки запросов на клиентском компьютере;

—время передачи запросов между клиентом и сервером через сегменты сети и промежуточное коммуникационное оборудование;

—время обработки запросов на сервере и передачи ответов от сервера пользователю;

—время обработки получаемых от сервера ответов на компьютере пользователя.

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

Договор об уровне обслуживания — SLA (Service Level Agreements). В этом договоре содержатся критерии, согласно которым пользователь ожидает получить оговоренные услуги. Договор может содержать соглашения по следующим параметрам:

—продолжительность работы системы в сутки (например, 8 ч);

—минимальное время восстановления (например, 4 ч);

—скорость передачи информации (например, 512 Кбит/с);

—допустимая задержка (например, меньше 50 мс). Создание договора свидетельствует о том, что службы ад-

министратора системы и бизнес договорились о стандарте на производительность системы и способах ее оценки.

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

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

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

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

SLA обычно включает спецификацию уровня обслуживания SLS (Service Level Specification) и цели соглашения об уровне услуг SLO (Service Level Objective). Спецификация SLS служит своего рода инструкцией при оказании услуг. В SLO оговариваются определенные технические параметры и их значения, например пропускная способность, частота, максимально допустимое время отклика и пр., которые должны быть достигнуты с помощью SLS.

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

действий персонала. Например, в компании, работающей в сфере ИТ-технологий, существует отдел технической поддержки пользователей — call-центр. В этом случае в составе SLA могут быть следующие метрики:

—AR (Abandone Rate) — количество звонков (в процентах), потерянных в период ожидания ответа;