Что такое симметричное управление потоком данных на маршрутизаторе
Обновлено: 19.05.2024
Когда Ethernet-устройство перегружено, управление потоком позволяет ему отправлять запросы PAUSE на устройства, отправляющие ему данные, чтобы разрешить состояние перегрузки. Если управление потоком не включено и возникает состояние перегрузки, устройство будет отбрасывать пакеты. Отбрасывание пакетов гораздо больше влияет на производительность, чем управление потоком.
Управление потоком 802.3X реализовано не на основе потока, а на основе канала. Управление потоком предназначено для решения проблемы, заключающейся в перегрузке входного буфера при переполненном дуплексные каналы, которые не могут обрабатывать скорость ввода. Управление потоком изначально было изобретено для предотвращения потери пакетов коммутаторами, которые работали со скоростью ниже скорости передачи данных. В то время методом управления обычно был противодавление. Кроме того, это может значительно снизить общую пропускную способность сегментов, управляемых потоком.
Когда приемная часть (Rx) порта заполняет свою очередь Rx FIFO и достигает верхней отметки, передающая часть (Tx) порта начинает генерировать кадры паузы. Ожидается, что удаленное устройство остановит/сократит передачу пакетов на интервал времени, указанный в кадре паузы. Если Rx может очистить очередь Rx или достичь нижней отметки в течение этого интервала, Tx отправляет специальный кадр паузы, в котором интервал указывается как нулевой (0x0). Это позволяет удаленному устройству начать передачу пакетов. Если Rx все еще работает в очереди, по истечении времени интервала Tx снова отправляет новый кадр паузы с новым значением интервала.
Если Rx-No-Pkt-Buff равен нулю или не увеличивается, а счетчик Tx PauseFrames увеличивается, это указывает на то, что наш коммутатор генерирует кадры паузы, а удаленный конец подчиняется, следовательно, очередь Rx FIFO истощается.
Если Rx-No-Pkt-Buff увеличивается и TxPauseFrames также увеличивается, это означает, что удаленный конец игнорирует кадры паузы (не поддерживает управление потоком) и продолжает отправлять трафик. Чтобы выйти из этой ситуации, вручную настройте скорость и дуплекс, а также отключите контроль потока, если это необходимо. Эти типы ошибок на интерфейсе связаны с проблемой трафика с превышением лимита подписки на порты.
Чем не является управление потоком:
- Не предназначено для решения проблемы постоянно перегруженных сетей или каналов.
- Он не предназначен для решения проблемы нехватки пропускной способности сети. При правильном использовании управление потоком может быть полезным инструментом для устранения краткосрочных перегрузок на одиночной ссылке.
- Не предназначено для обеспечения сквозного управления потоком данных. Сквозные механизмы, обычно на транспортном уровне, предназначены для решения таких проблем. Наиболее распространенным примером является TCP Windows, обеспечивающий сквозное управление потоком между источником и получателем для отдельных потоков L3/L4.
Что произойдет, если управление потоком будет недоступно?
Для Ethernet пакеты будут по-прежнему отправляться на принимающий порт, но не будет места для временного хранения пакетов. Принимающий порт просто проигнорировал бы эти входящие пакеты. Ethernet и TCP/IP работают вместе для повторной передачи этих «потерянных» пакетов. Однако требуется время, чтобы определить, что пакеты были отброшены, запросить повторную передачу этих отсутствующих пакетов, а затем отправить их.
Контроль потока — где его использовать, а где нет.
Где подключенные серверы GE работают на скорости меньше, чем скорость проводной сети, а соединение необходимо приостановить только на короткое время, обычно измеряемое микросекундами. Отдельные клиенты могут быть задержаны без потенциального воздействия на большие области сети. Управление потоком может быть полезно, например, если восходящий канал перегружен отдельными клиентами. CoS/QoS со временем станет более важным здесь.
Управление потоком очень важно для хорошо спроектированной и высокопроизводительной инфраструктуры iSCSI Ethernet.
Во многих сетях может быть дисбаланс в сетевом трафике между устройствами, которые отправляют трафик, и устройствами, которые получают трафик. Это часто имеет место в конфигурациях SAN, в которых множество серверов (инициаторов) обмениваются данными с устройствами хранения (целями). Если отправители передают данные одновременно, они могут превысить пропускную способность получателя. Когда это происходит, получатель может отбрасывать пакеты, вынуждая отправителей повторно передавать данные после задержки. Хотя это не приведет к потере данных, задержка увеличится из-за повторных передач, а производительность ввода-вывода снизится. Flow Control может помочь устранить эту проблему. Это позволяет получателю обработать свою задолженность, чтобы впоследствии возобновить прием входных данных. Величина задержки, вызванная этим действием, значительно меньше, чем накладные расходы, вызванные повторной передачей пакетов TCP/IP.
Коммутаторы всегда должны быть настроены на автоматическое согласование управления потоком, если служба поддержки не укажет иное.В терминологии Cisco это означает использование «желаемой» настройки. Если коммутатор может как отправлять, так и получать кадры паузы (так называемое симметричное управление потоком), включите согласование в обоих направлениях (отправка желаемого и получение желаемого). Если коммутатор поддерживает только получение кадров паузы (асимметричное управление потоком), включите согласование только для приема (требуемый прием).
В массивах Equalogic серии PS автосогласование для асимметричного управления потоком всегда включено.
На самом деле управление потоком в ядре больше вредит, чем помогает. Управление потоком в ядре может вызвать перегрузку на участках сети, которые в противном случае не были бы перегружены. Если определенные ссылки постоянно находятся в перегруженном состоянии, скорее всего, проблема связана с текущей реализацией сети. Правильным решением будет изменить структуру сети, добавив дополнительную пропускную способность, снизив нагрузку или обеспечив надлежащее сквозное качество обслуживания, чтобы гарантировать прохождение критически важного трафика.
Лучший способ справиться с любой потенциальной перегрузкой в магистральной сети — CoS/QoS элементы управления. Приоритизация пакетов через несколько очередей обеспечивает гораздо более сложное управление трафиком (например, нацеливание на определенные типы пакетов приложений), чем принцип «все или ничего» или даже регулируемая форма управления потоком.
QoS не может работать должным образом, если коммутатор отправляет кадры PAUSE, потому что это замедляет весь трафик этих портов, включая любой трафик, который может иметь высокий приоритет.
Когда вы включаете QoS на коммутаторе, буферы портов распределяются по одной или нескольким отдельным очередям. Каждая очередь имеет один или несколько связанных с ней порогов отбрасывания. Комбинация нескольких очередей в буфере и пороги отбрасывания, связанные с каждой очередью, позволяют коммутатору принимать разумные решения при возникновении перегрузки. Трафик, чувствительный к колебаниям и задержке, такой как пакеты VoIP, может быть перемещен в начало очереди для передачи, в то время как другой менее важный или менее чувствительный трафик может быть помещен в буфер или отброшен. Планирование входящего и исходящего трафика всегда основывается на значении COS, связанном с кадром. По умолчанию более высокие значения COS сопоставляются с более высокими номерами очередей. Трафик COS 5, обычно связанный с трафиком VoIP, сопоставляется с очередью со строгим приоритетом, если она присутствует.
При настройке портов коммутатора/кластера для использования с cDOT рекомендуется отключить управление потоком в соответствии с TR-4182. Фактически, это рекомендация и для обычных портов данных. Почему это? Прежде чем мы углубимся в это, давайте рассмотрим основы…
Что такое управление потоком?
Управление потоком — это механизм, используемый для управления скоростью передачи данных между двумя устройствами. Это делается для того, чтобы устройство-источник не перегружало устройство-получатель, отправляя больше пакетов, чем может обработать пункт назначения. Эти сценарии могут возникнуть, если исходное устройство быстрее, чем целевое устройство (ЦП, ОЗУ, сетевая карта и т. д.). Это также может произойти, если источник преднамеренно пытается залить место назначения с помощью вредоносной атаки типа «отказ в обслуживании» (DoS).
Управление потоком может быть активировано для отправки или получения пакетов или для обоих. Он может быть аппаратным или программным. Это может произойти на нескольких уровнях модели OSI
Чтобы провести аналогию с управлением потоком в реальном мире, подумайте о том, как работают плотины. Плотина будет установлена для контроля потока воды на реке, обычно для создания озер или водохранилищ. Плотины можно использовать для регулировки потока воды для предотвращения наводнений в зависимости от количества осадков. Управление сетевым потоком делает почти то же самое — предотвращает лавинную передачу данных.
Управление потоком данных
Остановиться и подождать
В этом типе управления потоком на канале передачи данных, когда управление потоком срабатывает, целевое устройство не будет подтверждать пакет, пока оно не будет к этому готово. Это просто, но из-за своей простоты это также плохо работает, так как источник должен получить ACK для отправки следующего пакета.
Скользящее окно
В этом типе управления потоком данных целевое устройство отправляет скорректированные размеры окна* (и всегда ACK) на исходное устройство, чтобы объявить, какой размер пакета должен отправлять источник. Размер окна будет зависеть от того, насколько уже заполнен размер окна. Если окно заполняется до отказа, место назначения отправит источнику окно нулевого размера, чтобы сообщить источнику, что он не может больше получать данные. Если источник продолжает отправлять пакеты в пункт назначения после того, как размер окна объявлен равным нулю, пункт назначения будет обрабатывать пакеты в зависимости от того, как было разработано микропрограммное обеспечение, работающее на устройстве.
Считается, что это намного эффективнее, чем «остановиться и подождать», поскольку пункт назначения всегда будет подтверждать подтверждение, а трафик будет течь в зависимости от размера окна.
*Размеры окна отправки и получения можно контролировать и изменять с помощью конфигурации клиента. Обратитесь к своему поставщику за информацией о том, какие размеры лучше всего установить для вашего конкретного приложения.
Управление потоком Ethernet
Существует также понятие управления потоком Ethernet. Это делается на транспортном уровне (уровень 4). Существует несколько основных типов управления потоком Ethernet, в том числе:
Приостановить кадр
Этот тип использует управление потоком кадров с паузой, при котором перегруженное целевое устройство отправляет пакет источнику, указывая, что источник должен ждать в течение определенного периода времени, чтобы отправить следующий пакет. Индикатором этого будет увеличение счетчиков XON/XOFF на сетевых адаптерах.
Это тип управления потоком, на который NetApp ссылается в своем передовом опыте. Это не то же самое, что контроль перегрузки.
Приоритет
Приоритетное управление потоком (802.1Qbb) является продолжением стандарта 802.3x и используется в средах FCoE. Он по-прежнему выполняет управление потоком, но в отличие от 802.3x, 802.1Qbb работает с индивидуальными приоритетами и будет управлять запросами, даже когда 802.3x отключен.
У Cisco есть информация об управлении потоком для различных коммутаторов, таких как Catalyst 6500:
Почему управление потоком данных в Clustered Data ONTAP должно быть отключено?
На мой взгляд, для этого есть три причины…
Во-первых: ограничения буфера на некоторых коммутаторах.
Буфер — это физическое выделение памяти на устройстве, позволяющее хранить данные до тех пор, пока их нельзя будет переместить в другое место. По мере развития современных вычислений данные стали БОЛЬШЕ. Больше данных = больше трафика. Больше трафика = потребность в большем буфере для обработки этого трафика. Когда используется управление потоком, буфер данных используется для хранения данных, в то время как другие полученные данные обрабатываются.
Однако оборудование коммутатора не всегда может удовлетворить спрос на буферы данных, не влияя на стоимость.
Во-вторых: больше данных, лучшее оборудование.
Хотя данных становится больше, растут и исходные и конечные устройства, а также сетевые каналы. Современные устройства теперь более способны обрабатывать все эти данные и обрабатывать их достаточно быстро, так что управление потоком не только не нужно, но и фактически препятствует повышению производительности. Если вы мне не верите, у этого парня есть реальный пример
Третье: контроль перегрузки.
Общая идея состоит в том, чтобы позволить управлению потоком управляться выше по стеку в форме управления перегрузкой. Это может быть сделано приложениями, и, честно говоря, должны выполняться приложениями, поскольку аппаратное управление потоком данных не зависит от приложений
А как насчет других поставщиков? Они также рекомендуют отключить управление потоком?
Короткий ответ? "Это зависит от обстоятельств".
Длинный ответ? У всех по-разному. Например, в последней документации для ESXi (5.5) говорится, что управление потоком следует оставить включенным. Я еще не видел рекомендаций по передовой практике для vSphere 6. Лучше всего обратиться за рекомендацией к конкретному поставщику.
Имейте в виду, что эти рекомендации могут меняться в зависимости от новой информации, выявленных проблем и т. д. Поэтому всегда следите за обновлениями лучших практик (включая рекомендации NetApp).
Как отключить управление потоком?
Если вы решите отключить управление потоком, имеет смысл отключить его на обеих конечных точках. Несоответствие конфигурации потенциально может вызвать проблемы с производительностью или другие проблемы. В идеале, в зависимости от рекомендации поставщика, параметр управления потоком должен быть одинаковым для всех устройств.
Чтобы отключить управление потоком в Cisco IOS, см. справочные страницы конкретной версии коммутатора.
Чтобы отключить управление потоком в Clustered Data ONTAP:
кластер::> изменить сетевой порт -node -port
Имейте в виду, что изменение управления потоком на порте приведет к кратковременному прерыванию подключения, так как порт будет сброшен для считывания новой конфигурации. Это сообщение может меняться во времени в зависимости от микропрограммы, загрузки и т. д. Настройка управления потоком данных должна выполняться только в период обслуживания.
Надеюсь, это поможет прояснить некоторую путаницу в управлении потоком и рекомендациях по передовой практике!
![]()
Здравствуйте, это относится как к r/networking, так и к r/sysadmin, но я написал здесь первым, так как, на мой взгляд, это больше r/networking.
В любом случае, разобравшись, что вы думаете о том, чтобы включить управление потоком на клиенте, но не на коммутаторе, есть ли польза от его отключения на клиентских ПК? Мы не используем Flow Control на наших сетевых устройствах, так как у нас есть QOS, а наличие обоих — нет, нет, поэтому просто интересно, не повлияет ли его включение на клиентах на их производительность.
![]()
Я страстно ненавижу управление потоком. Если я ясно объясню, когда вы закончите читать это, вы это сделаете. С другой стороны, Priority Flow Control, реализованный в линейке продуктов Cisco Nexus, является гораздо более интеллектуальным решением той же проблемы.
QoS — это прекрасно. Я люблю QoS. Вы должны любить QoS.Если вы не включили и не настроили QoS в своей локальной сети, значит, вы делаете это неправильно.
Давайте поговорим об управлении потоком.
Управление потоком – это технология управления перегрузками с прогнозированием.
Управление потоком используется коммутатором или клиентом/сервером для предотвращения неконтролируемой потери пакетов. Когда коммутатор или сервер ПРЕДСКАЗЫВАЕТ, основываясь на текущем потоке трафика, что у него закончатся буферы в следующих нескольких пакетах, он инициирует кадр PAUSE (запрос) на отправляющем устройстве. После получения кадра PAUSE, предполагая, что отправляющее устройство настроено на ответ на запросы на паузу, отправляющее устройство просто прекратит отправку трафика на несколько миллисекунд. Чем выше скорость соединения, тем короче продолжительность паузы.Это полная остановка всего потока трафика, независимо от приоритетов трафика.
Да, я отправлял вам слишком много трафика iSCSI, поэтому вы попросили меня сделать паузу. Я пойду дальше и поставлю в очередь эти пакеты VoIP. Надеюсь, это не сильно повлияет на качество голоса.
Итак, теперь ваш сервер попросил ваш коммутатор замолчать на секунду. Коммутатор перестанет посылать вам трафик, но трафик продолжит поступать на коммутатор. Коммутатор не имеет механизма для передачи запроса на паузу вверх по течению, если только вы не включили управление потоком на входном канале.
Итак, теперь пакеты входят в коммутатор, но не могут выйти в течение X миллисекунд. Коммутатор будет буферизовать пакеты как можно лучше, основываясь на своей внутренней архитектуре. Он может позаимствовать буферную память из других портов, чтобы «помочь» ситуации. Если вы везде включили управление потоком, теперь у вашего коммутатора повсеместно не хватает буферов, поэтому все порты начинают отправлять запросы на паузу.
Весь ваш сегмент локальной сети на мгновение зависнет, потому что ваш дисковый массив не выдержит.
Сеансы SSH зависают, вызовы VoIP имеют разрывы звука, сеансы RDP зависают. Плохие вещи вокруг.
Но эти несколько пакетов iSCSI буферизуются и удерживаются настолько хорошо, насколько это возможно, чтобы мы могли доставить их драгоценные биты.
Давайте сравним эту сцену с тем, что произошло бы при глобальном отключении управления потоком и правильной реализации QoS.
Такой же избыток пакетов iSCSI поступает на коммутатор, и выходной порт становится перегруженным, поскольку сервер не справляется. Выходной порт будет буферизовать и истощать, насколько это возможно, в соответствии с количеством буферов, назначенных этой очереди трафика в политике QoS. Все остальные порты продолжают отправлять и получать данные в обычном режиме.
Если политика QoS разрешает очереди iSCSI заимствовать дополнительные буферы, он так и сделает. Но он не может заимствовать буферы, гарантированные другим классам трафика. Если пакеты iSCSI должны быть отброшены из-за перегрузки, они будут отброшены, и никакие другие классы пакетов не будут знать об этом. VoIP продолжает нормально работать, SSH и RDP поддерживают постоянный поток данных.
Но подождите, мы также можем включить WRED в рамках политики QoS. Эй, сеть: если вы думаете, что в определенном классе трафика у вас закончатся буферы, отбросьте один или два случайных кадра из этого класса. Это приведет к тому, что эти потоки обнаружат потерю пакетов и запустят медленный старт TCP. Пара конкретных разговоров замедляется, что снижает общую нагрузку на трафик. Нарушители с интенсивным движением «страдают», чтобы другой трафик мог течь.
Похоже, это гораздо более разумный способ управления заторами.
Подведем итоги?
Кратко о Flow-Control: ВСЕМ ЗАТКНИСЬ -- я думаю, что у меня могут закончиться буферы.
Кратко о QoS: Ух ты, сколько трафика iSCSI, буферы заполняются. Лучше замедлите разговор или два, пока ситуация не вышла из-под контроля.
Теперь вы, серьезные администраторы SAN, чуть ли не плачете от мысли о потере нескольких пакетов хранилища iSCSI. Я знаю. Каждый из этих пакетов представляет собой запрос на чтение или запись данных, и какой-то сервер где-то задохнется на секунду, потому что его ввод-вывод не поспевает за ним.
Новости: в локальной сети закончились буферы. Заторы все равно происходили. Flow-Control МОЖЕТ сохранить ваши пакеты iSCSI, но он также может испортить кучу других невинных потоков трафика. QoS намеренно отбросил пару ваших пакетов и на мгновение снизил производительность сервера. Это, вероятно, должно было случиться в любом случае — помните, что происходили перегрузки.
Кульминация: iSCSI можно восстановить. TCP запросит повторную передачу того, что мы сбросили, поэтому ввод-вывод восстановится — в конце концов, потери данных не произойдет.
Итак, в конце концов, вот что я рекомендую вам делать с управлением потоком:
Отключите его везде по умолчанию.
Если это рекомендуется поставщиком вашего хранилища, включите его на портах, назначенных специально для устройств хранения.
Никогда не включайте его на любом порту, через который может передаваться VoIP, и никогда на коммутаторе, чтобы переключиться или переключиться на порт маршрутизатора.
QoS — это правильный способ сообщить вашей сети, какой трафик важен, какой трафик менее важен и что делать, если происходит перегрузка.
Теперь, в 10-гигабитной среде с включенным FCoE, Priority Flow-Control – это удобный инструмент, но он является частью общей архитектуры QoS в вашем центре обработки данных.
После того, как я недавно укусил механизм управления потоком данных в Ethernet, я решил узнать об этом малоизвестном, но часто используемом аспекте современных сетей. Этот пост представляет собой краткое изложение того, что я узнал о нем, а также связанных с ним преимуществах и опасностях.
Что такое управление потоком?
Управление потоком Ethernet, или 802.3x, — это способ для сетевого устройства сообщить своему непосредственному соседу, что оно перегружено данными, например, когда устройство получает данные быстрее, чем оно. может его обработать. Это позволяет перегруженному устройству отправлять специальный кадр Ethernet, называемый кадром паузы, который просит устройство на другом конце провода временно прекратить отправку данных. Если принимающее устройство соблюдает кадр паузы, у отправляющего устройства есть время, чтобы наверстать упущенное в стеке полученных данных, которые оно еще не успело обработать.Также существует более старый метод управления потоком, называемый "обратным давлением", который используется в полудуплексных средах (т. е. некоммутируемом Ethernet). Он заключается в том, что перегруженное устройство временно «глушит» носитель до тех пор, пока оно не сможет принять больше данных. Я мало что знаю об управлении полудуплексным потоком, поэтому не буду упоминать его снова; здесь все относится исключительно к полнодуплексному управлению потоком через 802.3x. Кроме того, TCP имеет собственный механизм управления потоком, который полностью отличается от управления потоком в Ethernet; Я не буду здесь полностью объяснять метод управления потоком TCP, так как он сам по себе заслуживает продолжительного обсуждения.
- Управление потоком работает на более низком уровне, чем TCP или IP, и поэтому не зависит от них. Иными словами, управление потоком можно использовать независимо от того, какие протоколы более высокого уровня наложены на него. Важным побочным эффектом этого является то, что ни TCP, ни IP не знают, что делает управление потоком Ethernet; они работают, исходя из предположения, что нет никакого управления потоком, кроме того, что они могут или не могут обеспечить сами.
- Функции управления потоком между двумя напрямую подключенными сетевыми устройствами, а кадры управления потоком никогда не пересылаются между ссылками. Таким образом, два компьютера, подключенные через коммутатор, никогда не будут отправлять кадры паузы друг другу, но могут отправлять кадры паузы самому коммутатору (и наоборот: коммутатор может отправлять кадры паузы обоим компьютерам).
- Кадры паузы имеют ограниченную продолжительность; они автоматически «сгорают» через определенное время. Время истечения устанавливается устройством, передающим кадр паузы.
- Приостановленная ссылка не является дискриминатором протоколов; это предотвратит передачу по ссылке любых данных, кроме дополнительных кадров паузы.
Отказ TCP
Хорошо, это неправда, TCP не перестает работать, когда включено управление потоком. Однако важная его часть перестает работать правильно: собственный механизм управления потоком. Управление потоком TCP использует более сложный механизм тайм-аутов и сегментов подтверждения, чтобы определить, когда удаленное устройство перегружено. В основном он отправляет все быстрее и быстрее, пока не увидит, что некоторые из отправленных им данных не попадают на удаленное устройство, а затем замедляется. Это позволяет TCP разумно использовать сетевые каналы, поскольку перегрузка сети или устройства приведет к потере некоторых сегментов TCP и, таким образом, к снижению скорости отправки данных отправителем.Теперь рассмотрим, что происходит, когда управление потоком Ethernet смешивается с управлением потоком TCP. Предположим, что у нас есть два напрямую подключенных компьютера, один из которых намного медленнее другого. Более быстрый отправляющий компьютер начинает отправлять много данных более медленному принимающему компьютеру. Получатель в конце концов замечает, что он перегружен данными, и отправляет кадр паузы отправителю. Отправитель видит кадр паузы и временно прекращает отправку. По истечении кадра паузы отправитель возобновит отправку потока данных на другой компьютер. К сожалению, механизм TCP на отправителе не распознает, что получатель перегружен, так как не было потерянных данных — получатель обычно останавливает отправителя до того, как он потеряет какие-либо данные. Таким образом, отправитель будет продолжать ускоряться в геометрической прогрессии; поскольку он не видел потерянных данных, он будет отправлять данные в два раза быстрее, чем раньше! Поскольку приемник имеет постоянный недостаток скорости, это потребует от приемника отправлять кадры паузы в два раза чаще. Все начинает развиваться как снежный ком, пока получатель не останавливает отправителя так часто, что отправитель начинает сбрасывать свои собственные данные до того, как отправит их, и, таким образом, наконец видит, что некоторые данные теряются, и замедляется.
Это проблема? В некотором смысле это не так.Поскольку TCP является надежным протоколом, на самом деле ничего не «теряется»; оно просто ретранслируется, и жизнь продолжается. В этой ситуации управление потоком Ethernet выполняет то же самое, что и управление потоком TCP, поскольку оба они замедляют передачу данных до скорости, с которой может справиться более медленное устройство. Есть некоторые аргументы в пользу того, что между двумя механизмами управления потоком существует неудобное перекрытие, но могло быть и хуже.
К сожалению, бывает и хуже.
Блокировка начала строки
В последнем примере я рассмотрел случай, когда два компьютера были напрямую связаны друг с другом. Этот пример слишком упрощен, чтобы быть полезным — когда вы в последний раз видели два напрямую подключенных компьютера? Это немного редкость. Давайте теперь посмотрим, что происходит, когда вы вводите переключатель в микс. Для наших целей предположим, что коммутатор полностью поддерживает управление потоком Ethernet и готов его использовать. Наша новая установка будет состоять из двух настольных компьютеров и одного файлового сервера, все они подключены к коммутатору. Делать все идеально неинтересно, поэтому давайте также предположим, что один из рабочих столов подключен к коммутатору со скоростью 10 Мбит/с, а другой рабочий стол и сервер подключены со скоростью 100 Мбит/с.Обычно эта настройка подходит: соединение со скоростью 10 Мбит/с будет медленнее, чем другие, но это не вызовет особых проблем, просто медленнее будет обслуживаться один рабочий стол. Однако все может стать ужасно, если на коммутаторе включено управление потоком Ethernet. Представьте, что рабочий стол со скоростью 10 Мбит/с запрашивает большой файл с файлового сервера. Файловый сервер сначала начинает отправлять файл на рабочий стол медленно, но быстро набирает обороты. В конце концов файловый сервер начнет отправлять данные на рабочий стол со скоростью 11 Мбит/с, что больше, чем может выдержать плохое соединение со скоростью 10 Мбит/с. Если на коммутаторе не включено управление потоком, коммутатор начнет просто отбрасывать сегменты данных, предназначенные для рабочего стола, что файловый сервер заметит и начнет снижать скорость отправки.
Однако если на коммутаторе включено управление потоком, коммутатор использует совершенно другой подход; он будет отправлять свои собственные кадры паузы на любой порт, который отправляет данные на перегруженный порт 10 Мбит/с. Это означает, что файловый сервер получит кадр паузы от коммутатора, запрашивающий прекращение всех передач на определенное время. Это проблема? Да! Поскольку кадры паузы останавливают все передачи по каналу, любые другие данные, отправляемые файловым сервером, также будут приостановлены, включая данные, которые могут быть предназначены для настольного компьютера со скоростью 100 Мбит/с. В конце концов пауза истечет, и файловый сервер продолжит отправку данных. К сожалению, механизм TCP на файловом сервере не будет знать, что что-то не так, и будет продолжать отправлять данные со все большей и большей скоростью, тем самым снова перегружая рабочий стол со скоростью 10 Мбит/с. Как и прежде, цикл будет повторяться до тех пор, пока файловый сервер не начнет сбрасывать свои собственные данные. В отличие от предыдущей ситуации, невиновный наблюдатель рабочего стола со скоростью 100 Мбит/с будет оштрафован, и скорость его передачи с файлового сервера упадет до 10 Мбит/с.
Эта ситуация называется блокировкой очереди, и это основная причина, по которой использование управления потоком Ethernet несколько опасно. Когда он включен на сетевых коммутаторах, он может создавать ситуации, когда один медленный канал в сети может привести к сканированию остальной сети. Это становится особенно плохо, если в магистралях вашей сети включено управление потоком; к этому моменту должно быть очевидно, насколько это может быть плохо.
Читайте также:
