На пути к коммутируемым сетям

Корпоративная сеть, основанная на технологии коммутации (иногда называемая коммутируемым объединением сетей, КОС) является сетью с высокой пропускной способностью и малыми задержками, наделенная атрибутами кадровой и ячеечной коммутации. Ряд особенностей отличают КОС от традиционных объединений локальных сетей. Помимо высокоскоростных интерфейсов и специализированных коммутационных микросхем, обеспечивающих выделенные каналы "точка-точка" между ключевыми магистральными и групповыми устройствами, коммутируемая корпоративная сеть поддерживает сбалансированное агрегирование в корпоративной магистрали трафика от рабочих групп. Средние, высокоскоростные и сверхскоростные интерфейсы (4 Мбит/сек, 10 Мбит/сек, 16 Мбит/сек, 100 Мбит/сек, 155 Мбит/сек) образуют коммуникационную инфраструктуру, способную обеспечить полосу пропускания, требующуюся для всех подключенных устройств, в любой момент времени, из конца в конец, через всю корпорацию.

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

Виртуальные локальные сети (ВЛВС) делают коммутацию гибкой

Одно из важнейших различий между традиционной сетью с разделяемым доступом (см. Рис. 2) и сетью, основанной на технологии коммутации, состоит в том, что логическая иерархия сети с разделяемым доступом подчинена физическим границам, создаваемым при использовании маршрутизаторов для сегментирования сети. Логическую иерархию, определяемую наборами устройств, обычно нельзя изменить без физической реорганизации сетевого оборудования, то есть без перемещения маршрутизаторов или переопределения подсетей. В коммутируемом объединении сетей (КОС) логическая иерархия и физическая инфраструктура полностью разделены за счет дополнения коммутации средствами создания виртуальных локальных сетей (ВЛВС). В то время как реорганизация групп устройств в традиционных сетях с разделяемым доступом означает перемещение маршрутизаторов или изменение адресов подсетей, реорганизация групп пользователей и сетевых ресурсов в коммутируемых сетях практически сводится к изменению конфигурации ВЛВС. Обычно это означает всего лишь небольшое изменение в системе управления сетью.

Технология коммутации выгодна всем

Коммутируемые сети дают определенный выигрыш всем. В рамках старого доброго Ethernet каждый компьютер в сети (и пользовательская рабочая станция, и сервер) получает выделенный канал на 10 Мбит/сек. Каналы к критическим разделяемым ресурсам строятся с использованием Ethernet на 100 Мбит/сек. Эти каналы агрегируют потоки данных от многих настольных систем к серверам рабочих групп — файловым или баз данных.

Коммутируемые сети Token Ring также выглядят обновленными, снимая перегрузки с самых больших кольцевых сетей, но работая при этом с базой установленных сетевых карт (это верно и для коммутируемого Ethernet).

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

Густой соус, а не десерт

В развитой корпоративной сети должны успешно сочетаться многие технологии, старые и новые, в том числе маршрутизаторы, коммутаторы кадров, сети с разделяемым доступом и протоколами Ethernet и Token Ring, мосты, коммутаторы ячеек, ВЛВС, концентраторы, сетевые карты, протоколы и повторители. Результирующая архитектура сети не определяется каким-либо одним элементом. Напротив, она напоминает густой соус, покрывающий многие элементы и объединяющий их в нечто новое, лучшее по сравнению с отдельными составляющими. Различные технологии дополняют друг друга, усиливая прочие строительные блоки сети.

Семь шагов к коммутируемой корпорации

План планирования

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

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

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

Шаг 1: переучет сети — разберитесь, что вы имеете

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

Начните с горизонтальной проводки

Нравится это или нет, главным вопросом является кабельная сеть. Основное правило — не прокладывать сеть дважды, поскольку дороже всего стоит труд по прокладке кабеля. Начните с прокладки на каждом этаже кабелей категории 5 на неэкранированной витой паре. Кабель категории 5 — наиболее гарантированная ставка для всех сетей, кроме самых экзотических. Практически все крупные производители будут поддерживать технологию коммутации для этого кабельного хозяйства, по крайней мере посредством ATM со скоростью 155 Мбит/сек (а, возможно, и выше). Кабели категории 3 на неэкранированной витой паре, возможно, удовлетворят ваши потребности на ближайшее время, но переход на скорости 100 Мбит/сек и выше может оказаться проблематичным.

