headermask image

Notice: Undefined variable: t in /var/www/user97185/data/www/system-administrators.info/yandex-ad.php on line 15

Notice: Undefined variable: r in /var/www/user97185/data/www/system-administrators.info/yandex-ad.php on line 15
Рекомендую: Фриланс-биржа | Кэшбэк-сервис | Интернет-бухгалтерия

Дросселирование пропускной способности с помощью QoS (часть 2)

В первой части этой серии статей я рассказывал о том, что делает QoS, и для чего он используется. В этой части я продолжу разговор объяснением того, как работает QoS. По мере прочтения этой статьи, пожалуйста, учитывайте, что информация, представленная здесь, основана на Windows Server 2003 применении QoS, которое отличается от применения QoS в Windows 2000 Server.

API управления трафиком

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

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

Первое, что делает Traffic Control API, это создает то, что известно под названием filterspec. Filterspec – это, по сути, фильтр, определяющий, что значит для пакета принадлежать к определенному потоку. Некоторые атрибуты, используемые filterspec, включают IP адрес источника и назначения пакета и номер порта.

Как только filterspec был определен, API позволяет создать flowspec. Flowspec определяет QoS параметры, которые будут применяться к последовательности пакетов. Некоторые из параметров, определяемые flowspec, включают скорость передачи (допустимую скорость передачи) и тип службы.

Третий концепт, определяемый интерфейсом Traffic Control API – это концепт потока. Поток представляет собой простую последовательность пакетов, которые подвержены одному flowspec. Проще говоря, filterspec определяет, какие пакеты будут включены в flowspec. Flowspec определяет, будут ли пакеты обрабатываться с более высокими приоритетами, а поток – это собственно передача пакетов, которые подвергаются обработке flowspec. Все пакеты в потоке обрабатываются равноправно.

Следует упомянуть, что одним из преимуществ Traffic Control API над Generic QoS API, использовавшемся в Windows 2000, является способность использовать агрегирование (объединение). Если узел имеет несколько приложений, передающих множественные потоки данных в общее место назначения, то эти пакеты могут быть объединены в общий поток. Это действует, даже если приложения используют различные номера портов, но при условии, что IP адрес источника и назначения одинаков.

Классификатор общих пакетов (Generic Packet Classifier)

В предыдущем разделе я рассказал о взаимоотношениях между flowspec, filterspec и потоком. Однако важно помнить, что интерфейс Traffic Control API – это просто программный интерфейс приложения. Будучи таковым, его работа заключается в определении и назначении приоритетов потокам трафика, а не создание этих потоков.

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

QoS Packet Scheduler (планировщик пакетов)

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

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

На самом деле, здесь присутствует два типа маркировки. Планировщик пакетов QoS использует Diffserv маркировку, которая распознается устройствами третьего уровня, и маркировку 802.1p, которая распознается устройствами второго уровня.

Настройка планировщика пакетов QoS

Прежде чем я покажу вам, как работает маркировка, следует отметить, что вам нужно будет настроить планировщика пакетов QoS, чтобы все работало. В Windows Server 2003 планировщик пакетов QoS относится к необязательным сетевым компонентам, так же как и клиент для сетей Microsoft или TCP/IP протокол. Чтобы включить планировщика пакетов QoS, откройте страницу свойств вашего сетевого подключения сервера и поставьте флажок рядом со строкой планировщик пакетов QoS, как показано на рисунке A. Если планировщик пакетов QoS отсутствует в списке, нажмите кнопку «Установить» и следуйте указаниям.

qos.jpg

Рисунок A: Планировщика пакетов QoS необходимо включить, прежде чем вы сможете использовать QoS

Еще один момент, который вам нужно знать касаемо планировщика пакетов QoS, заключается в том, что для его корректной работы ваш сетевой адаптер должен поддерживать 802.1p маркировку. Чтобы проверить свой адаптер, нажмите кнопку «Настроить», рисунок A, и Windows отобразит свойства вашего сетевого адаптера. Если вы посмотрите во вкладку «Дополнительно» на странице свойств, вы увидите различные свойства, которые поддерживает ваш сетевой адаптер.

Если вы посмотрите на рисунок B, вы увидите, что одним из свойств в списке является 802.1Q / 1P VLAN Tagging. Вы также видите, что это свойство отключено по умолчанию. Чтобы включить 802.1p маркировку, просто включите это свойство и нажмите OK.

qos1.jpg

Рисунок B: Вы должны включить 802.1Q/1P VLAN Tagging

Вы, возможно, заметили на рисунке B, что свойство, которое вы включили, связано с VLAN тегированием, а не с пакетной маркировкой. Причина тому кроется в том, что маркеры приоритетов включаются в VLAN теги. 802.1Q стандарт определяет VLANs и VLAN теги. Этот стандарт на самом деле резервирует три бита в VLAN пакете, которые используются для записи кода приоритетности. К сожалению, 802.1Q стандарт никогда не определяет, каковы должны быть эти коды приоритетности.

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

Заключение

В этой статье мы обсудили некоторые основные понятия в архитектуре Windows Server 2003′s QoS. В третьей части я подробнее расскажу о том, как планировщик пакетов QoS маркирует пакеты. Я также расскажу о том, как работает QoS в условиях сети с низкой пропускной способностью.

Автор: Брайн Позей

Оригинал 

Похожие посты
  • Дросселирование пропускной способности с помощью QoS (часть 1)
  • Дросселирование пропускной способности с помощью QoS (часть 3)
  • Дроссерилование пропускной способности с помощью QoS (часть 4)
  • Iperf – утилита для тестирования пропускной способности сети.
  • Отправка SMTP сообщений с помощью PowerShell. Часть 4
  • Включаем Aero в Windows 7 с помощью реестра
  • Управление групповыми политиками с помощью Advanced Group Policy Management (AGPM) v4, часть 2
  • Отправка SMTP сообщений с помощью PowerShell. Часть 3
  • Миграция с Windows XP в Windows 7 с помощью MDT 2010
  • Отправка SMTP сообщений с помощью PowerShell. Часть 1