Кольцо и звезда: кто кого?

При построении сетей есть две конкурирующие топологии: это звезда (разных вариантов) и кольцо (разных вариантов). У звезды одно преимущество – низкая переподписка. Недостатки звезды — сложная структура, а соответственно сложность эксплуатации и высокая стоимость. Звезда — это решение для собранных в одно место пользователей на доступе: классическая сеть здания управления в предприятии, но не всегда и даже в этом случае. Ведь опорная сеть здания с соблюдением норм пожарной безопасности всегда будет прокладываться через два кабельных стояка в разных частях здания и это снова – кольцо, а не звезда: одно кольцо/жгут оптики через эти два стояка и два центра ядра сети здания/ЦОД.

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

Рис. 1. Модуль АСУТП завода.

Работать по топологии звезды могут все производители сетевого оборудования, а работать по топологии кольца на коммутаторах с распределением виртуальных сетей по всему кампусу без использования сложных и дорогостоящих технологий типа MPLS/VPLS могут только ограниченное число производителей – HP, Huawei, Extreme.

К примеру, возьмем парочку типовых простых «кольцевых» объектов: стадион и аэропорт.

Рис. 2. Сеть стадиона.

Для данных объектов кольцевая топология имеет следующие преимущества, по сравнению со звездой:

1. Инсталлировать и поддерживать топологию кольца гораздо проще. Инсталлировать и поддерживать топологию кольца гораздо проще, так как устройства доступа через кольцо сразу попадают или в серверную ферму или в ядро, а звезда еще предполагает промежуточный уровень — агрегация каналов с уровня доступа. Причина уровня агрегации у звезды проста: на уровне агрегации цена за порт гораздо ниже, чем на уровне ядра у звезды,, а также для более гибкого применения различных политик.
2. Для современных сетей резервирование каналов связи от уровня доступа в уровень аггрегации и/или ядра что является критическим. Если в звезде делать резервирование кабельных трасс по разным путям, тогда физически получиться кольцо, а логически — звезда. Но при этом для каждого коммутатора на доступе придется тащить в места коммутации отдельные кабельные трассы, так как оптика всегда разрезается и сваривается всем жгутом, а не по отдельным жилам. Каждая сварка оптики на пути движения света в волокне увеличивает потери бюджета оптики, и как следствие, сокращает расстояние работы оптических каналов связи. Также надо учитывать, что и работ по сварке оптики будет в несколько раз больше при топологии звезды, чем при топологии кольцо.
3. Для стадионов, аэропортов и для сетей предприятий всегда есть как минимум две отдельных физически разделенных сети. Для кольца – это просто, для звезды у распределенных объектов – реальность печальна.
4. Сходимость звезды будет всегда хуже, так как всегда будут петли логических путей между коммутаторами доступа, кроме случая когда в ядре два слотовых коммутатора работают как один. Сходимость топологии кольца от 50 ms (одно кольцо) до 200 ms (к основному кольцу подключаются подкольца).
5. У звезды сложности с масштабированием: добавление кабельных трасс в любом месте — это протяжка нового дополнительного кабеля, для кольца — добавочная муфта в существующем оптическом жгуте.
6. В случае кольца мы выводим с доступа в ядро всегда нужную и планируемую скорость uplink каналами из коммутаторов, которые наиболее нагружены: то есть платим по мере необходимости за рост полосы. А в случае звезды – мы платим сразу за все и реально не используем полосу пропукания подключенных uplink каналов.

Последний пункт хотелось бы рассмотреть более подробно. Нужно отметить, что узким местом всегда будет подключение серверов: так как если мы подключим 28 (это более чем достаточно даже для самых крупных в мире стадионов) гигабитных коммутаторов по топологии звезды, тогда у нас перегрузка при подключении доступа к ядру будет 2*2*20Гб(скорость подключения серверного модуля кольцам)/28*20ГБ (28 коммутаторов доступа по два 10 Гб/c uplink)=1:7. В случае стека — это будет 40ГБ (два серверных стека)/4*20Гб (четыре стека доступа)= 1:2. Но переподписка на доступе у звезды будет 20Гб (два аплинка по 10Гб)/ 48*1ГБ( порты доступа)= 5:12 = 1:2.4, а у стека 20Гб(ширина стека)/7 *48*1Гб (семь коммутаторов доступа в одном стеке) = 5:7*12 = 5:84 = 1:17. Для стандартной сети на доступе перегрузка допускается 1:20. Как мы видим, в случае звезды низкая перегрузка на доступе вызывает «захлебывание» для серверов. Для решения данных проблем в ядре сети для топологии звезды нужно ставить дорогостоящие модули (но вопрос – для чего их добавлять, если уже и так достаточно серверных портов?), если же нужно на доступе в стеке уменьшить перегрузку – нужно просто добавить оптические конверторы. Ниже привожу таблицу сравнения.

Но тут в борьбу кольца и звезды вмешался прогресс: появились 40 ГБ и 100 Гб интерфейсы. Для 95% клиентов – это просто недостижимые в ближайшем будущем полосы uplink каналов связи для подключения доступа к ядру. И как результат, по тем же жилам, ничего не добавляя, а просто заменяя 10 Гб трансивер на 40ГБ или 100ГБ, мы повышаем в несколько раз пропускную способность кольца, и тут уже потенциальная проблема переподписки кольца не появляется в принципе. Хотя, опять же, цена 40 Гб и 100 Гб трансиверов на 10 км сейчас очень высока, но через год – это уже будет цена текущих 10Гб трансиверов.

Самые крупные примеры использования кольцевых технологий совместно с технологией стекирования в Азии – это город Пекин, в Европе — французские железные дороги. Но у железных дорог Франции просто не было выбора после того как TR «умер». И это проекты реализованные на оборудовании компании HP (бывшего оборудования 3Com), что дает повод для размышлений и применения на практике описанного кольцевого дизайна для проектировщиков сетей передачи данных.

Автор: Tigger

Источник