Советы с переднего края: как перестроить сеть, используя новейшие технологии коммутации и маршрутизации.
Если вам довелось быть сетевым администратором или проектировщиком сети крупной корпорации и проработать достаточно долго, вы, скорее всего, принимали многие наиболее важные решения по проектированию сетей в начале 90-х гг. Затем пару лет занимались расширением своей сети, чтобы она дотянулась до всех уголков корпорации. И не успели вздохнуть с облегчением после хорошо сделанной работы, как поставщики и отраслевые аналитики начали называть вашу сеть устаревшей и предупреждать, что неизбежно потребуется большая пропускная способность, чем та, которую она способна поддерживать.
К концу 1995 г. сетевой пейзаж стал выглядеть довольно запутанным. В качестве альтернативных вариантов для удовлетворения потребностей в пропускной способности предлагались такие технологии, как коммутируемый Ethernet, 100Base-T, 100VG-AnyLAN, Copper Distributed Data Interface (CDDI) и АТМ, однако было неясно, какие из них выживут, а какие нет. Некоторые производители прямо-таки одержимы идеей сокращения времени ожидания в сетях и считают, что сети необходимо делать плоскими и коммутируемыми, а место маршрутизации - на периферии глобальной сети.
Если вам повезло, то ваш сетевой трафик не был таким интенсивным, как предполагали эксперты, и вы могли позволить себе подождать, пока в отрасли все утрясется. Однако теперь уровни трафика вызывают законное беспокойство, и пора принимать меры. Фактически пришло время перестраивать сеть. И хотя некоторые моменты стали яснее - например, очевидно, что технологии CDDI и 100VG-AnyLAN вряд ли найдут широкое применение в будущем, - теперь пути решения многих проблем сетей следующего поколения (в частности, соотношения коммутации и маршрутизации) даже менее ясны, чем раньше. Так что же следует предпринять?
Движущие силы
Прежде всего, вы должны понять, зачем нужно увеличивать производительность вашей сети. Обычно это требуется при использовании определенных приложений или необходимости перераспределения сетевых ресурсов. Ваши проблемы, как правило, обусловлены описанными ниже факторами:
Заметьте, что большая часть данных факторов имеет нечто общее: они имеют тенденцию генерировать дополнительный трафик; при этом доля внешнего трафика относительно больше, чем локального. Внешним мы назвали трафик, выходящий за пределы той части сети, которая традиционно считалась ЛВС-сегментом и часто эквивалентна локальной подсети TCP/IP. Создавая сеть 4-8 лет назад, вы были уверены, что около 80% трафика станет циркулировать в пределах данного ЛВС-сегмента. Это обуславливалось тем, что тогда многие ЛВС использовались для функционирования относительно несущественных приложений автоматизации офисной деятельности, например текстовых процессоров и электронных таблиц. Обычно каждый ЛВС-сегмент имел свой собственный файловый и принтерный сервер; трафик в этой сети формировался главным образом клиентами, загружающими с локального сервера исполняемые и прочие файлы приложений и осуществляющими печать через принтерный сервер. Критически важные для бизнеса приложения выполнялись на параллельных сетях типа терминал-хост, таких как SNA. По существу, весь трафик в сетях терминал-хост был внешним.
Трафик к файловым и принтерным серверам и от них представляет особенный интерес, поскольку он часто составляет более 50% объема сетевого трафика и может оказывать глубокое воздействие на всю его структуру. Администраторы ЛВС все больше склоняются к переходу на централизованные файловые и принтерные серверы, что позволяет минимизировать работу, связанную с перемещением сотрудников. Если такие серверы находятся в распределенных ЛВС-сегментах, то при перемещении какого-либо сотрудника в иной ЛВС-сегмент сетевой администратор должен передавать его идентификационную информацию и файлы с одного сервера на другой. Если этого не сделать, трафик будет проходить от пользователя к серверу через маршрутизатор; когда он достигнет достаточно большого объема, в маршрутизаторах начнется выпадение пакетов, и перед вами неизбежно встанет проблема производительности.
Поскольку большая часть перемещений персонала происходит в пределах одного здания, администраторы ЛВС предпочитают переходить на меньшее количество более крупных файловых и принтерных серверов, размещенных в центре здания. Они также хотят, чтобы не требовалось разбираться в структуре сегментов сети или подсети, в которой размещены пользователи и серверы, и чтобы при перемещении сотрудников нужно было всего лишь менять сетевые адреса (в случае работы с протоколом TCP/IP), что существенно снизило бы трудоемкость работы администратора. Если адресация внутри здания "плоская" или реализована обширная виртуальная ЛВС, охватывающая все здание, то не потребуется даже менять адреса и располагать сервер в центре. Данный аргумент часто приводят сторонники виртуальных сетей и соответствующих технологий, хотя при этом они часто преувеличивают трудности изменения адреса TCP/IP и редко вспоминают о проблеме перемещения файлов и идентификаторов с сервера.
Быть или не быть маршрутизации?
Что все это значит для тех, кто создает сети следующего поколения? Главное, что нужно иметь в виду: в вашей сети будет уже не 80% локального трафика - этот трафик будет уходить за границы сегмента, причем его большая часть (в том числе, трафик между файловым и принтерным серверами, находящимися в компьютерной комнате) останется внутри здания. Если вы связали подсети TCP/IP и сети Novell с помощью сегментов Ethernet или Token Ring, то выход трафика за пределы сегмента означает его прохождение через маршрутизатор. Вы можете обойтись без применения маршрутизатора, применив плоскую схему адресации в сети или виртуальную ЛВС. Однако следует ли это делать?
Многие поступают так, чтобы избежать проблем, связанных со "связующим деревом" (spanning tree) или "штормами" широковещательных пакетов в своих обширных плоских соединенных мостами сетях. Если вы занимались сетями в конце 80-х гг., то, скорее всего, сталкивались с ситуацией, когда мостовые соединения выводили из строя всю сеть. Такая особенность плоских соединенных мостами сетей в начале 90-х гг. стала главным аргументом таких компаний, как Cisco Systems и Wellfleet Communications (ныне Bay Networks). Эти производители твердили о важности разделения наших сетей на подсети меньшего размера, которые должны соединяться с помощью их маршрутизаторов, и о том, что за счет этого сетевые проблемы остаются в пределах подсети. Честно говоря, они были правы, благодаря чему и добились огромных успехов.
В ответственных сетях, какие имеются, например, в финансовой отрасли, производительность всегда важна, однако ключевыми характеристиками являются работоспособность и надежность. Разделение на подсети и маршрутизация обеспечивают требуемую надежность, от них не следует бездумно отказываться. Предлагаемое некоторыми производителями уплощение пространства сетевых адресов во всем здании или в пределах кампуса, которое позволяет коммутировать, а не маршрутизировать трафик, - устрашающая мысль. Применение схемы виртуальных ЛВС позволяет решить некоторые проблемы за счет объединения пользователей в широковещательные домены, однако для расширения таких доменов (сегментов или подсетей) с включением в них разнообразных сетевых устройств и офисов обычно применяются мосты и связующие деревья. Это очень похоже на ту базовую технологию, с которой были связаны наши проблемы в конце 80-х гг. Кроме того, в соответствии с рекламными заявлениями данные схемы позволяют произвольно расширять подсети, включая в них различные коммутаторы, для того чтобы уйти от необходимости изменения адресов TCP/IP на оконечных станциях. Но при этом может быть создана среда, которой намного труднее управлять и в которой сложнее устранять неисправности, чем обычно.
С другой стороны, технология АТМ слишком непохожа на базовую технологию начала 90-х гг., чтобы полагаться на нее как на основу крупной плоской коммутируемой сети, - по крайней мере, до тех пор, пока она не проявит себя в ряде ответственных систем. Лишь немногие производители и пользователи имеют опыт разработки, построения и, что наиболее важно, борьбы с неисправностями в крупных корпоративных АТМ-сетях. Если технологию АТМ необходимо применять в средах с большим количеством подсетей, требуется более четко определить функциональные возможности сетевого уровня. Технология Gigabit Ethernet также представляет собой значительную угрозу будущему применению АТМ в кампусных сетях. Можно много говорить о том, почему необходимо придерживаться принципа "простых решений", которому как раз и соответствует использование Ethernet для вашего здания или кампуса.
Так что же делать, если вы хотите не только сохранить надежность вашей разделенной на подсети и маршрутизируемой сети, но и приготовиться к переводу здания или кампуса на крупные централизованные серверы, а следовательно, к принятию обратного правила "80:20"? Вы рассчитываете на то, что высокопроизводительные коммутаторы сетевого уровня будут работать так, как рекламируется, т. е. маршрутизировать/ коммутировать ваши наиболее важные протоколы, а именно TCP/IP и IPX, со скоростью и при затратах, сопоставимых с аналогичными показателями для коммутаторов канального уровня. Вам бы хотелось, чтобы все это обеспечивалось максимально просто и стандартизованно.
Продукты, обеспечивающие коммутацию сетевого уровня, поражают разнообразием: мы имеем технологию IP Switching от компании Ipsilon Networks и ее сторонников, в том числе корпорации Digital Equipment; технологию Multi-Protocol over ATM от таких приверженцев технологии АТМ, как фирма FORE Systems; технологии NetFlow Switching и Tag Switching от компании Cisco; службы Multiprotocol Switched Services от IBM; технологию Fast IP от корпорации 3Com и т.д. Однако некоторые из этих подходов больше ориентированы на решение задач масштабирования глобальных сетей, а не тех проблем, которые находятся в центре внимания данного обсуждения. Большинство из них в той или иной степени нестандартны и довольно-таки навязчивы. Стратегии разных производителей несовместимы между собой или не согласуются в частностях. В обмен на свои преимущества они обычно требуют от вас того, что вы предпочли бы не делать:
Положительным фактором является то, что много творческой энергии направлено на создание технологии коммутации сетевого уровня и быстрой маршрутизации, поэтому рано или поздно кто-либо доведет ее до нужного уровня. Компания Cisco и некоторые начинающие фирмы имеют кое-какие интересные разработки гигабитных маршрутизаторов. Хотя эта работа первоначально была в основном нацелена на Internet, технологические находки постепенно дойдут и до корпоративных пользователей.
Недавно анонсированное компанией Bay и уже готовое к выпуску устройство Switch Node больше предназначено для корпоративных сетей и, по утверждениям представителей фирмы, сможет действовать как коммутатор сетевого уровня с малыми задержками (менее 50 мкс), чья скорость передачи составляет свыше 1 млн пак./с. Предлагая в этом устройстве интересное средство IP AutoLearn, компания Bay заявляет, что оно позволяет внедрять IP-коммутацию без каких-либо изменений конфигурации сетевых маршрутизаторов, коммутаторов или конечных станций. Планируется, что по стоимости Switch Node будет ближе к коммутатору, чем к маршрутизатору.
При создании устройства Switch Node компания Bay учитывала тот факт, что требования к маршрутизации внутри зданий (и до некоторой степени - в кампусах) менее жесткие, чем обобщенные требования к магистрали. В частности, трафик внутри зданий передается, главным образом, по протоколам IP и IPX при минимальной потребности в фильтрации и назначении приоритетов. Эти функции чаще используются в глобальных сетях, когда на первый план выходят соображения защиты и пропускной способности. Кроме того, большая часть трафика внутри здания передается между рабочими станциями и файловыми и принтерными серверами. Когда данные серверы расположены в центре, в компьютерной комнате, такой трафик обычно проходит всего лишь через один или два маршрутизатора. Следовательно, схемы повышения производительности за счет использования нескольких центров здесь неприменимы.
Эти особености корпоративных сетей позволяют производителям не учитывать в своих устройствах поддержку множества протоколов и новейших функций, которые входят в ПО традиционных маршрутизаторов. Вместо этого они могут попытаться создать систему очень быстрой и простой передачи данных по протоколам IP и IPX сетевого уровня.
К настольным ПК - по восходящим каналам
Если в вашей компьютерной комнате имеется устройство, способное осуществлять высокопроизводительную коммутацию сетевого и канального уровней, то разработать проект подключения остального оборудования - задача довольно простая.
Начнем с настольных ПК. Большинство клиентов и производителей согласятся, что технология АТМ, похоже, не будет использоваться на уровне настольных систем по крайней мере в течение пяти лет, так что уделим основное внимание Ethernet. Выделенная коммутируемая сеть Ethernet на 10 Мбит/с, подведенная к каждому настольному ПК, - хорошее решение, во всяком случае на ближайшие годы. Если учесть, что расходы на коммутируемую Ethernet в настоящее время приближаются к обычным затратам на совместно используемые порты Ethernet, в конечном счете подход микросегментации (множество совместно используемых сегментов на одном адаптере коммутации) не даст никакой экономии. Подключение настольных ПК к Ethernet на 100 Мбит/с для большинства корпоративных пользователей пока является излишней роскошью. Благодаря технологии сжатия видеоданных даже видеосигналы телевизионного качества не будут потреблять, по-видимому, больше 400 кбит/с на сеанс связи, так что одной 10-мегабитной выделенной линии на каждый настольный ПК должно быть достаточно.
Если в центре вашего здания имеются хорошие средства коммутации на сетевом уровне, вы можете использовать общий коммутатор в распределительном шкафу. Стремитесь подобрать такой коммутатор, который обеспечивает те же свойства, что и хороший концентратор (высокую надежность, отсутствие единой точки отказа в блоке и т.д.), а кроме того - зеркальное отображение портов для поддержки оборудования анализаторов протоколов.
При организации восходящих (uplink) соединений необходимо сделать выбор между ATM и Fast Ethernet. Для тех, кто ценит простоту, предпочтительным вариантом станет Fast Ethernet. Однако ваша система должна будет работать долго, поэтому удостоверьтесь, собираются ли производители устанавливаемого оборудования для центрального и распределительных шкафов поддерживать восходящие каналы ATM и Gigabit Ethernet. Полезным окажется способ объединения восходящих портов Ethernet на 100 Мбит/с на основе отраслевого стандарта, позволяющий эффективно создавать каналы на 200, 300 Мбит/с и т. д. Однако сейчас нет отраслевого стандарта, который давал бы возможность сочетать оборудование различных производителей.
В кампусе и за его пределами
Итак, в ваших кабельных шкафах есть коммутаторы Ethernet на 10 Мбит/с, соединенные с новым коммутатором сетевого уровня в центре здания. Что дальше?
Если в кампусе всего несколько зданий и вы смогли протянуть между ними оптоволоконный кабель, следует предусмотреть резервное коммутационное устройство, которое будет подключено непосредственно к коммутаторам сетевого уровня в здании или к традиционным маршрутизаторам, расположенным перед этими коммутаторами. Необходимость в традиционных маршрутизаторах определяется вашими требованиями к протоколам и особенностями коммутаторов сетевого уровня.
Выбирая коммутатор кампуса, снова рассмотрите варианты АТМ и Fast Ethernet. Лучше остановиться на Fast Ethernet, сохранив для себя возможность перехода на АТМ или Gigabit Ethernet в будущем. В следующие два года прояснится, какая из двух технологий станет на рынке победителем, и если вам потребуется большая пропускная способность сети, вы сможете просто модифицировать ее.
За пределами кампуса вы попадаете в мир территориально-распределенных сетей (WAN), которые характеризуются слишком большим набором параметров, чтобы обсуждать их здесь. Достаточно сказать, что на корпоративные сети WAN большое влияние оказывают экономические аспекты; следовательно, вы постараетесь выбрать наиболее привлекательные по стоимости устройства. В настоящее время большинство корпоративных сетей WAN переходят от арендуемых линий к технологии frame relay - в основном, из соображений экономии. Если операторы связи захотят, чтобы пользователи в массовом порядке перешли на службы АТМ, им придется установить на них соответствующие цены.
У большинства корпоративных клиентов не возникает проблем масштабируемости, как у провайдеров услуг Internet, так что некоторые из новых ориентированных на сети WAN методов коммутации сетевого уровня, видимо, более важны для провайдеров, чем для вас. Интересное явление в корпоративных сетях WAN - виртуальные частные сети. Когда будут разработаны методы защиты, вы увидите, что корпорации все чаще начнут соединять большие участки своих сетей через провайдеров "управляемой Internet".
А пока неразбериха в отрасли достигла рекордного уровня, так что для вас самое главное - не упускать из виду свои требования и конечную цель. Удачи!
Магистраль здания, базирующаяся на Ethernet:
концентраторы в кабельных шкафах заменяются на коммутаторы Ethernet, что обеспечивает соединения на 10 Мбит/с с настольными ПК и нисходящие (downlink) соединения на 100 Мбит/с;
высокоскоростные коммутаторы/маршрутизаторы IP/IPX сетевого уровня обеспечивают централизацию и консолидацию файловых/принтерных серверов;
традиционный маршрутизатор обрабатывает другие протоколы
Магистраль здания, базирующаяся на АТМ/МРОА:
концентраторы в кабельных шкафах заменяются оконечными устройствами, способными работать в режиме МРОА, что обеспечивает соединение настолдьных ПК с Ethernet на 10 Мбит/с и нисходящие (downlink) каналы на АТМ на 155 Мбит/с;
одна из функций маршрутизации - пересылка пакетов - передана оконечным устройствам, а информация о маршрутизации обеспечивается сервером-маршрутизатором;
файловые/принтерные серверы подключаются либо через коммутатор АТМ, либо через оконечные устройства
Правило "80:20" изменилось на обратное
При использовании традиционной модели размещения серверов ЛВС, когда они находились в отдельных рабочих группах, можно было ожидать, что около 80% трафика ЛВС останутся в пределах ее локального сегмента.
По мере того как все больше пользователей принимают стратегию централизованных серверов, облегчающую перемещения сотрудников и обслуживание, они обнаруживают, что трафик ЛВС является локальным лишь приблизительно на 20%. Проблема состоит в том, чтобы понять, как обрабатывать сетевой трафик, большая часть которого остается в пределах здания.