Далее, проложите к каждому этажу по крайней мере два вертикальных пучка оптоволокна. Оптоволокно обеспечивает защиту сигналов, необходимую для передачи данных на высоких скоростях на относительно большие расстояния в сложном электромагнитном окружении. Вертикальные оптоволоконные связи гарантируют, что при необходимости может использоваться даже сверхскоростная разновидность ATM на 622 Мбит/сек. До наступления столь светлого будущего имеется возможность применять оптоволокно для коммутации кадров, начиная от коммутируемого Ethernet на 10 или 100 Мбит/сек и до коммутируемого Token Ring или традиционного FDDI.

Шаг 2: продумайте протоколы

Рассмотрим взаимодействие между клиентом и сервером, связанное с посылкой четырех пакетов данных. На этом примере наглядно проявляется различие между протоколами, поддерживающими механизм окон на транспортном уровне, и не поддерживающими таковой. Протоколы с поддержкой окон (например, TCP) уменьшают число контактов между клиентом и сервером, что, в свою очередь, уменьшает время ответа.

Имеется по крайней мере одно обязательное простое правило, касающееся протоколов в коммутируемой сети: везде, где это возможно, используйте протоколы, поддерживающие на транспортном уровне механизм окон. Хотя с коммутационной технологией почти все протоколы работают превосходно, поддержка окон значительно повышает эффективность сетевых коммуникаций. Например, TCP-окна дают возможность клиентам и серверам посылать друг другу цепочки пакетов, прежде чем переходить к ожиданию получения пакета с подтверждением (ACK) в ответ на последнюю посылку. Эта черта позволяет коммутаторам эффективно конвейеризовать большое число пакетов между отправителем и получателем, а не входить в режим, когда в каждый момент времени между отправителем и получателем передается только один пакет. Таким образом, протоколы с поддержкой окон экономят время (которое в противном случае расходуется на ожидание подтверждений) и полосу пропускания. На самом деле, передача по сети файла размером порядка 1 Мб при использовании протоколов с поддержкой окон может быть эффективнее на 50%. Это положение иллюстрируется на Рис. 3.

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

• первый пакет данных должен пересечь сеть и промежуточные сетевые устройства;
• пакет принимается и обрабатывается получателем;
• генерируется подтверждение;
• подтверждение пересекает сеть в обратном направлении.

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

Шаг 3: разделите технические и политические границы

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

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

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

На Рис. 4 показана корпоративная сеть, в которой маршрутизатор разделяет три отдела. Маршрутизатор изолирует потоки данных в отделах друг от друга. Например, взаимодействие между компьютерами A и B осуществляется исключительно в пределах сети инженерного отдела (подсеть 1). В некоторый момент инженерному отделу может понадобиться увеличить производительность, снизив трафик в подсети. Быстрое решение состоит в сегментировании инженерной сети с помощью существующего маршрутизатора. Добавляются два порта маршрутизатора (см. Рис. 5), за счет чего создаются три инженерных сегмента: подсети 1, 2 и 3. Хотя каждый из сотрудников инженерного отдела ощущает рост эффективности при взаимодействии с компьютером в пределах одной подсети, эффективность взаимодействия между компьютерами A и B уменьшится, поскольку поток данных будет проходить через маршрутизатор.

Изучение сети на Рис. 5 показывает, что маршрутизатор поддерживает политические границы между инженерным отделом, бухгалтерией и отделом маркетинга. Однако маршрутизатор дополнительно сегментирует инженерный отдел на три подсети в попытке улучшить эффективность работы сети. При миграции к коммутационным технологиям целесообразно воспользоваться схемой, изображенной на Рис. 6, где маршрутизатор продолжает разделять три отдела, а коммутатор служит для связывания устройств в инженерной сети. В данном случае маршрутизатор и коммутатор дополняют друг друга. Каждый из них выполняет работу, для которой он спроектирован. Маршрутизатор устанавливает политические границы, обеспечивая межсетевое экранирование, а коммутатор осуществляет высокоскоростную пересылку кадров между компьютерами или сегментами. Теперь компьютеры A и B могут обмениваться данными без потери эффективности, связанной с прохождением через маршрутизатор. Ресурсы маршрутизатора расходуются исключительно на эффективную пересылку данных между отделами, он освобожден от обслуживания рабочих групп. Совместное применение маршрутизатора и коммутатора позволяет администратору сети полностью избавиться от подсетей, созданных исключительно из соображений эффективности. Тем самым восстанавливается первоначальная ясная, управляемая структура подсетей.

Шаг 4: спланируйте корпоративные топологии; установите иерархию производительности

При проектировании топологии сети могут использоваться две модели: централизованная и распределенная. Технология коммутации полезна в обоих случаях. Хотя каждая из моделей имеет право на существование, их сочетание проблематично. Начните проектирование топологии сети с разработки модели критически важных приложений. Помните, что эта модель со временем будет меняться.

