Tor коммутатор что это
Обновлено: 06.07.2024
Пусть наш Сервис-Провайдер LAN_DC будет, например, хостить обучающие видео о выживании в застрявших лифтах.
В мегаполисах это пользуется бешенной популярностью, поэтому физических машин надо много.
Сначала я опишу сеть приблизительно такой, какой бы её хотелось видеть. А потом упрощу для лабы.
Локации
У LAN_DC будет 6 ДЦ:
Внутри ДЦ (Intra-DC)
Во всех ДЦ идентичные сети внутренней связности, основанные на топологии Клоза.
Что за сети Клоза и почему именно они — в отдельной статье.
В каждом ДЦ по 10 стоек с машинами, они будут нумероваться как A, B, C итд.
В каждой стойке по 30 машин. Они нас интересовать не будут.
Также в каждой стойке стоит коммутатор, к которому подключены все машины — это Top of the Rack switch — ToR или иначе в терминах фабрики Клоза будем называть его Leaf.
Общая схема фабрики.
Именовать их будем XXX-leafY, где XXX — трёхбуквенное сокращение ДЦ, а Y — порядковый номер. Например, kzn-leaf11.
А вообще такая топология называется фабрикой, потому что fabric в переводе — это ткань. И сложно не согласиться:
Фабрика полностью L3. Никаких VLAN, никаких Broadcast — вот такие у нас в LAN_DC замечательные программисты, умеют писать приложения, живущие в парадигме L3, а виртуальные машины не требуют Live Migration c сохранением IP-адреса. И ещё раз: ответ на вопрос почему фабрика и почему L3 — в отдельной статье.
DCI — Data Center Interconnect (Inter-DC)
DCI будет организован с помощью Edge-Leaf, то есть они — наша точка выхода в магистраль.
Для простоты предположим, что ДЦ связаны между собой прямыми линками.
Исключим из рассмотрения внешнюю связность.
Я отдаю себе отчёт в том, что каждый раз, как я убираю какой-либо компонент, я значительно упрощаю сеть. И при автоматизации нашей абстрактной сети всё будет хорошо, а на реальной возникнут костыли.
Это так. И всё же задача этой серии — подумать и поработать над подходами, а не героически решать выдуманные проблемы.
Положа руку на сердце, на нашей фабрике, которая с большой долей вероятности не будет стремительно расти, за глаза хватило бы и OSPF. Это на самом деле проблемы мегаскейлеров и клауд-титанов. Но пофантазируем всего лишь на несколько выпусков, что нам это нужно, и будем использовать BGP, как завещал Пётр Лапухов.
Политики маршрутизации
BGP ASN
Edge-Leaf ASN
Spine ASN
На Spine у нас будет один ASN на ДЦ. Начнём здесь с самого первого номера из диапазона приватных AS — 64512, 64513 итд.
Почему ASN на ДЦ?
Декомпозируем этот вопрос на два:
- Почему одинаковые ASN на всех спайнах одного ДЦ?
- Почему разные в разных ДЦ?
Почему одинаковые ASN на всех спайнах одного ДЦ
Вот как будет выглядеть AS-Path Андерлейного маршрута на Edge-Leaf:
И здесь нигде не должно быть повторяющихся ASN.
То есть Spine_DC1 и Spine_DC2 должны быть разными, ровно как и leafX_DC1 и leafY_DC2, к чему мы как раз и подходим.
Как вы, наверно, знаете, существуют хаки, позволяющие принимать маршруты с повторяющимися ASN вопреки механизму предотвращения петель (allowas-in на Cisco). И у этого есть даже вполне законные применения. Но это потенциальная брешь в устойчивости сети. И я лично в неё пару раз проваливался.
И если у нас есть возможность не использовать опасные вещи, мы ей воспользуемся.
Leaf ASN
где leafX_ASN и leafY_ASN хорошо бы, чтобы отличались.
Требуется это и для ситуации с анонсом лупбэка VNF между ДЦ:
Вот такая картина с ASN.
Принципиально, нам нужно выделить адреса для следующих подключений:
- Адреса сети Underlay между ToR и машиной. Они должны быть уникальны в пределах всей сети, чтобы любая машина могла связаться с любой другой. Отлично подходит 10/8. На каждую стойку по /26 с запасом. Будем выделять по /19 на ДЦ и /17 на регион.
- Линковые адреса между Leaf/Tor и Spine. Их хотелось бы назначать алгоритмически, то есть вычислять из имён устройств, которые нужно подключить. Пусть это будет… 169.254.0.0/16. А именно 169.254.00X.Y/31, где X — номер Spine, Y — P2P-сеть /31. Это позволит запускать до 128 стоек, и до 10 Spine в ДЦ. Линковые адреса могут (и будут) повторяться из ДЦ в ДЦ.
- Cтык Spine — Edge-Leaf организуем на подсетях 169.254.10X.Y/31, где точно так же X — номер Spine, Y — P2P-сеть /31.
- Линковые адреса из Edge-Leaf в MPLS-магистраль. Здесь ситуация несколько иная — место соединения всех кусков в один пирог, поэтому переиспользовать те же самые адреса не получится — нужно выбирать следующую свободную подсеть. Поэтому за основу возьмём 192.168.0.0/16 и будем из неё выгребать свободные.
- Адреса Loopback. Отдадим под них весь диапазон 172.16.0.0/12.
- Leaf — по /25 на ДЦ — те же 128 стоек. Выделим по /23 на регион.
- Spine — по /28 на ДЦ — до 16 Spine. Выделим по /26 на регион.
- Edge-Leaf — по /29 на ДЦ — до 8 коробок. Выделим по /27 на регион.
| Префикс | Роль устройства | Регион | ДЦ |
| 172.16.0.0/23 | edge | ||
| 172.16.0.0/27 | ru | ||
| 172.16.0.0/29 | msk | ||
| 172.16.0.8/29 | kzn | ||
| 172.16.0.32/27 | sp | ||
| 172.16.0.32/29 | bcn | ||
| 172.16.0.40/29 | mlg | ||
| 172.16.0.64/27 | cn | ||
| 172.16.0.64/29 | sha | ||
| 172.16.0.72/29 | sia | ||
| 172.16.2.0/23 | spine | ||
| 172.16.2.0/26 | ru | ||
| 172.16.2.0/28 | msk | ||
| 172.16.2.16/28 | kzn | ||
| 172.16.2.64/26 | sp | ||
| 172.16.2.64/28 | bcn | ||
| 172.16.2.80/28 | mlg | ||
| 172.16.2.128/26 | cn | ||
| 172.16.2.128/28 | sha | ||
| 172.16.2.144/28 | sia | ||
| 172.16.8.0/21 | leaf | ||
| 172.16.8.0/23 | ru | ||
| 172.16.8.0/25 | msk | ||
| 172.16.8.128/25 | kzn | ||
| 172.16.10.0/23 | sp | ||
| 172.16.10.0/25 | bcn | ||
| 172.16.10.128/25 | mlg | ||
| 172.16.12.0/23 | cn | ||
| 172.16.12.0/25 | sha | ||
| 172.16.12.128/25 | sia |
| Префикс | Регион | ДЦ |
| 10.0.0.0/17 | ru | |
| 10.0.0.0/19 | msk | |
| 10.0.32.0/19 | kzn | |
| 10.0.128.0/17 | sp | |
| 10.0.128.0/19 | bcn | |
| 10.0.160.0/19 | mlg | |
| 10.1.0.0/17 | cn | |
| 10.1.0.0/19 | sha | |
| 10.1.32.0/19 | sia |
Два вендора. Одна сеть. АДСМ.
Juniper + Arista. Ubuntu. Старая добрая Ева.
Количество ресурсов на нашей виртуалочке в Миране всё же ограничено, поэтому для практики мы будем использовать вот такую упрощённую до предела сеть.
Два датацентра: Казань и Барселона.
Полная конфигурация всех сетевых устройств, которую мы будем пробовать воспроизвести с помощью автоматики.
Так же принято? Под каждой статьёй делать короткий вывод?
Итак мы выбрали трёхуровневую сеть Клоза внутри ДЦ, поскольку ожидаем много East-West трафика и хотим ECMP.
Разделили сеть на физическую (андерлей) и виртуальную (оверлей). При этом оверлей начинается с хоста — тем самым упростили требования к андерлею.
Выбрали BGP в качестве протокола маршрутизации анедрелейных сетей за его масштабируемость и гибкость политик.
У нас будут отдельные узлы для организации DCI — Edge-leaf.
На магистрали будет OSPF+LDP.
DCI будет реализован на основе MPLS L3VPN.
Для P2P-линков IP-адреса мы будем вычислять алгоритмически на основе имён устройств.
Лупбэки будем назначать по роли устройств и их расположению последовательно.
Андерлейные префиксы — только на Leaf-коммутаторы последовательно на основе их расположения.
Предположим, что прямо сейчас у нас ещё не установлено оборудование.
Поэтому наши следующие шаги будут — завести их в системах (IPAM, инвентарная), организовать доступ, сгенерировать конфигурацию и задеплоить её.
В следующей статье разберёмся с Netbox — системой инвентаризации и управления IP-пространством в ДЦ.
- Андрею Глазкову aka @glazgoo за вычитку и правки
- Александру Клименко aka @v00lk за вычитку и правки
- Артёму Чернобаю за КДПВ
Оставайтесь на связи
Особо благодарных просим задержаться и пройти на Патреон.
Эволюция ЦОД заставляет внимательнее анализировать различные конфигурации кабельной инфраструктуры ЦОД. Универсальной конфигурации, подходящей для всех ЦОД, не существует. Поэтому специалистам по проектированию центров обработки данных необходимо взвесить все «за» и «против», проанализировав каждое решение с учетом конкретных требований, в том числе финансовых.
Эволюция ЦОД заставляет внимательнее анализировать различные конфигурации кабельной инфраструктуры ЦОД. С уверенностью можно сказать, что универсальной конфигурации, подходящей для всех ЦОД, не существует. Поэтому ИТ-директорам и специалистам по проектированию центров обработки данных необходимо взвесить все «за» и «против», проанализировав каждое решение с учетом конкретных требований, в том числе финансовых.
Требования к ИТ в центрах обработки данных постоянно растут. Для новых приложений нужны большая пропускная способность, улучшенные кабельные системы и сетевые устройства с высокими характеристиками. Из-за постоянного роста объемов обрабатываемых данных приходится покупать дополнительные серверы и коммутаторы и каким-то образом втискивать их в имеющийся ЦОД, что еще больше повышает плотность оборудования.
В результате первостепенное значение приобретают вопросы электропитания и охлаждения, поскольку соответствующие затраты существенно возрастают. Если принять во внимание все эти изменения, становится ясно, что расходы на современные ЦОД могут легко выйти из-под контроля. Сегодня самой сложной задачей, стоящей перед ИТ-менеджерами, является поддержание экономической жизнеспособности центров обработки данных.
При сравнении конфигурации кабельной системы с коммутатором вверху стойки (Top of Rack, ToR) и СКС приходится принимать во внимание множество аспектов, в том числе влияние кабельных конфигураций на управление в целом, возможности их масштабирования и изменения. Вместе с тем, поскольку управление затратами становится все более важным, не нужно забывать об экономической эффективности. Каковы финансовые последствия выбора конфигурации ToR и отказа от структурированных кабельных систем?
В данной статье рассматривается выбор конфигурации кабельной системы с точки зрения затрат, при этом особое внимание уделяется расходам на построение и обслуживание кабельной системы, эффективному использованию портов, энергопотреблению и охлаждению.
КРАТКИЙ АНАЛИЗ ТОПОЛОГИЙ TOR И СКС
Прежде чем браться за финансовые вопросы, нужно понимать, каковы элементарные отличия топологий ToR и СКС, реализованных в ЦОД.
В структурированной кабельной системе предусматриваются зоны распределения и коммутации, обеспечивающие гибкие, основанные на стандартах соединения между коммутаторами и серверами, коммутаторами и системами хранения данных, а также самими коммутаторами. Коммутационные панели, порты которых зеркалируют порты коммутаторов и серверов, подключаются к соответствующим панелям в одной (или более) центральной распределительной/коммутационной зоне посредством постоянных (фиксированных) линий (Permanent Link). Эти зоны могут находиться в конце или в середине ряда стоек, формируя конфигурацию «любой ко всем», когда любой порт коммутатора можно соединить с любым портом оборудования.
В конфигурации ToR в верхней части каждой стойки или серверного шкафа устанавливаются небольшие (1RU или 2RU) пограничные коммутаторы, подключаемые прямо к установленным в стойке серверам с помощью коротких биаксиальных претерминированных кабельных сборок малого форм-фактора (например, SFP+ и QSFP), активных оптических кабельных сборок или модульных коммутационных шнуров RJ-45. Эти так называемые соединения точка – точка позволяют обойтись без организации центральной зоны коммутации.
Кабельная система, отвечающая стандарту TIA 942, и конфигурация ToR имеют каждая свои преимущества и недостатки. Например, в конфигурации ToR значительно увеличивается количество коммутаторов, но при этом сокращаются начальные потребности в структурированной кабельной инфраструктуре. Такой сценарий имеет свои «за» и «против», но управление перемещениями, добавлениями и изменениями (MAC) в конфигурации ToR может оказаться сложнее и занимать больше времени. При этом изменения ограничиваются отдельными стойками или шкафами, а не осуществляются в одной удобной коммутационной зоне, где просто меняется положение коммутационных шнуров или оптических перемычек.
ЦЕНА ВЫБОРА
_300.jpg) |
| Рисунок 1. При выборе конфигурации кабельной системы в ЦОД приходится учитывать многочисленные факторы. Ни одно решение нельзя считать универсальным. |
При выборе между структурированной кабельной системой и ToR нужно учитывать и финансовые вопросы. Какие именно?
Ценовой фактор 1. Выбор в пользу кабельной системы и его влияние на стоимость оборудования, кабельной системы и обслуживания. В конфигурации ToR, предусматривающей наличие коммутатора в каждой стойке (или двух в случае резервирования — для основной и вспомогательной сетей), общее число портов коммутаторов зависит от числа шкафов в ЦОД, а не от фактического числа портов, необходимых для поддержания работы оборудования. В результате по сравнению со структурированной кабельной системой число коммутаторов и модулей питания почти удваивается. В отличие от пассивной СКС коммутаторам ToR требуется электропитание и текущее обслуживание. Например, в случае ЦОД на 39 стоек с двумя раздельными сетями стоимость оборудования и обслуживания для конфигурации ToR более чем вдвое превышает аналогичные показатели для структурированной кабельной системы.
Использование в СКС распределительных зон влияет и на стоимость кабельной инфраструктуры. Конфигурация ToR позволяет сэкономить на структурированной кабельной системе, но применяемые в ней короткие биаксиальные кабельные сборки форм-фактора SFF обычно дороже медножильных коммутационных шнуров в СКС. Затраты на эти кабельные сборки в ToR могут негативно сказаться на любой экономии, особенно когда вендоры требуют использовать кабельные сборки их собственной разработки. Фактически стоимость кабельных сборок в ToR в расчете на порт более чем вдвое превосходит аналогичные затраты при построении СКС. Даже если не учитывать стоимость кабельных сборок, затраты на структурированную кабельную систему представляют лишь около 5% общей экономии на оборудовании и обслуживании при выборе СКС вместо ToR. Кроме того, на СКС обычно дается гарантия на 15–25 лет (в зависимости от производителя), тогда как гарантия на кабельные сборки, предлагаемые большинством вендоров, не превышает 90 дней.
Конфигурация ToR может привести к увеличению стоимости серверов: те, что оснащены сетевыми картами (NIC) с интерфейсом «витая пара», дешевле, чем устройства с сетевыми интерфейсами SFP+ или QSFP. Во многих серверах медный интерфейс под кабели «витая пара» встроен в системную плату. При развертывании конфигурации ToR с биаксиальными кабельными сборками SFF могут понадобиться сетевые карты с SFP+ или QSFP, которые стоят от 400 до 800 долларов.
Ценовой фактор 2. Максимальная доступность портов и эффективность их использования. Исследования DataCenter Dynamics и Gartner Group показывают, что в настоящее время один серверный шкаф потребляет примерно 5–6 кВт электроэнергии. В него помещается около 14 серверов. Таким образом, потребность в портах коммутаторов обычно оказывается меньше, чем их реально имеется в коммутаторе ToR. Например, если в 32-портовом коммутаторе занято 14 портов, то 18 портов остаются невостребованными. При использовании двух раздельных сетей при резервировании, когда каждый из 14 серверов подключен к двум 32-портовым коммутаторам, будут задействованы 28 из 64 портов, а незанятыми окажутся 36 портов.
В случае СКС можно использовать практически все активные порты, поскольку нет привязки к отдельным шкафам. 32 порта коммутатора, которые в конфигурации ToR располагались бы в одном шкафу, могут быть разделены по требованию между несколькими шкафами посредством распределительной области. Даже при использовании пограничных коммутаторов для передачи трафика восток – запад (то есть между серверами), структурированная кабельная система позволяет разместить такие коммутаторы централизованно в распределительной зоне. Это приводит к уменьшению числа незадействованных портов и сокращению объема трафика север – юг и, соответственно, снижению загрузки коммутаторов уровня агрегирования и ядра сети.
Возможность эффективно распоряжаться невостребованными портами — ключевой вопрос при выборе конфигурации ToR. Нужно отметить также, что в некоторых ЦОД применяется архитектура коммутационной фабрики. В этом случае число незадействованных портов, количество кабелей и единиц оборудования будет иным, чем при использовании трехуровневой коммутационной инфраструктуры. Однако преимущества структурированной кабельной системы сохраняются.
Ценовой фактор 3. Влияние числа неиспользуемых портов и единиц оборудования на энергопотребление. Уровень энергопотребления — один из главных факторов эффективности ЦОД, ведь цены на электроэнергию продолжают расти, мощности обходятся все дороже и все большее внимание уделяется сохранению окружающей среды. Благодаря тому что в СКС можно задействовать все порты имеющихся коммутаторов и, таким образом, сократить их количество, потребляемая мощность уменьшается наполовину (см. Таблицу 1). Это помогает снизить затраты на оборудование и электроэнергию, способствует успешной реализации таких «зеленых» инициатив, как LEED, BREEAM или STEP. Поскольку при использовании структурированной кабельной системы требуется меньше источников питания, последующие модернизация и переход на более энергоэффективные модули питания становятся более легкими и менее затратными.
_500.jpg) |
| Таблица 1. В случае структурированной кабельной системы требуемое число коммутаторов и модулей питания составляет менее половины от необходимого для конфигурации ToR, что обеспечивает снижение энергопотребления. |
Если в конфигурации ToR все порты коммутаторов оказываются заняты, то добавление в шкаф нового сервера потребует размещения в нем дополнительного коммутатора и модулей питания. В результате меньше мощности можно будет выделить самим серверам, а доступной емкости может и вовсе не хватить для вновь установленных устройств. Даже учитывая, что благодаря виртуализации сокращается число физических серверов и, соответственно, снижается потребность в электроэнергии (в том числе направляемой на охлаждение оборудования), увеличение количества блоков питания в конфигурации ToR потенциально может свести на нет часть достигнутой экономии. Важно помнить, что даже в состоянии простоя неиспользуемые порты коммутаторов потребляют электроэнергию. Независимо от конфигурации и развернутых технологий, потребляемая мощность зависит от модели и производителя, и фактическое энергопотребление портов нужно анализировать в масштабе всего ЦОД.
Ценовой фактор 4. Размещение оборудования, его влияние на охлаждение в ЦОД и показатели бесперебойной работы. Хотя технически коммутатор ToR может находиться в середине или даже в нижней части стойки, для более простого доступа и управления такие коммутаторы обычно размещают сверху. Между тем, по данным Uptime Institute, уровень отказов оборудования в верхней трети стойки втрое выше, чем в нижней ее части. В конфигурации с СКС вверху обычно размещаются пассивные компоненты (например, коммутационные панели), а самые «холодные» места остаются для оборудования.
Из-за коротких кабелей и запрета на организацию соединений между шкафами посредством коммутационных шнуров конфигурация ToR предоставляет меньше свободы и в размещении оборудования. В результате может оказаться невозможно установить его там, где это будет наиболее оптимально с точки зрения питания и охлаждения. Например, если бюджет не позволяет оснастить шкаф еще одним коммутатором ToR, то выбор места для нового модульного сервера может быть ограничен доступными сетевыми портами — придется установить его там, где такие порты есть. Это может вести к образованию зон перегрева и отрицательно повлиять на рядом расположенное оборудование в той же зоне охлаждения. В случае СКС таких проблем нет.
ЗАКЛЮЧЕНИЕ
Выбор конфигурации кабельной инфраструктуры в ЦОД зависит от множества факторов, и универсального решения нет. Конфигурации ToR подходят для небольших серверных комнат, где весь набор оборудования устанавливается в шкафу или общее число неиспользуемых портов невелико.
При выборе конфигурации кабельной инфраструктуры инженерное и сетевое подразделение должны провести совместное исследование. Кроме вышеизложенных аспектов, в процессе принятия решения должны учитываться такие факторы, как общее управление, масштабируемость, возможность модернизации и совместимость.
Конфигурацию ToR часто рассматривают в качестве замены структурированной кабельной системы, но во многих случаях СКС должна сосуществовать с ToR для поддержки переключателей KVM или других средств управления и мониторинга, использующих общую или отдельную сеть.
Кэрри Хигби — директор по решениям и сервисам для ЦОД, руководитель группы экспертов по сетевым технологиям в компании Siemon.
Представление о том, каким сетевым оборудованием должен быть оснащен ЦОД, зависит от многих факторов: начиная с того, в какой отрасли и на каком уровне он решает задачи, и заканчивая тем, какие приложения в нем запущены. Что готов предложить рынок? «ИКС» спросил об этом поставщиков оборудования и системных интеграторов.
Поскольку для высокопроизводительной коммутации серверов и систем хранения сегодня используется большой спектр технологий и устройств (коммутаторы Ethernet, Fibre Channel, Infiniband, Myrinet и др.), мы решили сначала ограничиться рассмотрением узкого круга задач – организации коммуникации на уровне доступа сети ЦОДа с использованием технологии Ethernet, но при этом были вынуждены подняться несколько выше, рассмотрев архитектуру сети ЦОДа в целом.
Надо отметить, что присутствие в обзоре производителей, известных своими продуктами для рынков небольших локальных и операторских сетей доступа, может вызвать вопросы. Но в связи с тем, что классификация того или иного оборудования как предназначенного специально для ЦОДа и является предметом обсуждения данной статьи, мы считаем, что, ознакомившись с ней, читатель сам сможет сделать вывод, какая модель Ethernet-коммутатора годится для его конкретного проекта ЦОДа, а какая нет.
Сеть ЦОДа: классическая архитектура и ее воплощения
Коммуникационная среда ЦОДа в силу повышенных требований к ее надежности и безопасности часто создается как отдельная сеть. Исторически масштабирование Ethernet-сетей производилось благодаря многоуровневой иерархической структуре. В классической современной архитектуре корпоративной ЛВС выделяют три уровня: доступа, агрегирования и ядра сети. Аналогичным образом строится и сеть ЦОДа (см., например, рисунок), т.е. в общем случае в ней также можно выделить уровень доступа (access tier, или у некоторых производителей – edge tier), просто в качестве терминальных узлов здесь выступают не настольные ПК или иные абонентские устройства, а серверы. В такой сети своя специфика имеется и у уровня агрегирования (иногда еще называемого distribution), и у уровня ядра. Скажем, на уровне агрегирования часто помимо средств безопасности и мониторинга располагаются еще и средства балансировки нагрузки.
Некоторые из опрошенных нами поставщиков считают, что для сети ЦОДа трехуровневая архитектура слишком сложна и избыточна. Это объяснимо, поскольку в России, которая находится на начальном этапе «цодостроительства», под ЦОДом часто подразумевают серверную комнату с парой стоек оборудования, и в таком случае действительно можно обойтись если не единственным модульным коммутатором, то уж точно сетью с двухуровневой архитектурой.
Другое дело, когда заходит речь о сетевых решениях, обеспечивающих работу сотен стоек с тысячами серверов: там дополнительный уровень, распределяющий серверный трафик и поддерживающий сетевые сервисы, просто необходим.
От ядра – к серверам
Уровень ядра сети ЦОДа обеспечивает коммутацию трафика от уровня агрегирования и связь ЦОДа с остальной корпоративной сетью. С организационной точки зрения именно за уровнем ядра сети ЦОДа в крупных организациях заканчивается зона ответственности структурного подразделения эксплуатации ЦОДа. Уровень агрегирования, комплектуемый обычно коммутаторами с большим числом портов 10 Gigabit Ethernet (10GE), в крупных сетях служит демпфером между ядром и уровнем доступа; коммутаторы в нем, как правило, устанавливаются парами, так, что коммутаторы уровня доступа подключаются сразу к двум коммутаторам уровня агрегирования.
Как уже отмечалось, в сети ЦОДа в качестве терминальных узлов уровня доступа выступают серверы. Современные серверы имеют как минимум два интерфейса Gigabit Ethernet. Кроме того, они могут оснащаться портами для связи с системой хранения данных (а часто еще и дополнительными интерфейсами для обеспечения доступа к системе резервного копирования) и портом управления по дополнительному каналу (out-of-band). Такое количество интерфейсов существенно усложняет коммутационную инфраструктуру нижнего уровня сети ЦОДа. Задача поставщиков активного сетевого оборудования – упростить ее, предоставив как можно более унифицированную коммуникационную среду.
На уровне доступа используются два метода размещения коммутаторов, в соответствии с которыми поставщики иногда классифицируют свои продукты. Это подключение серверов одного ряда стоек к од-ному коммутатору с большим числом гигабитных интерфейсов, устанавливаемому в конце этого ряда (End-of-row – EoR), и подключение серверов в каждой стойке к стоечному коммутатору высотой 1U–2U, устанавливаемому вверху стойки (Top-of-rack –ToR). Отдельная тема для разговора – обеспечение коммуникационной среды для блейд-серверов.
Компоновка стоек: ToR против EoR
Для размещения коммутаторов по принципу EoR, как правило, применяются модульные коммутаторы. Преимущества такой компоновки – в высокой пропускной способности, определяемой неблокируемой коммутируемой емкостью модульного коммутатора, и в необходимости управлять лишь одним устройством. Однако у этого варианта есть и недостатки – многочисленные длинные кабельные соединения, из-за которых увеличивается сложность и снижается надежность кабельной системы. К тому же большой объем кабелей в канале под фальшполом препятствует нормальному охлаждению стоек с оборудованием.
ToR-компоновка: «виртуальное шасси», или Общая шина на уровне доступа
Ряд поставщиков предлагает решения, которые совмещают преимущества EoR- и ToR-компоновок путем объединения коммутаторов, монтируемых вверху стойки, в некий виртуальный модульный коммутатор с помощью мощной стекирующей шины. С точки зрения системы управления такой стек действительно представляется единым коммутатором, что упрощает администрирование множества отдельных устройств.
Например, у компании Juniper такое решение получило название «виртуальное шасси» (Virtual Chassis, VC). Оно работает только на коммутаторах серии EX4200. Несколько этих коммутаторов (до 10) объединяются стекирующей шиной с кольцевой топологией через два 64-гигабитных VC-порта с результирующей пропускной способностью 128 Гбит/с (допускается также подключение коммутаторов в VC-стек с помощью агрегируемых Ethernet-каналов с пропускной способностью до 40 Гбит/с). Управление виртуальным шасси производится с резервированием по принципу выделения master/backup-коммутаторов.
Метод стекирования для консолидации коммутаторов на уровне доступа при помощи специальной мощной шины используют и другие производители, например компания Nortel в технологии Switch Cluster, позволяющей объединять в кольцо до 8 устройств ERS5600 60-гигабитной шиной (максимальная пропускная в способность в кольце – 120 Гбит/с).
Несмотря на то что у Cisco есть своя технология StackWise для стекирования стоечных коммутаторов, сегодня в нише ToR-размещения компания делает ставку на коммутаторы серии Nexus с технологией так называемых выносных модулей (fabric extenders) с применением топологии «звезда». Идея этого подхода заключается в том, что виртуальный модульный коммутатор образуется за счет подключения к центральному коммутатору (также резервируемому) Nexus 5000 нескольких выносных модулей Nexus 2000, фактически Ethernet-коммутаторов высотой 1U, по обычному или агрегированному соединению из четырех 10GE-каналов. По данным компании, такой «почти неблокируемый виртуальный коммутатор» с 12 выносными модулями может иметь до 576 интерфейсов Gigabit Ethernet.
Справедливости ради надо сказать, что и остальные компании, представившие свои стоечные коммутаторы для компоновки ToR, позволяют строить из них стеки (преимущественно с помощью 10GE-каналов, часто агрегируемых). Но при этом неблокируемая коммутируемая емкость таких стеков значительно ниже, чем у перечисленных выше виртуальных модульных коммутаторов.
В самом деле для ЦОДа?
Опираясь на опрос поставщиков, мы можем выделить несколько общих требований, которым должно отвечать Ethernet-оборудование для ЦОДов:
Повышенная надежность и отказоустойчивость. Надежность коммутирующих устройств в ЦОДе обеспечивается высоким качеством разработки схемотехнических решений и резервированием всех основных модулей: управления, коммутационных матриц, питания и вентиляции. Это правило справедливо даже для младших моделей коммутаторов (см. табл. 1), используемых на уровне доступа, в большинстве которых дублируются модули питания и вентиляторные блоки.
Высокая производительность и плотность портов. Коммутаторы на уровне доступа должны иметь как минимум гигабитные интерфейсы для связи с серверами и 10GE-интерфейсы для uplink-соединений. В силу упомянутого выше большого числа интерфейсов в современных серверах к коммутаторам для ЦОДов предъявляются требования высокой плотности портов. Но физический максимум конструктивной плотности портов фактически уже достигнут – это порядка 48–52 портов на стандартное стоечное устройство высотой 1U (см. фотографии). Поэтому, говоря о плотности, производители часто подразумевают некую удельную пропускную способность на один порт, а она тем выше, чем больше у коммутатора 10GE-интерфейсов. Сегодня компоновку с большим числом таких портов обеспечивают в основном модульные коммутаторы, но некоторые производители предоставляют уже и 1U–2U- стоечные модели 10-гигабитных коммутаторов, например, Cisco – коммутатор Nexus 5000 (до 52 10GE-портов), Juniper – 1U-коммутатор EX2500 (24 10GE-порта), HP – 1U-коммутатор ProCurve 6600-24XG (24 10GE-порта). Такие устройства могут быть использованы при ToR-размещении коммутаторов в стойках с высокопроизводительными серверами, оснащенными 10GE-интерфейсами.
Экономичность . Можно сказать, что на фоне мощности, потребляемой серверами, энергопотребление обслуживающего их коммутирующего оборудования не слишком значительно. Но для ЦОДа важна не только экономия самой электроэнергии, но и стоимость инфраструктуры бесперебойного питания, поэтому здесь каждый ватт на учете. Исследуя данный вопрос, мы обнаружили, что поставщики, относительно недавно вышедшие на рынок Ethernet-коммутаторов, более щепетильно относятся к энергопотреблению своего оборудования. Например, потребляемая мощность 24-портового гигабитного L3+ коммутатора XGS-4728F фирмы ZyXEL по каталогу составляет 63 Вт, а у аналогичной модели коммутатора H3C S5500-28C-SI фирмы 3Com и вовсе 58 Вт, что существенно ниже энергопотребления в холостом режиме соответствующих моделей других известных производителей, которые специально подчеркивают сертификацию своего оборудования с точки зрения экономичности. Впрочем, экономичность коммутируемой сети ЦОДа целесообразно считать по комплексному решению, с учетом потребления старших моделей Ethernet-коммутаторов и их конкретной компоновки.
Эффективный теплоотвод . Решение проблемы охлаждения в коммутирующем оборудовании для ЦОДа имеет определенные особенности. Дело в том, что нетипичная для серверных стоек боковая система вентиляции (side-to-side), реализованная в большинстве традиционных моделей пицца-подобных коммутаторов, приносит инженерам ЦОДов много хлопот из-за эффекта замкнутого горячего контура, когда горячие «выхлопы» одного устройства «заглатываются» для охлаждения другого. Учитывая этот факт, ряд производителей уже начал поставку «плоских» стоечных коммутаторов с продольной системой вентиляции (front-to-back). Это, например, модели серий AT-x900/908 фирмы Allied Telesis и уже упомянутые модели Cisco Nexus (все семейство), Juniper EX2500, HP ProCurve 6600. Причем две последние серии предусматривают реверсивную компоновку вентиляторов (в моделях HP обращение потока производится простой перестановкой блока вентиляторов). Таким образом, мощные стоечные коммутаторы все больше по своей компоновке напоминают серверы, которые они обслуживают.
Поддержка оптических интерфейсов . Поскольку медножильные кабели категории 6A, предназначенные специально для технологии 10GE, занимают значительный объем пространства (не только в сравнении с оптическими кабелями, но даже с кабелями категорий 5e и 6), использование их в ЦОДе усложняет задачу эффективного отвода тепла. Кроме того, они проигрывают оптике в рабочих расстояниях, а «медные» порты потребляют гораздо больше электроэнергии, чем оптические, поэтому критически важной становится поддержка коммутаторами оптических интерфейсов (т.е. наличие слотов XFP или SFP/SFP+).
Однако строгий читатель может заметить, что все это справедливо и для любых современных ЛВС. В то же время к сетям ЦОДов сегодня предъявляются определенные специфические требования, связанные, в частности, с применением технологии виртуализации серверов, что сильно отличает такие сети от обычных ЛВС. Эти требования тезисно сформулировал системный инженер-консультант Cisco Александр Скороходов:
Сетевая поддержка виртуализации . Сеть передачи данных и сеть хранения должны «понимать» работу систем виртуализации вычислений, иметь возможность применять дифференцированные политики к виртуальным серверам и поддерживать возможность их миграции между физическими серверами.
Эффективная поддержка больших доменов коммутации 2-го уровня (коммутации Ethernet). Широкое использование миграции виртуальных машин усугубляет данное требование.
Все более высокая производительность и массовый переход на технологию 10-Gigabit Ethernet, поскольку консолидация вычислений приводит к росту нагрузки на сетевые интерфейсы серверов.
Консолидация ввода-вывода (переход на технологии объединенной сети). Использование виртуализации приводит к росту доли серверов, подключенных к сетям хранения данных, что делает особенно актуальной задачу консолидации ввода-вывода, т.е. отказа от отдельного подключения серверов к сетям Ethernet и Fibre Channel, а в перспективе, возможно, и от отдельных сетей передачи данных и хранения данных.
В результате своего небольшого исследования мы выяснили, что, если не считать некоторых концепций и сетевых архитектур (например, Data Center Infrastructure Solutions фирмы Juniper или аналогичных концепций HP и Nortel) и «точечных» моделей ком-мутаторов, поставщики в основном позиционируют свое Ethernet-оборудование как универсальное, которое может использоваться как в корпоративных и операторских транспортных сетях, так и в сетях ЦОДов.
Взяв на себя определенный риск, компания Cisco выпустила целую линию продуктов, позиционируемую как специализированное оборудование для ЦОДа. В нее входят коммутаторы серий Nexus 7000, 5000, 2000 и 1000V. Последний представляет собой виртуальный программный коммутатор, обслуживающий виртуальные же серверы в среде гипервизора VMware. (Можно сказать, что на наших глазах начинается этап перетаскивания очередного слоя оборудования в «зазеркалье» виртуализации.) Линия продуктов Nexus – не последняя инициатива Cisco в рамках ее концепции Data Center 3.0. Весной этого года компания вышла на рынок с новой линией продуктов Unified Computing System, поставляемой в формате блейд-шасси, и серверов для них, которые включают в себя полную сетевую инфраструктуру с конвергированной Ethernet-средой и использованием как минимум 10GE-интерфейсов. Тем самым рынку Ethernet-оборудования брошен вызов, и уже в ближайшее время можно ожидать, что на нем разгорится борьба в сфере специализированных комплексных сетевых решений для ЦОДов.
На мероприятии OCP Virtual Summit 2020 Inspur представила две новинки: коммутатор доступа SC5630EL и коммутатор агрегации SC8661SL. Обе модели построены на ASIC Broadcom в паре с Intel Xeon D-1527 (4 ядра с базовой частотой 2,2 ГГц) и имеют скорость портов до 100 Гбит/с.
Коммутатор доступа SC5630EL в форм-факторе 1U имеет 48 портов 10/25 Гбит/с и 8 портов 40/100 Гбит/с. Общая пропускная способность коммутатора достигает 4 Тбит/с. Для обработки сетевых пакетов используется отдельный процессор ASIC Broadcom Trident3 с буфером 32 Мбайт. Для управления есть выделенные порты: один RJ-45 10/100/1000 Мбит/с, один RJ-45 Serial Console Port и один USB 3.0 порт.
Для работы ОС доступно от 16 до 32 Гбайт оперативной памяти и 240 Гбайт на встроенном накопителе. Два блоки питания с возможностью «горячей замены» могут работать при входном напряжении от 90 до 265 В переменного тока, также существует версия для работы от постоянного тока напряжением от 164 до 300 В. Максимальная потребляемая мощность коммутатора составляет всего 296 Вт. Рабочая температура от 0 до 40 градусов Цельсия.
Коммутатор агрегации SC8661SL представляет собой модульное шасси форм-фактора 4U с 4 слотами для модулей расширения. Каждый модуль может иметь 32 100GbE-порта — таким образом, максимальное количество портов достигает 128. Общая пропускная способность коммутатора составляет 25,6 Тбит/с.
Ресурсы для работы ОС коммутатор имеет аналогичные предыдущей модели, но процессор для обработки сетевых пакетов установлен уже более производительный — ASIC Broadcom Tomahawk 3 с буфером 64 Мбайт. Максимальная потребляемая мощность составляет 2148 Вт, а за питание отвечают четыре (2+2) блока с возможностью «горячей замены».
Работают коммутаторы под управлением открытой ОС SONIC. Оба коммутатора могут поставляться как отдельно, так и в составе комплексного решения OCP Rack Solution for AI.
Читайте также: