ѕодпишитесь на наш Telegram-канал Ѕудьте в курсе последних новостей 👇 😉 ѕодписатьс€
ѕоддержим в трудное врем€ —пециальное предложение на техническую поддержку вашей »“ - инфраструктуры силами наших экспертов ѕодобрать тариф
ѕоставка оборудовани€ √аранти€ и помощь с настройкой. —кидка дл€ наших читателей по промокоду WIKIMERIONET  упить
»нтерфейс статистики Merion Mertics показывает ключевые диаграммы и графики по звонкам, а также историю звонков в формате, который легко поймет менеджер ѕопробовать бесплатно
¬недрение
офисной телефонии
Ўаг на пути к созданию доступных унифицированных коммуникаций в вашей компании ¬недрить
»нтеграци€ с CRM ѕомогаем навести пор€док с данными
и хранить их в единой экосистеме
ѕодключить
»“ Ѕезопасность ”мна€ информационна€ безопасность дл€ вашего бизнеса «аказать
ћерион Ќетворкс

13 минут чтени€

ќпределение проблемного пространства

—етевые инженеры часто сталкиваютс€ с проблемой слишком большого трафика дл€ слишком малого канала св€зи. ¬ частности, почти в каждом пути через сеть одно звено ограничивает весь путь, так же как один перекресток или одна дорога ограничивает поток трафика. –исунок ниже иллюстрирует это.

Ќа рисунке A обмениваетс€ данными с G, а B обмениваетс€ данными с E. ≈сли кажда€ из этих пар устройств использует близкую к доступной полосе пропускани€ на своих локальных каналах ([A, C], [B, C], [F, G] и D, E]), предполага€, что все каналы имеют одинаковую скорость, канал [C, D] будет перегружен трафиком, превратившись в узкую точку в сети.

 огда канал перегружен, например канал [C, D] на рисунке ниже, по каналу будет отправлено больше трафика, чем пропускна€ способность канала. ¬о врем€ перегрузки сетевое устройство, такое как маршрутизатор или коммутатор, должно определ€ть, какой трафик следует перенаправить, какой отбросить и в каком пор€дке следует пересылать пакеты. ƒл€ решени€ этой проблемы были созданы различные схемы приоритезации.

“очка перегрузки в сетевых пут€х

”правление перегрузкой каналов путем приоритизации одних классов трафика над другими входит в широкий раздел качества обслуживани€ (QoS). ¬оспри€тие QoS среди сетевых инженеров вызывает беспокойство по многим причинам. Ќапример, многие реализации, даже недавние, как правило, не так хорошо продуманы, как могли бы быть, особенно в том, как они настроены и поддерживаютс€.  роме того, ранние схемы не всегда работали хорошо, и QoS часто может добавить проблем в сети, а не облегчить их, и, как правило, очень трудно устранить неполадки.

ѕо этим причинам, а также из-за того, что конфигураци€, необходима€ дл€ реализации схем приоритезации, имеет тенденцию к непостижимости, QoS часто считаетс€ темным искусством. „тобы успешно реализовать стратегию QoS, вы должны классифицировать трафик, определить стратегию организации очередей дл€ различных классов трафика и согласованно установить стратегию на всех сетевых устройствах, которые могут испытывать перегрузку каналов.

’от€ можно погрузитьс€ во множество различных функций и функций схем и реализаций QoS, результат всегда должен быть одним и тем же.


ѕочему бы просто не сделать линии св€зи достаточно большими?

ѕосле обдумывани€ ценностного предложени€ QoS очевидной реакцией будет вопрос, почему сетевые инженеры просто не выбирают достаточно большие линии св€зи, чтобы избежать перегрузки. ¬ конце концов, если бы линии св€зи были достаточно большими, перегрузка исчезла бы. ≈сли перегрузка исчезнет, исчезнет необходимость отдавать приоритет одному типу трафика над другим. ¬есь трафик будет доставлен, и все эти досадные проблемы, св€занные с недостаточной пропускной способностью, будут устранены. ƒействительно, избыточное выделение ресурсов, возможно, €вл€етс€ лучшим QoS из всех.

  сожалению, стратеги€ избыточного обеспечени€ не всегда €вл€етс€ доступным вариантом. ƒаже если бы это было так, самые большие доступные каналы св€зи не могут преодолеть определенные модели трафика. Ќекоторые приложени€ будут использовать столько пропускной способности, сколько доступно при передаче данных, создава€ точку перегрузки дл€ других приложений, совместно использующих линию св€зи. ƒругие будут передавать в микроперерывах, подавл€ющих сетевые ресурсы в течение короткого времени, и некоторые транспортные механизмы-такие как протокол управлени€ передачей (TCP)-будут намеренно собирать путь врем€ от времени, чтобы определить наилучшую скорость передачи данных. ¬ то врем€ как более крупна€ лини€ св€зи может сократить врем€ существовани€ состо€ни€ перегрузки, в некоторых сценари€х нет такой вещи, как наличие достаточной полосы пропускани€ дл€ удовлетворени€ всех требований.

Ѕольшинство сетей построены на модели избыточной подписки, когда некотора€ совокупна€ пропускна€ способность распредел€етс€ в определенных узких местах. Ќапример, коммутатор Top of Rack (ToR) в загруженном центре обработки данных может иметь 48 портов 10GbE, обращенных к хостам, но только 4 порта 40GbE, обращенных к остальной части центра обработки данных. Ёто приводит к коэффициенту переподписки 480:160, который уменьшаетс€ до 3:1. Ќе€вно, 160 √бит/с полосы пропускани€ центра обработки данных €вл€етс€ потенциальным узким местом - точкой перегрузки - дл€ 480 √бит/с полосы пропускани€ хоста. » все же соотношение переподписки 3:1 €вл€етс€ обычным €влением в схемах коммутации центров обработки данных. «ачем?

ќкончательный ответ - часто деньги. „асто можно спроектировать сеть, в которой граничные порты соответствуют доступной пропускной способности. Ќапример, в структуре центра обработки данных, приведенной выше, почти наверн€ка можно добавить достаточную пропускную способность канала, чтобы обеспечить 480 √бит / с из ToR в структуру, но стоимость вполне может быть непомерно высокой. —етевой инженер должен учитывать не только стоимость порта и оптоволокна, но и стоимость дополнительного питани€, а также стоимость дополнительного охлаждени€, необходимого дл€ управлени€ окружающей средой после добавлени€ необходимых дополнительных устройств, и даже затраты дополнительного места в стойке и веса пола.

«атраты денег на обеспечение более высокой пропускной способности сети также могут быть трудно оправданы, если сеть редко перегружена. Ќекоторые событи€ перегрузки не €вл€ютс€ достаточно частыми, чтобы оправдать дорогосто€щее обновление сети. Ѕудет ли город тратить миллионы или миллиарды долларов на улучшение транспортной инфраструктуры, чтобы облегчить движение раз в год, когда политик приезжает с визитом? Ќет. ¬место этого дл€ решени€ проблемы с трафиком внос€тс€ другие корректировки.

Ќапример, компании могут наиболее остро столкнутьс€ с этим ограничением в глобальных сет€х, где каналы арендуютс€ у поставщиков услуг (SP). „астично поставщики услуг зарабатывают деньги на объединении разрозненных географических регионов дл€ организаций, которые не могут позволить себе прокладывать и использовать оптоволоконные кабели большой прот€женности самосто€тельно. Ёти линии дальней св€зи обычно предлагают гораздо более низкую пропускную способность, чем более короткие, местные линии св€зи в одном кампусе или даже в одном здании. ¬ысокоскоростное соединение в университетском городке или центре обработки данных может легко перегрузить более медленные каналы дальней св€зи.

ќрганизации будут устанавливать максимально возможные размеры дальних (таких как межсайтовые или даже межконтинентальные) линий св€зи, но, оп€ть же, важно помнить о деньгах.

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


 лассификаци€

—хемы приоритизации QoS действуют на различные классы трафика, но что такое класс трафика и как он определ€етс€?

 лассы трафика представл€ют собой агрегированные группы трафика. ѕотоки данных из приложений, требующих аналогичной обработки или представл€ющих аналогичные схемы трафика в сети, помещаютс€ в группы и управл€ютс€ политикой QoS (или классом обслуживани€, CoS). Ёта группировка имеет решающее значение, поскольку было бы трудно определить уникальные политики QoS дл€ потенциально бесконечного числа приложений. — практической точки зрени€ сетевые инженеры обычно группируют трафик в четыре класса.  онечно, возможны и другие классы, и такие схемы существуют в производственных сет€х. ќднако управление системой классификации и политическими действи€ми становитс€ все более утомительным по мере того, как число классов превышает четыре.

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

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

ѕримечание: Ќесмотр€ на то, что пакеты и кадры в сети различны, в этой статье будет использоватьс€ термин пакеты.

Ѕыли разработаны и стандартизированы различные схемы маркировки, такие как 8-битное поле типа обслуживани€ (ToS), включенное в заголовок »нтернет-протокола версии 4 (IPv4). ¬ерси€ 6 того же протокола (IPv6) включает 8-битовое поле класса трафика, служащее аналогичной цели.  адры Ethernet используют 3-битное поле как часть спецификации 802.1p. Ќа рисунке показано поле ToS IPv4.

¬ наилучшей сетевой практике классификаци€ трафика должна приводить к одному действию и только к одному действию-маркировке.  огда пакет помечен, присвоенное значение может сохран€тьс€ и действовать на прот€жении всего пути следовани€ пакета по сетевому пути.  лассификаци€ и последующа€ маркировка должны быть "одноразовым" событием в жизни пакета.

Ћучша€ практика QoS - рекомендуетс€ маркировать трафик, как близко к источнику, насколько это возможно. ¬ идеале трафик будет помечен в точке входа в сеть. Ќапример, трафик, поступающий в сетевой коммутатор с персонального компьютера, телефона, сервера, устройства »нтернета вещей и т. д. будет помечена, и метка будет служить классификатором трафика на пути следовани€ пакета по сети.

јльтернативна€ схема классификации и маркировки трафика вход€щим сетевым устройством заключаетс€ в том, что приложение само маркирует свой собственный трафик. ƒругими словами, пакет отправл€етс€ с уже заполненным байтом ToS. Ёто поднимает проблему довери€. —ледует ли разрешить приложению ранжировать собственную важность? ¬ худшем случае все приложени€ эгоистично помечают свои пакеты значени€ми, указывающими наивысшую возможную важность. ≈сли каждый пакет помечен как очень важный, то на самом деле ни один пакет не €вл€етс€ особо важным. „тобы один пакет был более важным, чем любой другой, должна быть дифференциаци€.  лассы трафика должны иметь разные уровни важности, чтобы схемы приоритезации QoS имели какое-либо значение.

ѕол€ Ethernet DSCP и IP ToS

ƒл€ сохранени€ контрол€ над классификацией трафика все сети, реализующие QoS, имеют границы довери€. √раницы довери€ позвол€ют сети избежать ситуации, когда все приложени€ помечают себ€ как важные. ѕредставьте, что произошло бы на перегруженной дороге, если бы у каждого автомобил€ были мигающие аварийные огни - действительно важные автомобили не выдел€лись бы.

¬ сети некоторым приложени€м и устройствам довер€ют отмечать свой собственный трафик. Ќапример, IP-телефонам обычно довер€ют соответствующим образом маркировать свой потоковый голосовой трафик и трафик протокола управлени€, то есть метки, которые IP-телефоны примен€ют к своему трафику, принимаютс€ входным сетевым устройством. ƒругие конечные точки или приложени€ могут быть ненадежными, что означает, что байт ToS пакета стираетс€ или перезаписываетс€ при входе. ѕо умолчанию большинство сетевых коммутаторов стирают метки, отправленные им, если они не настроены на доверие определенным устройствам. Ќапример, производител€м, помещенным в пакет сервером, часто довер€ют, а маркировкам, установленным конечным хостом, - нет. Ќа рисунке ниже показана граница довери€.

Ќа рисунке 3 пакеты, передаваемые B, помечены AF41. ѕоскольку эти пакеты исход€т от хоста в домене довери€ QoS, маркировка остаетс€, пока они проход€т через D. ѕакеты, исход€щие от A, помечаютс€ EF; однако, поскольку A находитс€ за пределами доверенного домена QoS, эта маркировка удал€етс€ в D. ѕакеты в пределах доверенного домена, исход€щие из A, рассматриваютс€ как немаркированные с точки зрени€ QoS. ћаркировка протокола физического уровн€ и верхнего уровн€ может быть св€зана, а может и не быть. Ќапример, маркировка верхнего уровн€ может быть скопирована в маркировку нижнего уровн€, или маркировка нижнего уровн€ может быть перенесена через сеть, или маркировка нижнего уровн€ может быть удалена. —уществует множество различных возможных реализаций, поэтому вы должны быть осторожны, чтобы пон€ть, как маркировка обрабатываетс€ на разных уровн€х, а также на каждом переходе.

√раница довери€ QoS

’от€ операторы сети могут использовать любые значени€, которые они выбирают в байте ToS дл€ создани€ различных классов трафика, часто лучше придерживатьс€ некоторых стандартов, таких как значени€, определенные стандартами IETF RFC. Ёти стандарты были определены дл€ того, чтобы дать сетевым инженерам логическую схему, позвол€ющую надлежащим образом различать множество различных классов трафика.

