Оборотная сторона коммутации

Коллизии пакетов могут привести к нарушению работы коммутаторов локальных и ATM-сетей. Этого, однако, можно избежать.

Вычислительная сеть работает медленно. Тупо уставившись на экран монитора, пользователи пытаются заметить хоть какие-нибудь изменения в картинке - и не видят ничего. Сеансы либо прерываются по тайм-ауту, либо зависают в результате заторов в сети. Руководство раздраженно твердит о снижении производительности труда. Сетевому администратору небо кажется с овчинку, его лишают премии и заводят разговоры о понижении зарплаты. Что делать?! Миллионы людей во всем мире в ответ воскликнут: "Ставить коммутатор!" Они убеждены, что заменой маршрутизаторов на коммутаторы можно решить все проблемы локальной сети. Действительно, нас уверяют, что коммутация быстрее маршрутизации, что при ее использовании можно добиться повышения производительности, снижения времени реакции сети и даже обеспечения обмена аудио- и видеоинформацией в локальной сети.

А стоит ли? Реселлеры, устанавливающие LAN-коммутаторы и обладающие большим опытом в этой области, жалуются на потерю пакетов в каналах связи "коммутатор-сервер" или "коммутатор-коммутатор". Проблемы не настолько серьезны, чтобы задуматься, полезна ли коммутация вообще, но их достаточно для возникновения потребности в исследовании, которое позволит ответить на вопрос, как на самом деле коммутация влияет на производительность сети. Это исследование даст возможность сделать некоторые выводы: когда коммутация полезна для данного конкретного пользователя, а когда - нет.

Как работает коммутатор?

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

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

Коммутация в сетях ATM несколько отличается от описанной. При работе с ATM (или frame relay) приходится учитывать ограниченность пропускной способности сети. Это означает, что сеть сама должна следить за тем, чтобы исходящий от приложений трафик не вызывал ее переполнения. Поэтому в ATM-коммутации используется понятие "сеанс связи" (иначе "вызов" или "соединение"). Перед установлением соединения узел сети сообщает, какие ресурсы ему понадобятся. Выделяя эти ресурсы, сеть соответствующим образом уменьшает пул доступных ресурсов. Если ресурсов не хватает, то соединение не устанавливается, если же их достаточно, сеть следит, чтобы объем посланных данных не превысил согласованного значения. Эти действия выполняются адаптером порта, к которому подключен компьютер пользователя, инициирующего сеанс.

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

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

Что же произойдет при превышении пропускной способности коммутатора, не оснащенного буферами? Как это ни удивительно, но при некоторых условиях сеть с коммутаторами станет работать медленнее - или вообще не будет.

Коллизии на выходном порту

Порт назначения информации, исходящей с той или иной станции, определяется либо на основании MAC-адресов (при коммутации в локальных сетях), либо по идентификатору Virtual Channel/Virtual Path (при ATM-коммутации). Казалось бы, если скорости работы коммутатора хватает на обеспечение передачи данных от любого порта к любому другому, то никаких проблем быть не должно. Именно это мы и просили вас запомнить.

Оказывается, все не так просто. Важно еще и то, хватит ли скорости выходного порта. Именно с коллизиями на выходном порту и связана проблема низкоскоростных магистральных линий. Если интенсивность трафика составляет 20 Мбит/с, а направлен он в порт с пропускной способностью 10 Мбит/с, то часть информации будет потеряна. В коммутаторах с большими буферами на портах избыток данных накапливается "в надежде" на то, что в какой-то момент спадет напряженность трафика и вся информация будет доставлена. Когда размер буферов невелик или коллизии происходят чересчур интенсивно, часть данных пропадает.

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

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

Коллизии на выходном порту - отнюдь не маловероятные события. Они обычно происходят на каналах связи с серверами и магистралях "коммутатор-коммутатор". Чем медленнее выходная линия, тем выше вероятность коллизии на выходном порту. Совместное использование выходного порта напоминает разделение носителя в локальной сети, что довольно забавно, поскольку коммутацию, собственно, придумали именно для того, чтобы избежать проблем с разделением ресурсов. Насколько это плохо? Исследование коммутируемых локальных сетей, выполненное корпорацией CIMI, показало, что восемь входных портов, работающих с приложениями клиент-сервер, могут так перегрузить порт линии "коммутатор-коммутатор", что эффективная пропускная способность упадет со 100 до 18 Мбит/с. Аналогичные данные CIMI получила от одного поставщика коммутаторов для локальных сетей.

