Общие вопросы выбора технологий

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

Когда же технологии маршрутизации оказывается недостаточно? Это проис­ходит в том случае, когда сети, построенные на маршрутизаторах, перерастают в своем развитии некий естественный предел, обусловленный функциональными возможностями маршрутизаторов. Как правило, такое «насыщение» возникает в результате широкого внедрения новых приложений. В таких ситуациях первой реакцией на жалобы пользователей, недовольных увеличением времени реакции сети, может быть внедрение высокоскоростных коммутаторов на границе ло­кальной сети и магистрали ATM. Когда пользователи, находящиеся в разных подсетях, обмениваются данными между собой, весь этот трафик проходит через магистральные маршрутизаторы, что становится особенно критично при резком увеличении трафика. Даже при установке быстрых маршрутизаторов, способных обрабатывать до 500 000 пакетов в секунду, они все равно становятся узким местом применительно к трафику между подсетями.

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

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

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

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

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

Тезис ведущих производителей «коммутировать по возможности, маршру­тизировать по необходимости» призывает организации внедрять у себя комму­таторы повсеместно. Маршрутизаторам же этот тезис не оставил практически никаких шансов на их широкое применение в будущем.

В последнее время внедрение коммутаторов в сети носит лавинообразный характер. Администраторы совершенно справедливо обосновывают необходи­мость широкого развертывания коммутаторов следующими соображениями:

q Высокая пропускная способность и низкая задержка. Коммутаторам, в общем случае, не требуется анализировать содержимое дейтаграмм, кор­ректировать поле TTL (если речь идет о протоколе IP), пересчитывать контрольную сумму и т. д.

q Низкая стоимость в расчете на один порт. Маршрутизаторы значительно более дорогие устройства по сравнению с коммутаторами. Их стоимость в расчете на один порт примерно в 6 раз больше.

q Простота управления. Большинство коммутаторов начинают работать в сети сразу с момента их установки и не требуют дополнительных настро­ек. Маршрутизаторы же известны сложностью настройки, для проведения которой администратору вручную требуется правильно установить огром­ное количество параметров.

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

Так как коммутаторы «выросли» из мостов, они унаследовали многие нега­тивные стороны последних. Основным недостатком является то, что при исполь­зовании исключительно коммутаторов, сеть получается «плоской». Главной проблемой таких сетей является влияние неконтролируемого широковещатель­ного трафика на производительность.

Говоря о широковещании и связанных с ним проблемах, можно выделить два основных типа широковещательных пакетов. Это пакеты, запрашивающие ста­тус сетевого устройства или его доступность в настоящий момент, и пакеты, которые объявляют об услугах, предоставляемых определенными устройствами. Примерами первых пакетов могут служить сообщения, генерируемые протоко­лом ARP, или запросы на разрешение NetBIOS-имени в сетях Microsoft. Приме­ром второго типа пакетов могут служить сообщения протоколов маршрутизации RIP IP, OSPF, RIP/SAP IPX и т. д. В табл. 17.1 приведены общий перечень протоколов, вызывающих широковещательный трафик, и частота его появления.

Таблица 17.1. Перечень протоколов, вызывающих широковещательный трафик

Протокол	Источник широковещания	Цель широковещания	Частота широковещания (по умолчанию)
Протокол объявления об ус­лугах — Novell NetWare SAP (Service Advertising Protocol)	Сервера Novell Netware/клиенты Novell Netware	Информирование о предос­тавляемых услугах/обнару­жение ближайшего сервера	Один раз в минуту каж­дым сервером в сети/при старте клиента
Протокол маршрутизации RIP (Routing Information Protocol)	Маршрутизаторы в сетях IP или IPX	Информирование соседних маршрутизаторов об извест­ных маршрутах в подсети	Один раз в минуту каж­дым маршрутизатором в сети
Протокол определения фи­зического адреса ARP (Ad­dress Resolution Protocol)	Рабочие станции, работающие с протоколом IP	Определение по известному IP-адресу получателя его физического адреса	При взаимодействии клиентов с сервером или между собой
Протокол определения логи­ческого адреса (NetBIOS Name Query)	Рабочие станции в сетях Microsoft	Определение по известному имени получателя его логи­ческого адреса, например IP-адреса	При взаимодействии клиентов с сервером или между собой

Широковещательный трафик может достигать значительного объема в боль­ших сетях с сотнями устройств (300 и более). Увеличение широковещательного трафика снижает полезную пропускную способность сети, что отрицательно ска­зывается на работе приложений, критичных к задержкам.

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

До некоторого времени при проектировании все следовали основному прави­лу, которое гласило, что 80 % сетевого трафика должно оставаться в рабочей группе, и только остающимся 20 % трафика разрешается циркулировать между группами. Однако с появлением новых приложений, особенно мультимедийных, в современных корпоративных сетях изменился характер трафика — теперь зна­чительно большая его часть приходится на связь между рабочими группами. Наблюдается постепенный сдвиг в сторону поддержки связей типа точка-точка между любыми устройствами в сети, в том числе, принадлежащими различным рабочим группам.

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

Таким образом, знакомое всем правило 80/20 преобразуется в другое прави­ло — 20/80, то есть 20 % трафика остается в рабочей группе, а 80 % трафика относится к взаимодействию групп между собой. Такое изменение, помимо при­веденных выше соображений, обусловлено также бурным развитием корпора­тивных интрасетей.

Как видно, провозглашенный производителями тезис «коммутировать по возможности, маршрутизировать по необходимости» не является абсолютно безоговорочным — маршрутизация в современных сетях все еще требуется до­статочно часто. И, как следствие, уже не является сюрпризом то, что производи­тели разрабатывают альтернативные технологии, комбинирующие коммутацию и маршрутизацию. За счет использования этих новых технологий производите­ли пытаются решить две основные проблемы:

q Уменьшение показателя «стоимость/производительность». Производи­тели очень хотели бы объединить все достоинства маршрутизаторов с вы­сокой производительностью и низкой стоимостью коммутаторов;

q Повышение масштабируемости в глобальных сетях. Еще одной причи­ной комбинирования коммутации и маршрутизации является попытка ре­шить проблему, возникающую в сетях ATM и Frame Relay. В таких сетях все граничные маршрутизаторы находятся как бы на расстоянии одного перехода друг от друга — это происходит за счет формирования виртуаль­ных каналов (в случае Frame Relay — DLCI, в случае ATM — VPI/VCI) между ними даже в сложной, смешанной топологии. Однако увеличение числа виртуальных каналов на втором уровне приводит к быстрому росту отношения числа определяемых на третьем уровне маршрутов к числу маршрутизаторов.

Например, если N — это число узлов, то формула для числа виртуальных однонаправленных соединений всех узлов друг с другом имеет вид N4(N-1) (сумма арифметической прогрессии). Используя эту формулу, легко вычислить, что для связи 5 узлов потребуется 20 виртуальных (однонаправленных!) соединений. При добавлении всего лишь одного узла потребуется уже 30 виртуаль­ных соединений.

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

Дата добавления: 2015-07-13