ƒве из этих схем "Per Hop Behavior" по€вл€ютс€ в RFC2597, Assured Forwarding (AF), и RFC3246, Expedited Forwarding (EF), а также в различных других RFC, обновл€ющих или уточн€ющих содержание этих основополагающих документов. ќба эти RFC определ€ют схемы маркировки трафика, включа€ точные значени€ битов, которые должны заполн€ть байт ToS или байт класса трафика IP-заголовка, чтобы указать конкретный тип трафика. ќни известны как точки кода дифференцированного обслуживани€ или значени€ DSCP.

Ќапример, схема гарантированной пересылки RFC2597 определ€ет 12 значений в побитовой иерархической схеме дл€ заполнени€ восьми битов в поле байта ToS. ѕервые три бита используютс€ дл€ идентификации класса, а вторые три бита определ€ют приоритет отбрасывани€. ѕоследние два бита не используютс€. “аблица 1 иллюстрирует маркировку кода дл€ нескольких классов AF.

√арантированный класс переадресации Service Quality of Service Markings

¬ таблице 1 показано значение бита DSCP дл€ AF11, трафика класса 1 с низким приоритетом отбрасывани€, равным 001 010, где "001" обозначает класс 1, а "010" обозначает приоритет отбрасывани€. »зучение таблицы более глубоко раскрывает бинарный паттерн, выбранный авторами RFC. ¬есь трафик класса 1 помечаетс€ 001 в первых трех битах, весь класс 2-010 в первых трех битах и т. д. ¬есь трафик с низким приоритетом отбрасывани€ помечаетс€ 010 во-вторых трех битах, весь трафик со средним приоритетом отбрасывани€-100 во-вторых трех битах и т. д.

—хема гарантированной пересылки показана в таблице 2 дл€ примера. Ёто не исчерпывающий список кодовых точек, используемых при классификации трафика QoS. Ќапример, схема выбора класса, описанна€ в RFC2474, существует дл€ обратной совместимости со схемой маркировки приоритета IP. ѕриоритет IP использует только первые три бита байта ToS, всего восемь возможных классов. —електор классов также использует восемь значений, заполн€€ первые три бита шестибитового пол€ DSCP значимыми значени€ми (соответствующими устаревшей схеме приоритета IP), а последние три бита - нул€ми. ¬ таблице 2 показаны эти селекторы классов.

—електоры классов из RFC2474

RFC3246 определ€ет требовани€ к задержке, потер€м и джиттеру трафика, который должен быть перенаправлен быстро, вместе с единственной новой кодовой точкой - EF, которой присвоено двоичное значение 101 110 (дес€тичное 46).

 оличество и разнообразие формально определенных значений DSCP может показатьс€ ошеломл€ющим.  омбинированные определени€ AF, CS и EF сами по себе привод€т к формальным определени€м дл€ 21 различных классов из возможных 64, использующих шесть битов пол€ DSCP. ќжидаетс€ ли, что сетевые инженеры будут использовать все эти значени€ в своих схемах приоритезации QoS? —ледует ли разбивать трафик с такой высокой степенью детализации дл€ эффективного QoS?

Ќа практике большинство схем QoS ограничиваютс€ от четырех до восьми классов трафика. –азличные классы позвол€ют обрабатывать каждую группу по-своему во врем€ перегрузки. Ќапример, один класс трафика может быть сформирован так, чтобы соответствовать определенному порогу пропускной способности. ƒругой класс трафика может иметь приоритет над всем остальным трафиком. ≈ще один может быть определен как критически важный дл€ бизнеса или трафик, который важнее большинства, но менее важен, чем некоторые. “рафик сетевого протокола, критичный дл€ стабильности инфраструктуры, можно рассматривать как очень высокий приоритет.  ласс трафика scavenger может находитьс€ в конце списка приоритетов, получа€ немного больше внимани€, чем немаркированный трафик.

—хема, включающа€ эти значени€, веро€тно, будет представл€ть собой сочетание кодовых точек, определенных в различных RFC, и может несколько отличатьс€ от организации к организации. ќбычно прин€тые значени€ включают EF дл€ критического трафика с требованием своевременности, например VoIP, и CS6 дл€ трафика управлени€ сетью, такого как протоколы маршрутизации и резервировани€ на первом этапе. Ќемаркированный трафик (т.е. значение DSCP, равное 0) доставл€етс€ по принципу "максимальных усилий", без каких-либо гарантий уровн€ обслуживани€ (обычно это считаетс€ классом scavenger, как указано выше).