Так что же, решением задачи является использование ATM? Нет, поскольку во многих текущих версиях ATM имеются аналогичные проблемы. В ATM-протоколах LANE (LAN emulation) и MPOA (Multi-Protocol over ATM) используется уровень сервиса UBR (unspecified bit rate, неопределенная скорость передачи данных). При работе с UBR станция-источник не описывает поток трафика, который будет сгенерирован, а сеть не резервирует ресурсы под этот поток, не обеспечивает управления потоком и не ограничивает скорость генерации данных на станции-источнике. Информация поступает на коммутатор с той скоростью, которую поддерживает входной порт. При поступлении нескольких потоков на один и тот же выходной порт (который поддерживает такую же или даже меньшую скорость передачи данных) происходят случайные коллизии (аналогичные коллизиям потоков данных в локальной сети без установления соединения - connectionless LAN flow), приводящие к потерям информации. Компания CIMI опросила пользователей популярного ATM-коммутатора, столкнувшихся с такой проблемой при организации связи двух коммутаторов кампуса по каналу T-3. Клиентские и серверные системы работали на скорости 155 Мбит/с, при этом коллизии выходного порта линии T-3 были настолько интенсивными, что исполнение приложений прерывалось по тайм-ауту.

Что можно сделать?

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

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

В ATM-коммутаторах обычно используется буферизация. Однако, как показывает вышеупомянутый пример, множественные потоки UBR ATM, исходящие из быстрых портов, способны перегрузить даже буферы ATM. Если буферы объединены в центральный пул, то иногда невозможно закрепить буфер за отдельным перегруженным выходным портом. Еще раз напомним: как бы велики ни были буферы, они все равно могут оказаться перегруженными, если нельзя ограничить активность источников информации.

Второй подход состоит в такой организации коммутации и работы выходных портов, чтобы источник сообщения знал, что происходит "борьба" за ресурс выходного порта до окончания передачи данных. На входном порту возникает нечто вроде виртуальной коллизии на MAC-уровне, а в результате станция-источник бывает вынуждена прекратить передачу и повторить попытку через некоторое время. Данная возможность похожа на функцию обнаружения коллизий в локальных сетях с разделением носителя. Очевидно, этот подход работает только в сетях с обнаружением коллизий на MAC-уровне, например в Ethernet, а в сетях Token Ring или FDDI управление потоками на MAC-уровне невозможно.

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

Ожидается, что в ATM управление исходящими от станций потоками данных будет обеспечиваться за счет использования уровня сервиса ABR (available bit rate, доступная скорость передачи данных), однако пока ABR распространен не слишком широко и большинство производителей коммутаторов применяют его только для подключения к ATM настольных станций. В частности, ABR недоступен для трафика от адаптеров старого образца, поступающего в ATM-коммутатор с LANE и MPOA. Некоторые члены ATM Forum продвигают изменения в стандартах LANE и MPOA, в результате которых можно будет использовать как ABR, так и UBR. Часть производителей оборудования ATM, в частности IBM, обеспечивает определенный уровень управления трафиком и распределения ресурсов даже для пользователей LANE/UBR. В конце концов большинство производителей примет ABR в качестве дополнительной функции для LANE и MPOA, если он станет составной частью стандартов.

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

А что делать, если ни один из выбранных производителей не обеспечивает устранения коллизий на выходном порту? Для всех типов коммутаторов есть третий подход, который стоит серьезно обдумать. Он состоит в том, что выходной порт должен быть существенно быстрее портов-источников, передающих ему данные. Это позволит настолько снизить число коллизий, что они перестанут оказывать серьезное влияние на работу сети. Даже в локальных сетях, успешно борющихся с коллизиями с помощью буферизации или средств управления потоком, ускорение работы портов коммутаторов и каналов связи снизит задержки и улучшит работу приложений.

Стоит заметить, что большинство производителей рекомендуют именно этот подход. Даже покупатели и реселлеры отмечают, что если в сети Ethernet на 10 Мбит/с использовать для связи с сервером или коммутатором каналы на 100 Мбит/с, то коллизии становятся настолько редкими, что большинство приложений просто перестает их замечать. Реселлерам особенно нравится этот вид конфигурации, поскольку он уменьшает проблемы с поддержкой. Самая большая выгода от применения Gigabit Ethernet - это возможность предоставлять совместно используемым логическим портам полосу пропускания, предупреждающую возникновение коллизий и потерю работоспособности сети даже при работе с клиентами со скоростью 100 Мбит/с.

Так какой же нужен запас по полосе пропускания? Мы не обладаем исчерпывающими данными в этой области, однако беседы с пользователями и поставщиками показывают, что порт канала связи должен быть по крайней мере в 5-6 раз быстрее портов-источников. Необходимая разница в скорости может оказаться и большей, если много источников "набросятся" на один выходной порт. Стратегия Ethernet "каждое поколение в 10 раз быстрее предыдущего" обеспечивает выполнение данного требования. Что касается ATM, работоспособным будет сочетание клиентских портов ATM25 с 155-мегабитными каналами связи и серверными соединениями. Для более быстрых клиентов потребуется увеличить скорость каналов связи до 622 Мбит/с.

Простая истина

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

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

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