Истинно централизованная

Централизованная топология приложений, при которой несколько ключевых серверов сосредоточено в центре сети, применяется во многих организациях. Тому есть две главные причины:

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

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

Высокоскоростные каналы, предоставляемые в рамках технологии коммутации, обеспечивают новый уровень сетевой производительности, что существенно помогает организациям с централизованными приложениями. Коммутация дает централизации право на жизнь, поскольку высокоскоростная, с малыми задержками пересылка кадров обеспечивает значительно лучшее время отклика, чем в традиционных сетях, построенных на маршрутизаторах. Малые задержки приводят к сглаживанию различий между очень длинными и очень короткими цепочками коммутаторов, располагающихся на пути от клиента к серверу. Более того, мощные каналы, такие как Ethernet на 100 Мбит/сек и ATM на 155 Мбит/сек, делают возможным агрегирование запросов от нескольких клиентов и их параллельную пересылку на большие серверы. В сущности, проектирование коммутируемой сети с централизованными приложениями позволяет игнорировать правило 80-20, согласно которому 80% сетевого трафика должно оставаться в пределах локальной сети.

Истинно распределенная

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

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

При создании кластеров сеть проектируется с учетом правила 80-20. Расчет строится на удачном расположении серверов, применении технологии распределенных СУБД и способности коммутаторов локализовывать сетевой трафик. Главными достоинствами распределенной модели являются высокая эффективность приложений и малое время ответа, а также быстрое, модульное масштабирование приложений посредством создания новых кластеров коммутатор/сервер.

Корпоративная топология и иерархия производительности

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

Централизованные приложения порождают звезды звезд

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

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

Распределенные приложения порождают сеть звезд

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

Шаг 5: спланируйте виртуализацию

Создание виртуальных групп

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

Вероятно, важное значение будут иметь две реализационно-зависимые характеристики:

• способность динамически, в реальном времени, программными средствами перемещать компьютеры в другие ВЛВС;
• способность отслеживать и анализировать объем и характер сетевого трафика с целью выявления компьютеров, которые целесообразно объединить в одну ВЛВС.

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

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

Среди возможных схем определения ВЛВС выделяются группировка по протоколам и по прикладным областям. Группы по протоколам легко определить, и во многих сетях существуют выраженные протокольные границы, отражающие границы организационные — в инженерном отделе используют IP, в бухгалтерии — IPX, в отделе маркетинга — Appletalk. В любом случае создание начальных групп на основе общности используемых протоколов — это отличная стартовая точка для определения ВЛВС. Прикладные области определить несколько сложнее, но в качестве первого шага они были бы еще лучше. В то время как пользователи могут применять несколько протоколов или мигрировать в новое протокольное окружение, набор используемых приложений стабилен в гораздо большей степени. Подумайте, нет ли критерия, быть может уникального для вашей организации, который помог бы в определении виртуальных сетей.

Насколько большой должна быть виртуальная сеть?

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

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

Шаг 6: определите, где бороться за качество

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

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

Шаг 7: куда ставить коммутаторы?

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

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

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

Коммутаторы Ethernet 10 Мбит/сек и Token Ring 16 Мбит/сек хороши для передачи потоков данных на стабильно высоких скоростях. Практически во всех современных сетях при создании сегментов для концентрации трафика используется та или иная разновидность повторителей. Там, где применялись маршрутизаторы или мосты, коммутаторы Ethernet 10 Мбит/сек и Token Ring 16 Мбит/сек могут связать между собой сегменты ЛВС.

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

Поддержка Ethernet 100 Мбит/сек будет встраиваться в коммутаторы кадров, что даст возможность одновременного доступа многих пользователей к одному серверу или корпоративной магистрали по 100 Мбит/сек-каналу. Коммутаторы Ethernet 10/100 Мбит/сек, агрегирующие несколько выделенных каналов 10 Мбит/сек в канал 100 Мбит/сек, ликвидируют узкие места и выстраивают требуемую иерархию производительности. Такие коммутаторы особенно хороши для применения внутри ЛВС при распределенной корпоративной топологии, когда каналы быстрого Ethernet связывают пользователей с одним или несколькими серверами приложений. Хороши они и как основной интерфейс между локальными сетями и магистралью в здании при централизованной корпоративной топологии. В последнем случае быстрый Ethernet используется как канал между рабочей группой и оставшейся частью сети.

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

По сравнению с коммутаторами быстрого Ethernet, переходные адаптеры обладают двумя преимуществами при подключении к ATM-магистрали:

• ПА подключаются к магистрали непосредственно через ATM-интерфейс;
• ПА более тесно вовлечены в процессы подключения, управления потоком данных и принятия решений по маршрутизации, выполняемые коммутаторами ячеек в ATM-магистрали.

В отличие от ПА, коммутатор быстрого Ethernet должен пользоваться услугами либо маршрутизатора, либо ATM-коммутатора с интерфейсами быстрого Ethernet.

ATM-коммутаторы образуют каркас корпоративных сетей. Вероятно, в ближайшем будущем технология ATM будет играть важную роль в обеспечении глобальной связности в больших территориально распределенных корпоративных сетях с высокой пропускной способностью. Кроме того, ATM (на скоростях 155 Мбит/сек или 25 Мбит/сек) может использоваться там, где члены рабочих групп должны запускать приложения с крайне высокими требованиями к пропускной способности или качеству сервиса. Только ATM-коммутация способна обеспечить полосу пропускания, достаточную для агрегирования высокоскоростных потоков данных, поступающих в магистраль от коммутаторов кадров (на 10 или 100 Мбит/сек), связывающих локальные сети и отдельные рабочие станции. По мере того, как коммутация кадров будет получать все более широкое распространение внутри и между ЛВС, для поддержания корпоративной иерархии производительности (локальные сети — магистрали — глобальные сети) будут требоваться ATM-магистрали в пределах зданий.

Традиционные межсетевые маршрутизаторы по-прежнему остаются связующим звеном, цементом, скрепляющим между собой сложные разнородные сети. Маршрутизаторы продолжают объединять Ethernet и Token Ring, Frame Relay и X.25, а также сети, построенные на других технологиях. Очень важно, что маршрутизаторы делают доступными унаследованные сети, подключая ЛВС из самого дальнего угла корпоративной сети к коммутируемой инфраструктуре. И в рамках этой инфраструктуры за маршрутизаторами, вероятно, останется роль контроля политических границ и межсетевого экранирования, в том числе и между виртуальными сетями.

Планировать или не планировать?

Что предпочесть — покупку отдельных решений или разработку стратегии и сетевых проектов, образующих в совокупности архитектуру? Зачастую ответ зависит от того, насколько далеко идущие цели ставятся и как быстро должно быть найдено решение. Следует учитывать, однако, проблемы, которые возникают при бессистемном внедрении новых технологий. Вероятно, наиболее опасная из них состоит в интеграции с унаследованными системами. Другая опасность исходит от эволюционных тупиков. Так или иначе, перед владельцем сети встает выбор — планировать или не планировать.

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

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

Следует ли строить коммутируемую корпоративную сеть?

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

• Число компьютеров в организации растет со скоростью 25% в год. При расширении сети следует рассмотреть возможности технологии коммутации. Коммутация кадров может внедряться на уровне магистралей этажей и зданий, возможно, вместо маршрутизаторов рабочих групп. Существующие мощные клиентские и серверные системы могут подключаться к коммутаторам Ethernet или Token Ring, а каналы к повторителям могут передаваться менее требовательным пользователям.
• В организации пользуются успехом приложения клиент/сервер. Кажется, что очередное приложение решит все проблемы. Хотя среда клиент/сервер позволяет разрабатывать приложения быстрее и дешевле, при эксплуатации требуется по крайней мере на порядок большая пропускная способность по сравнению с приложениями, выполненными в архитектуре терминал/ЭВМ.
• На магистралях в зданиях требуется пропускная способность, превышающая 100 Мбит/сек. Когда перестает справляться FDDI, стоит обратить внимание на коммутируемый быстрый Ethernet или ATM. Подумайте о коммутационных технологиях, прежде чем продолжить сегментирование FDDI-магистрали.
• Некоторым серверам требуется разделяемая полоса пропускания, превышающая 20 Мбит/сек. Когда развитые приложения поднимают планку необходимой пропускной способности, стоит рассмотреть возможность перевода продвинутых рабочих групп на коммутируемые локальные сети. В особых случаях на коммутационные технологии могут переводиться отдельные пользователи, применяющие, например, научную графику, мультимедиа-приложения или приложения, чувствительные к задержкам (пример — электронная биржа). В подобных случаях вместе существующих или планируемых интерфейсов FDDI целесообразно установить интерфейсы ATM.
• Централизация серверов увеличила магистральный трафик. Опыт показывает, что если более одной трети трафика клиент/сервер выходит за пределы рабочей группы, пропускная способность канала от рабочей группы до магистрали должна быть удвоена.