Управление трафиком в корпоративных сетях

Брюс Робертсон

Представьте себе, что вы планируете изменить маршрут движения городского транспорта в связи с часто возникающими "пробками". Как обеспечить беспрепятственный проезд машин "скорой помощи", президентского кортежа, грузовиков? Не забыть бы также налогоплательщиков, которые не должны страдать от увеличения количества транспорта.

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

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

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

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

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

Профилирование трафика

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

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

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

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

Присвоение приоритетов на этапе маршрутизации

Если вы используете в своей сети маршрутизаторы, попробуйте для начала вариант присвоения уровней приоритетов различным видам трафика на этапе маршрутизации. Большинство маршрутизаторов определяют уровень либо по источнику трафика, либо по адресу назначения, либо, что даже лучше, по номерам ТСР-портов (в соответствии с определенными приложениями). Управление несколькими маршрутизаторами для поддержки согласованности этих соответствий может оказаться достаточно сложным, тем не менее такие компании, как Cisco Systems, постоянно работают в направлении поддержки все более централизированных и управляемых конфигураций (продукт NetSys).

Трафик с максимальным уровнем приоритета (создаваемый, tn3270, SAP R/3 либо двухуровневыми приложениями связующего ПО для удаленного доступа к данным типа клиент--сервер) должен проходить через маршрутизатор или коммутатор быстрее, чем любой другой трафик, менее интерактивный, но более "объемистый" и разбитый на пакеты, такой, как FTP, HTTP или e-mail. Используя различные технологии, например Fair Weighted Queuing фирмы Cisco, низкоприоритетный трафик можно направлять в очередь на ожидание передачи. Если в какой-то момент ожидающие своей очереди пакеты вдруг потеряются, протокол ТСР или соответствующее приложение просто повторят попытку их доставки.

Подходы к профилированию трафика

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

Большинство этих средств направляют трафик в очередь почти так же, как это делают маршрутизаторы, но при этом они более точно идентифицируют его. Используемые в них графические консоли администрирования позволяют профилировать трафик с помощью схем приоритетов (следует отметить, что некоторым из них все-таки недостает "легкости" в управлении несколькими устройствами). Так, например, продукт FloodGate-1 фирмы Check Point Software Technologies может идентифицировать множество приложений, поскольку в нем поддерживается та же функция контроля Stateless Inspection, что и в продукте FireWall-1 этой же фирмы. Продукты, предоставляющие аналогичный сервис, -- это Aponet и Xedia.

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