Узкое место сети как найти

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

Как показывает многолетний опыт компании “ПроЛАН” в области оказания услуг по диагностике и тестированию сетей, вопросам локализации “узких мест” сети и особенно вопросам выявления недостатков прикладного ПО администраторы сетей уделяют недостаточно внимания. Утверждения типа “все и так работает, зачем нам какая-то диагностика” приходится слышать нередко. Многие администраторы под диагностикой сети понимают исключительно диагностику кабельной системы. Кроме того, зачастую действия администратора по устранению дефектов и/или улучшению работы сети основываются на интуиции, а не на достоверных данных о том, почему сеть работает плохо.

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

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

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

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

ЧТО ТАКОЕ “УЗКОЕ МЕСТО” СЕТИ

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

Наличие или отсутствие “узких мест” зависит от того, какое прикладное ПО используется в сети. В общем случае какой-либо архитектурный компонент сети нельзя считать “узким местом” без конкретизации ПО, для которого он таковым является. В одной и той же сети для разных типов прикладного ПО “узкими местами” могут быть разные архитектурные компоненты. Например, если для прикладного ПО на базе Fox Pro наиболее вероятным “узким местом” будет производительность канала связи или дисковой подсистемы сервера, то для прикладного ПО на базе Oracle — производительность процессора сервера.

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

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

“Узкое место” сети можно сравнить с полностью заполненной трубой (утилизация близка к естественному пределу — 100%), из-за чего остальные трубы оказываются незаполненными.

Таким образом, пропускная способность других труб (ресурсов) используется неэффективно.

Скрытыми “узкими местами” являются такие алгоритмы, процессы или параметры настройки оборудования либо программного обеспечения, из-за которых пропускная способность сети оказывается неадекватно низкой. Так, например, к категории скрытых “узких мест” можно отнести параметры настройки оборудования, вызывающие “широковещательные штормы” (см. Правило №4.1), или параметры настройки прикладного ПО, приводящие к увеличению доли коротких кадров (см. Правило №3.1). К категории скрытых “узких мест” следует отнести и алгоритмы работы прикладного ПО, следствием которых является неэффективное использование пропускной способности сети (см. Правило №5.1).

НЕДОСТАТОЧНАЯ ПРОПУСКНАЯ СПОСОБНОСТЬ ОБЩЕГО СЕТЕВОГО РЕСУРСА

Правило №1.1. Уровень утилизации общих сетевых ресурсов с одинаковой дисциплиной обслуживания заявок в хорошо сбалансированной сети не должен существенно отличаться.

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

Для канала связи, например, дисциплина обслуживания выражается в правиле: “Первым пришел, первым обслужен” (FIFO). Как только заявка поступает, она сразу выполняется. Если канал связи свободен, то станция сразу передает кадр; таким образом, при наличии заявки на обслуживание канал связи не простаивает.

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

Если уровни утилизации общих ресурсов существенно отличаются друг от друга, то такую сеть принято называть “плохо сбалансированной по нагрузке”. В этом случае необходимо заменить активное оборудование и/или изменить архитектуру сети. Данная процедура называется “выравнивание нагрузки” (load balancing).

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

Предположим, что ваша сеть имеет архитектуру с компактной магистралью (collapsed backbone), как показано на Рисунке 2. Для того чтобы определить, какой из доменов сети (домен А на 10 Мбит/с или домен В на 100 Мбит/с) в большей степени влияет на время реакции прикладного ПО, загруженность этих доменов надо сравнить между собой. Несмотря на то что сравниваемые ресурсы имеют разную номинальную пропускную способность (10 Мбит/с и 100 Мбит/с), наибольшее влияние на время реакции прикладного ПО оказывает тот домен, значение утилизации которого выше.

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

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

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

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

Примечание. Это не относится к случаям, когда утилизация ресурсов отличается более чем на порядок. Если, например, утилизация процессора сервера

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

Правило №1.2. Чтобы определить, какой общий ресурс является “узким местом” сети, вы должны точно знать, утилизация какого ресурса ближе других к допустимому или к естественному пределу.

Если в процессе измерений вы определили, что утилизация какого-то ресурса близка к естественному пределу (к 100%), то этот ресурс однозначно является “узким местом” сети. Обычно с интерпретацией результатов, в которых утилизация ресурсов близка к естественному пределу, особых проблем не возникает. Намного сложнее интерпретировать результаты, в которых утилизация общих ресурсов различна и далека от естественных пределов.

Допустимый предел утилизации (см. Правило №1.3) обычно меньше естественного (меньше 100%), а его значение зависит от многих условий.

Предположим, что вы измерили утилизацию всех общих ресурсов сети (изображенной на Рисунке 2) и определили, что утилизация домена А составила 19%, утилизация внутренней магистрали коммутатора — 26%, домена B — 12%, процессора сервера — 36%. Позволяют ли полученные данные сделать вывод о том, что “узким местом” является недостаточная производительность процессора сервера? Нет, так как эти ресурсы имеют разную дисциплину обслуживания заявок, и мы изначально не знаем, утилизация какого ресурса ближе других находится к допустимому пределу.

Таким образом, мы подошли к вопросу о том, как определить допустимый предел утилизации ресурса.

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

Из теории массового обслуживания известно, что в общем случае скорость выполнения операций в сети гиперболически зависит от утилизации общих ресурсов (см. Рисунок 3). За верхнее допустимое значение обычно принимается утилизация, при которой заканчивается “линейный” участок гиперболы. Однако крутизна кривой и протяженность “линейного” участка для разных типов ресурсов могут быть различны. Это означает, что допустимое значение утилизации (допустимый предел) для разных типов ресурсов различно.

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

Ряд анализаторов протоколов, например Observer компании Network Instru-

ments, имеют функцию генерации трафика (см. Рисунок 4). Изменяя параметры Packets/sec (число пакетов в секунду) и Packet size (размер пакета), вы можете варьировать интенсивность генерируемого анализатором трафика, а изменяя параметр destination (приемник) — направление генерируемого трафика. Зависимость между утилизацией ресурса и временем реакции можно оценить, измеряя время реакции прикладного ПО на фоне увеличения генерируемой нагрузки. Зная эту зависимость, вы можете определить, при какой утилизации ресурса заканчивается “линейный” участок гиперболы или какой утилизации ресурса соответствует требуемое время реакции прикладного ПО (например, 2 с, см. врезку “Какая сеть хороша?”). Это значение утилизации и будет являться допустимым пределом утилизации ресурса.

Определить допустимый предел утилизации различных компонентов сервера намного сложнее (см. раздел узкое место — “Производительность сервера”).

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

Как мы уже говорили выше, ликвидация “узкого места” не всегда достигает цели. Признаком целесообразности устранения “узкого места” является наличие в сети только одного “узкого места”, и то только в том случае, если “расширение” “узкого места” позволит ускорить работу прикладного ПО (см. Правило №6.1).

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

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

Сеть развивается, число пользователей увеличивается, и вы, например, решили, не меняя сервера, заменить сеть Ethernet на сеть Fast Ethernet. В этом случае канал связи перестает быть “узким местом”, но не дисковая подсистема сервера. Нагрузка на дисковую подсистему увеличится, и, следовательно, ее утилизация возрастет. Если при этом крутизна гиперболической зависимости времени реакции от утилизации дисковой подсистемы (см. Правило №1.3) больше, чем для канала связи, то скорость выполнения операций в сети уменьшится.

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

ПРОИЗВОДИТЕЛЬНОСТЬ СЕРВЕРА

Особого внимания заслуживает вопрос о том, как проверить тот факт, что “узким местом” сети является недостаточная производительность сервера.

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

Сервер — это сложная система, в состав которой кроме процессора входит множество различных компонентов: системная шина, дисковая подсистема, оперативная память и др. Каждый из этих компонентов имеет свою дисциплину обслуживания заявок, и каждый теоретически может быть “узким местом” сети.

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

Признаком перегрузки других компонентов сервера могут быть такие показатели, как число “грязных” кэш-буферов, число отложенных запросов к диску, число “попаданий в кэш” и многие другие. Эти показатели, как правило, не выражаются в процентах, что существенно осложняет процесс определения “узкого места”. Более того, методика определения “узкого места” сильно зависит от типа сетевой ОС, в частности она различна для сервера с Windows NT и с NetWare.

В рамках данной статьи, ввиду объемности и сложности материала, мы не можем рассказать о том, как определить, какой конкретно компонент сервера является “узким местом”. Эта задача решается только с использованием метода стрессового тестирования сети, о котором мы планируем рассказать в последующих публикациях. Тем, кого эта проблема интересует, мы рекомендуем прочесть книгу Расса Блейка “Optimizing Windows NT”, которая входит в состав “Windows NT Resource Kit”, издаваемого Microsoft Press.

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

Правило №2.1. Признаком перегрузки сервера NetWare является специальный пакет протокола NCP, который сервер высылает в ответ на повторный запрос от рабочей станции, если предыдущий запрос от той же рабочей станции еще обрабатывается сервером. Такие пакеты обычно называются Delay packet, Server busy replies или Being processed packet.

Отправив по протоколу NCP запрос к серверу NetWare на выполнение какой-то операции, рабочая станция включает тайм-аут и ждет от сервера ответа о выполнении этой операции. Если ответ не приходит в течение фиксированного времени (тайм-аута), то станция повторяет запрос для проверки того, что он не был потерян при передаче по сети. Получив повторный запрос от рабочей станции, сервер отвечает ей специальным пакетом, который, как мы говорили, называется Delay packet, Server busy replies или Being processed packet. Сервер как бы просит станцию не волноваться: “Запрос получен, но я не могу на него сейчас ответить”. Получив пакет, рабочая станция обнуляет свой тайм-аут и продолжает ждать ответа от сервера. Наличие таких пакетов в сети свидетельствует о том, что сервер не успевает обрабатывать запросы от рабочих станций. Чем больше в сети подобных пакетов, тем сильнее перегружен сервер. Подробнее об этом можно прочесть в книге Лауры А. Чаппел и Дэна Е. Хейкса “Анализатор локальных сетей NetWare”, изданной Novell PRESS.

Обычно анализаторы сетевых протоколов имеют специальный входной фильтр, позволяющий фиксировать наличие и определять число таких пакетов в сети (см. Рисунок 5). Установив значение параметров Number of server busy replies (“Число ответов сервера о том, что он занят”) и Averaging period (“Период усреднения”), анализатор протоколов информирует вас, когда число ответов сервера о перегрузке за заданный промежуток времени превысит установленное значение.

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

Правило №2.2. Признаком перегрузки сервера является возросшее время ответа сервера на запросы рабочих станций.

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

Время реакции сервера автоматически определяется некоторыми анализаторами протоколов. В Observer время реакции каждого узла сети входит в состав статистики по каждой паре станций и называется latency (см. Рисунок 6).

БОЛЬШОЕ ЧИСЛО КОРОТКИХ КАДРОВ

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

Правило №3.1. Пропускная способность сети существенно зависит от типа сетевого трафика. Чем больше число коротких кадров, тем менее эффективно используется пропускная способность сети.

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

Пропускная способность канала связи (коммутаторов и концентраторов) существенно зависит от размера кадров. Чем большую долю в общем числе кадров занимают короткие кадры, тем менее эффективно используется пропускная способность канала связи. На Рисунке 7 пропускная способность сети Ethernet показана в зависимости от длины кадров (она была измерена утилитой perform3 компании Novell). Несмотря на то что вид кривой зависит от используемых сетевых адаптеров, снижение пропускной способности сети при уменьшении размера кадров характерно для всех типов сетей (Ethernet, Fast Ethernet, Token Ring, FDDI).

В этой связи измерение доли кадров конкретной длины приобретает большее значение. Такое измерение можно провести с помощью специальных утилит (например, psd.exe компании Novell) или анализатора протоколов. Анализатор Observer автоматически строит распределение кадров по длинам. Результат его работы показан на Рисунке 8.

РОСТ ЧИСЛА ШИРОКОВЕЩАТЕЛЬНЫХ ПАКЕТОВ

Правило №4.1. В соответствии с отраслевым стандартом де-факто число широковещательных и многоадресных кадров в сети не должно превышать 8—10% от общего числа кадров (Robert W. Buchanan, Jr, “The Art of Testing Network Systems”; Wiley Computer Publishing).

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

Если отношение числа широковещательных кадров к общему числу кадров больше 10%, то такой эффект называется “широковещательным штормом”.

Широковещательный шторм может быть следствием дефектов оборудования или неправильной настройки параметров активного оборудования. Чаще всего это явление наблюдается в распределенных сетях NetWare, построенных на основе коммутаторов, или когда данные между сегментами или доменами сети могут передаваться более чем по одному потенциальному пути. Если один из коммутаторов такой сети не поддерживает протокол Spanning Tree (обычно IEEE 802.1d) или последний неправильно настроен либо сбоит, то в сети начинается неуправляемая циркуляция широковещательных кадров.

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

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

Данная задача хорошо решена в анализаторе протоколов Observer (см. Рисунок 9). Совмещенный график отображает долю (в процентах) широковещательных и многоадресных кадров как функцию утилизации канала связи. При этом цветом выделяется степень загрузки сети. Если цвет линий желтый, то утилизация сети менее установленного порога (обычно 5%). При такой утилизации доля широковещательных и групповых кадров особого интереса не представляет. При зеленом цвете линий утилизация сети высокая, но доля широковещательных и групповых кадров менее установленного порога (по умолчанию 10%). Если же цвет линий красный, то это означает, что утилизация канала связи и доля широковещательных и многоадресных кадров выше установленного порога. Это признак “широковещательного шторма”.

НЕЭФФЕКТИВНЫЕ АЛГОРИТМЫ РАБОТЫ ПРИКЛАДНОГО ПО

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

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

Чтобы определить, насколько эффективно используются ресурсы сети, мы рекомендуем провести несколько экспериментов с типовыми задачами. Суть экспериментов заключается в одновременном запуске типовых задач на N (N = 1,2,3…) рабочих станциях. Цель экспериментов — измерить время выполнения типовой задачи при различном числе станций и соответствующие значения утилизации сетевых ресурсов (канала связи, процессора сервера, процессоров рабочих станций и т. д.).

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

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

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

Правило №5.1. Насыщение утилизации всех сетевых ресурсов на уровне существенно ниже естественного предела их пропускной способности служит признаком того, что “узким местом” являются неэффективные алгоритмы работы прикладного ПО.

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

КАКОЕ “УЗКОЕ МЕСТО” СЛЕДУЕТ УСТРАНЯТЬ В ПЕРВУЮ ОЧЕРЕДЬ

Если вы определили, какой именно ресурс является “узким местом” вашей сети, то затем вы должны установить, как устранение этого “узкого места” повлияет на время реакции ПО.

Правило №6.1. Чем больше доля времени, приходящаяся на конкретный сетевой ресурс при выполнении типовой задачи, тем большее ускорение в решении задачи будет достигнуто при увеличении пропускной способности этого ресурса. В первую очередь надо увеличивать пропускную способность того ресурса, на который приходится наибольшая доля времени выполнения типовой задачи.

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

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

Если вы определили, предположим, что передача данных по каналу связи занимает 10% времени решения задачи (Дканала = 0,1), выполнение операций на сервере — 5% (Дсервера = 0,05), а на рабочей станции — 85% (Дстанции = 0,85), то какой бы высокой производительностью ни обладал ваш новый сервер, вы не получите ускорения в решении задачи более чем на 5%. Аналогично, если ваша сеть будет работать со скоростью света, вы все равно не получите ускорения в решении задачи более чем на 10%. В таких случаях модифицировать прежде всего следует рабочие станции (или алгоритмы работы прикладного ПО).

ДВА ПОДХОДА К ОЦЕНКЕ КАЧЕСТВА СЕТИ

Какая сеть хороша?

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

Как показали исследования, проведенные группой американских психологов, время реакции прикладной системы для пользователей, работающих в диалоговом режиме, не должно превышать 2 секунды (William Stallings, “SNMP, SNMPv2, and CMIP. The Practical Guide to Network-Management Standards”, Addison-Wesley Publishing Company). Если время реакции оказывается большим, то пользователи чувствуют себя некомфортно, быстро устают, часто делают ошибки, производительность их труда становится низкой.

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

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

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

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

Зачастую, действия администраторов для улучшения работы основываются на интуиции, в виду недостаточного опыта в данной сфере. Как правило, первым виновником проблем считают оборудование, которое морально «устарело» и отработало свой «эксплуатационный период» при максимальной нагрузке в 10-30%. Исходя из этого ложного мнения, не имея минимального мониторинга показаний этого оборудования, осуществляют приобретение нового дорогостоящего продукта не задумываясь, что причина может быть совсем в другом. Потраченные средства не оправдывают ожиданий, а проблема остается не решенной.

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

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

• пропускная способность (скорость) канала для одного разговора 100 кбит/с;
• максимальная задержка (ping) при передаче пакетов должна составлять не более 100-150 миллисекунд;
• джиттер, или отклонение от среднего уровня задержки — не более 20 миллисекунд;
• не более 5% потери пакетов.

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

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

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

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

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

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

Первая идея, которая пришла мне в голову — это замена оборудования, так как оно отработало более 5 лет и не обслуживалось. При установке мониторинга сетевого оборудования и снятия показаний Ping, CPU, температуре и ОЗУ, анализ показывал, что оборудование при сроке эксплуатации в 5 лет работает стабильно, нагрузка на процессор более 30-40% не поднимается, пакеты не вылетают, задержки большие отсутствуют. Проблема все еще не устранена. 

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

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

Подводя итог вступительной части, я бы хотел поделиться с Вами своим примером использования доступного всем инструмента Iperf – для поиска узких мест в топологии сети, определения ширины канала; построения и визуализации сети с помощью Algorius Net Viewer.

Рассмотрим карту сети (Рис.1), на которой отображены и поставлены на мониторинг:

1. Станция 1 – ПЭВМ с виртуальной машиной:

• Station_Algorius – предустановленная система мониторинга;
• виртуальных машин с Centos 7 и Asterisk 18.10.0.

2. Станция 2 – ПЭВМ с виртуальной машиной:

• WorkStation – рабочая станция;
• виртуальных машин с Centos 7 и Asterisk 18.10.0.

3. Router_Tplink – домашний Wi-Fi роутер.

4. Iperf_lon.speedtest.clouvider.net – публичный Iperf сервер.

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

В данном примере будет рассмотрен вариант запуска Iperf, в качестве сервера со стороны Asterisk, со стороны системы мониторинга, в качестве клиента. Такой подход обеспечивает возможность получения показаний отправителя (sender) и получателя (receiver) со стороны мониторинга, так как на серверной части присутствует только один показатель.

Начнем с настройки виртуальных машин с Centos 7 и Asterisk 18.10.0, для этого необходимо осуществить следующие действия в строке Centos:

1. Выполним установку расширенного репозитория:
   yum install epel-release
2. Устанавливаем Iperf3:
   yum install iperf3
3. Запускаем Iperf3, как сервер ключом -s:
   Iperf3 –s

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

1. Запуск сервера автоматически при старте системы, работа программы осуществляется, как служба systemd:

— создадим юнит и внесем в него следующие данные: 

nano /etc/systemd/system/iperfd5204.service

Описание содержимого:

• Description — описание юнита;
• After — указывается юнит, после которого может запускаться сервис;
• Type — тип службы; 
• PIDFile — путь к pid файлу, в котором хранится номер процесса;
• ExecStart – команда выполнения при старте сервиса, где указывается запуск iPerf3, -s — в режиме сервера, -р – порт 5204, D – запустить, как службу, -I — указать pid-файл;
• ExecReload — команда для перезапуска службы;
• Restart=always — опция, позволяющая автоматически перезапускать сервис, если он перестанет работать;
• WantedBy=multi-user.target — устанавливает для автозапуска службу в обычном многопользовательском режиме.
• создадим второй юнит и внесем в него измененные данные: nano /etc/systemd/system/iperfd5205.service

Выполнение этого действия необходимо только в том случае, если планируется осуществлять тестирование с нескольких устройств, например, у нас есть несколько разнесенных серверов для тестирования, расположенных в разных точках.  Это позволит нам запустить Iperf3 за раз с нескольких портов: 5204 и 5205. Такой подход позволяет исключить ошибки при проведении запроса теста. Надо не забывать, что со стороны клиента в запросе требуется указывать порт для обращения к серверу:

-c 192.168.0.98 –р 5204

-c 192.168.0.98 –р 5205

• Перезапускаем systemd:

systemctl daemon-reload

• Разрешаем созданные сервисы и ставим их в автозагрузку:

systemctl enable iperfd5204.service

systemctl enable iperfd5205.service

• Запускаем их:

systemctl start iperfd5204.service

systemctl start iperfd5205.service

• Проверяем их статус:

systemctl start iperfd5204.service

systemctl start iperfd5205.service

2. Запуск публичного сервера с множеством портов, такой подход указан на официальном сайте Iperf:

• Создадим пользователя:

adduser iperf -c iperf

• Создадим юнит и внесем в него следующие данные: 

nano /etc/systemd/system/[email protected]

• Перезапускаем systemd:

systemctl daemon—reload

• Активируем Iperf3 при запуске сервера с портами 9200 по 9210:

for p in $(seq 9200 9210); do sudo systemctl enable [email protected]$p ; done

• Перезагружаем сервер:

Reload

• Проверяем статус запущенных служб:

systemctl status [email protected]*

• Проверяем журнал анализа логов с указанных юнитов:

journalctl -u [email protected]*

На этом настройка сервера заканчивается и как запускать Iperf выбирать Вам.

Перейдем к следующему этапу, нам необходимо осуществить запуск теста с ключом клиента. Для этого на ПЭВМ, где у меня установлен Algorius Net Viewer, я создал папку на рабочем столе куда поместил скаченный с официального сайта разработчика Iperf3 (https://iperf.fr/download/windows/iperf-3.1.3-win64.zip).

В Algorius Net Viewer нет встроенного Iperf и тут возникает вопрос, а как нам запустить тест и вывести полученные показания на карту сети. Для этого мы воспользуемся встроенным плагином ‘External’, который позволяет опрашивать устройства, используя внешние утилиты.

В указанном сенсоре нас интересует 3 настройки:

1. Файл – путь до приложения, которое необходимо запустить.
2. Аргумент – это наша команда с ключами запроса:
   с – запуск клиента;
   адрес до сервера;
   -р – опрашиваемый порт;
   -t – время опроса;
   -f – формат отчета;
   g – выводить в Gbit/sec.
3. RegEx – регулярное выражение описывающее необходимый нам показатель до получателя: (d+|d+.d+s+Gbits/sec)s+receiver .

Для каждого устройства необходимо создавать свой сенсор, по аналогии я создал еще 2 сенсора для опроса второго Asterisk и публичного сервера lon.speedtest.clouvider.net, изменив в шаблоне имя и адрес.

Для получения показаний о статусе Asterisk, загрузки CPU и памяти сервера, я решил использовать вывод запроса команд в строке Linux по SSH:

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

2. В настройках мониторинга воспользуемся плагином SSH.

В указанном плагине нас интересует 2 настройки:

1. Команды:
   • для показаний статусу Asterisk:
   systemctl status asterisk | grep Active: | awk ‘{print $2}’
   • для показаний загрузки CPU:
   asterisk -rx «core show sysinfo» | grep Total.RAM | awk ‘{print $3}’
   • для показаний памяти сервера:
   asterisk -rx «core show sysinfo» | grep Total.RAM | awk ‘{print $3}’
   Все эти команды используют стандартный поиск и вывод требуемых значений.
2. RegEx – регулярное выражение описывающее необходимое нам получаемое значение: .* .

На этом настройка завершена.

На следующем этапе необходимо установить в настройках устройств созданные сенсоры мониторинга. Указать период опроса. Для SSH указать созданный логин и пароль. Сенсоры не привязаны к конкретному устройству и их размещение зависит только от Вашего удобства для понимания.

Теперь рассмотрим финальный результат, который получился.

На карте сети (Рис.16) отображены и поставлены на мониторинг:

1. Станция 1:

• Station_Algorius:
  Показатели мониторинга:
  Ping — показатель целостности соединения;
  Iperf_Speed_Ast_1 – показатель теста Iperf до Asterisk’а 1;
  Iperf_Speed_Ast_2 – показатель теста Iperf до Asterisk’а 2;
  Iperf_Speed_Public – показатель теста Iperf до публичного сервера в интернете.
• Virtual_Asterisk_PBX_1:
  Показатели мониторинга:
  SSH_status – показатель состояния Asterisk;
  Ping — показатель целостности соединения;
  SSH_CPU — показатель состояния СPU;
  SSH — показатель состояния памяти;
  Ping — показатель целостности соединения.

2. Станция 2:

• WorkStation:
  Показатели мониторинга:
  Ping – показатель целостности соединения.
• Virtual_Asterisk_PBX_2:
  Показатели мониторинга:
  SSH_status – показатель состояния Asterisk;
  Ping – показатель целостности соединения;
  SSH_CPU – показатель состояния СPU;
  SSH – показатель состояния памяти;
  Ping – показатель целостности соединения.

3. Router_Tplink:

Показатели мониторинга:
Ping — показатель целостности соединения.

4. Iperf_lon.speedtest.clouvider.net:

Показатели мониторинга:
Ping — показатель целостности соединения.

На рис. 16 мы видим показатели теста Iperf от Virtual_Asterisk_PBX_1, Virtual_Asterisk_PBX_2 и Iperf_lon.speedtest.clouvider.net до Station_Algorius разные. Это связано с тем, что соединение с системой мониторинга осуществляется по различным каналам связи, пропускная способность, которых отличается. Это может быть связано с типом подключения, с максимальной пропускной способностью канала связи, с нагрузкой на сам канал связи.

Рис. 17 — Virtual_Asterisk_PBX_1 со Station_Algorius, расположены на одном ПЭВМ, и они связаны мостом. Их скорость максимальная при таком типе подключения.

Рис. 18 — Virtual_Asterisk_PBX_2 со Station_Algorius связаны Router_Tplink с портом в 100 Мб/с. Стоит отметь, что Station_Algorius подключена к Router_Tplink по WiFi, на указанном участке сети это является узким местом, так как такой тип подключения не позволяет использовать проводной канал в 100 Мб/с от Virtual_Asterisk_PBX_2 до Router_Tplink на 100%.

Рис. 19 — Iperf_lon.speedtest.clouvider.net со Station_Algorius связаны с Router_Tplink через подключение к Интернету, пропускная способностью порта WAN 100Мб/с. Но результат теста показывает, что ширина канала значительно ниже и временами падает до 0. Мы можем сделать вывод, что на участке сети от Station_Algorius до публичного сервера присутствуют узкие места. В данном примере — это может быть связано с ограничением в пропускной способности канала связи, с нагрузкой на канал связи до публичного сервера. На таком участке сети могу возникать проблемы с предоставлением услуг телефонной связи, где пропускная способность является низкой и нестабильной.

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

Спасибо за внимание.

Добрый день

Ситуация следующая

Есть 2 файловых сервера с настоенныеми RAID6. Будем называть их Сервер SSD, и Сервер HDD для наглядности, потому что первый собран на 8 SSD дисках, а второй на 10 обычных HDD для NAS (5400 rpm).

Оба файловых сервера подключены к 10 гигабитному свитчу, на скорости 10Гигабит.

Также к свитчу подключено 2 рабочие станции, одна по 10-гигабитке, а вторая по 1-гигабитке.

Итак, на Сервере SSD провел тесты скорости чтения и записи рэйда.

$ sync; dd if=/dev/zero of=./zeros1.img bs=10M count=500; sync
500+0 записей получено
500+0 записей отправлено
5242880000 байт (5,2 GB, 4,9 GiB) скопирован, 15,9636 s, 328 MB/s

$ sync; dd if=/dev/zero of=./zeros2.img bs=10M count=500; sync
500+0 записей получено
500+0 записей отправлено
5242880000 байт (5,2 GB, 4,9 GiB) скопирован, 17,3086 s, 303 MB/s

$ sync; dd if=/dev/zero of=./zeros3.img bs=10M count=500; sync
500+0 записей получено
500+0 записей отправлено
5242880000 байт (5,2 GB, 4,9 GiB) скопирован, 18,3812 s, 285 MB/s

$ sync; dd if=/dev/zero of=./zeros4.img bs=10M count=500; sync
500+0 записей получено
500+0 записей отправлено
5242880000 байт (5,2 GB, 4,9 GiB) скопирован, 19,4098 s, 270 MB/s

$ sync; dd if=/dev/zero of=./zeros5.img bs=10M count=500; sync
500+0 записей получено
500+0 записей отправлено
5242880000 байт (5,2 GB, 4,9 GiB) скопирован, 19,4397 s, 270 MB/s

Средняя скорость записи на RAID6 из 8 ssd дисков, по итогам теста, около 300 MB/s.

$ sudo /sbin/sysctl -w vm.drop_caches=3; dd if=./zeros1.img of=/dev/null bs=10M count=500
[sudo] пароль для master: 
vm.drop_caches = 3
500+0 записей получено
500+0 записей отправлено
5242880000 байт (5,2 GB, 4,9 GiB) скопирован, 2,8586 s, 1,8 GB/s

Средняя скорость чтения с RAID6 из 8 ssd дисков, по итогам теста, около 1.8 GB/s.

Теперь те же тесты я провел на Сервере HDD

$ sync; dd if=/dev/zero of=./zeros1.img bs=10M count=500; sync
500+0 записей получено
500+0 записей отправлено
5242880000 байт (5,2 GB, 4,9 GiB) скопирован, 9,47348 s, 553 MB/s

$ sync; dd if=/dev/zero of=./zeros2.img bs=10M count=500; sync
500+0 записей получено
500+0 записей отправлено
5242880000 байт (5,2 GB, 4,9 GiB) скопирован, 5,19057 s, 1,0 GB/s

$ sync; dd if=/dev/zero of=./zeros3.img bs=10M count=500; sync
500+0 записей получено
500+0 записей отправлено
5242880000 байт (5,2 GB, 4,9 GiB) скопирован, 5,21997 s, 1,0 GB/s

$ sync; dd if=/dev/zero of=./zeros4.img bs=10M count=500; sync
500+0 записей получено
500+0 записей отправлено
5242880000 байт (5,2 GB, 4,9 GiB) скопирован, 5,6245 s, 932 MB/s

$ sync; dd if=/dev/zero of=./zeros5.img bs=10M count=500; sync
500+0 записей получено
500+0 записей отправлено
5242880000 байт (5,2 GB, 4,9 GiB) скопирован, 5,3953 s, 972 MB/s

Средняя скорость записи на RAID6 из 10 hdd дисков, по итогам теста, около 950 MB/s. Что, на мой взгляд, оочень неплохо!

$ sudo /sbin/sysctl -w vm.drop_caches=3; dd if=./zeros1.img of=/dev/null bs=10M count=500
vm.drop_caches = 3
500+0 записей получено
500+0 записей отправлено
5242880000 байт (5,2 GB, 4,9 GiB) скопирован, 4,76412 s, 1,1 GB/s

Средняя скорость чтения на RAID6 из 10 hdd дисков, по итогам теста, около 1.1 GB/s. Что, на мой взгляд, тоже неплохо, хотя я ожидал что будет сильнее отрыв от скорости записи.

========================================
Сервер SSD:
Запись (приблизительно): 300 Мб/c
Чтение (приблизительно): 1.8 Гб/c

Сервер HDD:
Запись (приблизительно): 950 Мб/c
Чтение (приблизительно): 1.1 Гб/c
========================================

Вопрос №1
Почему так проигрывает Сервер SSD по скорости записи? По чтению, если грубо то это 250мб в секунду на 1 диск, в среднем. Ну вроде более менее, хотя я ожидал больше.

Вопрос №2
Насколько хорошие результаты скорости выдает сервер HDD? Мне кажется что по записи очень неплохо. А чтение, мне кажется могло быть повыше, но тут я могу ошибаться.

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

Общий объем сиквенции приблизительно 8.2 гигабайта.
По 10ти гигабитной сетке этот сиквенс загружался в память 1 минуту 29 секунд.

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

Согласитесь разница оочень незначительная.

Вопрос №3
Помогите понять, где узкое горлышко. Почему скорость на 1 и 10-ти гигабитных машинах почти одинакова? Хотя скорость чтения на сервер SSD порядка 1.8GB/s, что видно из тестов выше. т.е. по идее отдает файлы сервак с достаточной скоростью.

Поиск узких мест
в сети является важным аспектом анализа
ее работы. Узкое место создается тем
узлом сети, у которого коэффици­ент
загрузки U приближается
к единице. В этом узле образуется большая
очередь, которая при U
≥ 1 становится бесконечной, и сеть
переходит в неустойчивый режим работы.
Такой узел становится «насыщенным»
требованиями. Узкие места в сети
обусловливают ее пропускную способность,
то есть полностью определяют время
пре­бывания в сети. Поэтому при анализе
работы сети необходимо осо­бое внимание
уделять поиску узких мест.

Покажем на простом
примере, почему узкое место определяет
пропускную способность сети. Рассмотрим
трубопровод, в котором есть трубы разного
диаметра, доставляющие воду потребителю.
Если после трубы маленького диаметра
поставить трубу c любым
большим диаметром, то потребитель не
получит большего количества воды за
единицу времени, чем ее может пропустить
узкая труба. Это – так на­зываемый
эффект «узкого горлышка». Поэтому при
рассмотрении та­ких систем важно
иметь сбалансированные потоки в сети,
то есть такой баланс потоков в узлах,
при котором среднее время пребывания
в сети было бы минимально или ее пропускная
способность макси­мальна.

Приведем соотношения,
которые связывают коэффициенты
ис­пользования узлов c
коэффициентами посещаемости этих узлов:

Устройство k
будет «насыщено» требованиями, если
его коэф­фициент использования близок
к единице. В этом случае при выпол­нении
гипотезы о балансе потоков интенсивности
входящего потока и обслуживания будут
практически совпадать, то есть

При увеличении
числа требований, одновременно
обслуживаю­щихся в сети, первым
достигнет насыщения тот узел d,
который бу­дет иметь максимальную
величину V_iS_i,
i = 1,…,K,
то есть

При увеличении
количества требований коэффициент
использования U_d
приближается к 1 и X_d
=

.
Поскольку

,
то

.

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

Определим минимальное
среднее время пребывания требования
R₀, если в сети
есть лишь одно требование, через
коэффициенты по­сещаемости отдельных
устройств и время обслуживания устройства

На рис. 2.9 изображен
график зависимости интенсивности
пото­ка в сети от количества требований
в сети. При увеличении N интенсивность
Хо монотонно возрастает до предельной
асимптоты V_dS_d,
то есть пока на эту интенсивность не
начнет влиять потенциально узкое место
– узел d. На рис.
2.9 через N* обозначено число требований,
при котором узкое место еще не влияет
на пропускную способность сети.

Рис. 2.9

Для простейшей
замкнутой сети, если количество устройств
M = 1, тo R‘
= R‘₀.
При увеличении M
поток из сети будет возрастать, но не
больше, чем

.
Таким образом,

Итак, при увеличении
M среднее время
пребывания имеет асимптоту MV_dS_d–Z.
На рис.2.10 показана зависимость среднего
времени пребывания в замкнутой сети от
числа устройств M.
Асим­птота, которая создает узкое
место в сети, пересекает ось абсцисс в
точке

.

Рис. 2.10

Изложенный подход
к поиску узких мест в сети просто
исполь­зовать на практике. Покажем
это на примерах.

Пример 2.3.
Проведем расчет характеристик сети,
которая изо­бражена на рис. 2.11, там же
приведены значения операционных
пе­ременных S_k,
q_kj
и Z.

Рис. 2.11

Запишем уравнения
баланса потоков для коэффициентов
посе­щаемости этой сети:

Решая приведенную
систему уравнений, получаем

Определяем значения
V_kS_k
для каждого из узлов сети:

Таким образом,
минимальное среднее время пребывания
одного требования составляет: R₀
= 1 + 0,088 + 0,32 = 2,2 c.

Поскольку V₁S₁
>V₂S₂
>V₃S₃,
то потенциальным узким местом в сети
является первый узел.

Основываясь на
рассматриваемом методе операционного
анали­за, дадим ответ на некоторые
вопросы.

1. Пусть измерениями
определено, что Х₀ = 0,715 требований/с,
А среднее время пребывания требования
в сети составляет 5,2 c.
Какое среднее количество устройств
обслуживания взаимодействует c
се­тью за все время наблюдения?

В соответствии c
формулой (2.13) имеем:

2. Можно ли обеспечить
среднее время пребывания требований в
сети равным 8 c при 30
устройствах обслуживания? Какое
макси­мальное среднее время обслуживания
требования должен иметь узел 7, чтобы
это стало возможным?

В соответствии c
формулой (2.13) имеем:

Таким образом, при
взаимодействии c сетью
30 устройств, сред­нее время пребывания
требования в ней превысит 10 c.

Обозначим через
S₁* допустимое
среднее время обслуживания требования.
Тогда можно записать

то есть максимально
возможное среднее время обслуживания
требо­вания узлом 1 составляет 0,047 c.
На рис. 2.12 изображены графики для
асимптоты среднего времени обслуживания
требования.

Рис.2.12

Пример 2.4. Допустим,
что в сеть, кроме требований от уст­ройств
обслуживания, поступают еще и требования
от узла 3, как по­казано на рис.
2.13.

Рис. 2.13

На рис. 2.13 параметры
со штрихом характеризуют требования
узла 3. Измерения в данной сети
показали, что узел 3 загружен
прак­тически полностью, А время
ответа системы равняется 7 c.
Как в этих условиях загружен узел 1 и
какое значение приобретает X₀?

Из рис. 2.13 видно,
что V’₁
= V’₃
= 1. Тогда F₁S₁
= 0,05 c, F₁S₁
= 0,1 c.

Таким образом,
потенциально узким местом для требований
уз­ла 3 есть сам узел 3.

Поскольку

,
то X₃ = 7,392
требований/с, Х₁ =18,48
требований/с.

Загрузка узла 3,
создаваемая требованиями от устройств
обслу­живания, составляет

U₃
= X₃S₃
= 7,392 • 0,04 = 0,296 .

Вторая загрузка
узла 3 создается требованиями,
которые посту­пают от этого узла (U’₃
= 0,704).

Поскольку требования
от узла 3 циркулируют в замкнутом
кон­туре, то при условии замкнутости
сети имеем

Определим коэффициент
использования узла 1

Таким образом,
узел 1 также используется практически
полно­стью.

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

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #

  21.03.201525.52 Mб14golubev_a_p_sravnitelnaya_fonetika_angliiskogo.pdf

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #