Адаптация СКС к требованиям ЦОД

В последние год-два все более очевидным становится разделение рынка СКС на две различающиеся по подходам к их реализации части: речь идет об офисных системах и решениях для ЦОД. Если в первом случае построение универсальной кабельной системы оправданно как экономически, так и идеологически (проекты, по сути, отличаются только своими масштабами), то во втором — попытки создать универсальную СКС выливаются либо в неоправданные финансовые затраты, либо в негибкую и не очень хорошо работающую систему.

FULL MESH НА УРОВНЕ ДОСТУПА

В чем же причина? Ведь многие годы все сети (в том числе и в серверных) строились в соответствии с иерархической трехуровневой архитектурой (см. Рисунок 1): ядро, распределение, доступ, клиенты с резервируемым подключением к коммутаторам. Такая иерархия позволяла реализовать стандартную кабельную систему — иерархическая кабельная звезда накладывается на эту структуру наиболее естественным образом.

Рисунок 1. Традиционная трехуровневая архитектура.

Конечно, за универсальность приходилось платить свою цену. Так, в разветвленной структуре возникали серьезные задержки при прохождении пакетов от уровня доступа до ядра и обратно. Однако все с этим мирились до появления идеи унификации локальных сетей и сетей хранения и семейства протоколов Converged Enhanced Ethernet (CEE), частью которых является Fibrе Channel over Ethernet (FCoE). При этом стало очевидно, что использование традиционной архитектуры для построения сетей CEE приводит к неприемлемым задержкам для трафика FCoE.

Взяв за основу связную коммутируемую архитектуру (switched fabric), применявшуюся для построения сетей Fibrе Сhannel, производители сетевого оборудования начали предлагать построение сетей по схеме, представленной на Рисунке 2. Вроде бы, структура похожа — те же три уровня, но для нее характерна практически полная связность (full mesh) на втором уровне. Попытки построить подобные сети (в основном в целях обеспечения отказоустойчивости и балансировки нагрузки) предпринимались и раньше, однако, как показал опыт, стремление воспроизвести эту схему с использованием традиционного сетевого оборудования приводит к появлению очень большого числа точек администрирования (проблема, с которой производители сетевого оборудования активно борются) и потенциальным отказам в масштабах всей сети ЦОД.

Рисунок 2. Архитектура коммутирующей фабрики.

Тем не менее тенденция такова: все больше заказчиков при построении своих сетей ориентируются на применение оборудования наподобие Cisco Nexus или Juniper QFabric и построение сетей передачи данных с плоской топологией второго уровня. Gartner ожидает, что в следующем году по данной модели будет строиться около трети всех новых ЦОД. Переход к ней стимулируется увеличением числа потоков «сервер – сервер» и «сервер – система хранения». Поставщикам СКС остается только приспособить свои системы к коммутирующей структуре Switched Fabric, проповедуемой такими сетевыми вендорами, как Cisco, Juniper и другие.

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

ПРОБЛЕМЫ СЕТЕЙ ХРАНЕНИЯ

Пять лет назад сети хранения были сравнительно небольшими — количество устройств хранения и клиентов в сети FC было гораздо меньшим, чем мы видим в современных ЦОД. Резкое увеличение размеров физической сети для поддержки сети хранения ведет к чрезвычайно высокой концентрации оптики в ядре. Порой плотность оптики достигает 800– 900 волокон на 8–10 юнитов. Раньше такую картину можно было наблюдать только на магистральных узлах провайдеров либо в очень крупных ЦОД на 30–40 МВт. Во всех остальных случаях не приходилось особенно задумываться о том, где и как прокладывать оптику, каким образом ее укладывать в лотки, как разносить с медными кабелями и системами электропитания и т. д.

Претерминированная оптика позволяет худо-бедно бороться с проблемой растущих размеров сети хранения, но она не оптимальна с точки зрения затухания — переходное затухание на MPO-разъемах является не таким уж маленьким. Как результат, при использовании таких протоколов, как FC на 8 и 16 Гбит/с, у которых бюджет затухания составляет около 2 дБ, желание построить гибкую систему, которую легко наращивать, вступает в противоречие с необходимостью обеспечить приемлемый уровень затухания.

При этом следует иметь в виду, что у всех производителей СКС бюджет для претерминированной оптики рассчитывается статистически. Даже если взять наихудший случай, затухание на любом MPO-разъеме любого производителя не превысит полдецибела — от 0,3 до 0,5. Однако предельный случай встречается крайне редко, и для кабельного тракта, состоящего из большого количества соединений MPO, шанс получить 4–5 одинаково плохих соединений MPO подряд будет равен нулю. Большинство производителей согласны принять такой риск на себя и решать эти проблемы в рамках гарантийных претензий, поэтому в выполненных ими расчетах затухание на пяти соединениях никогда не будет равно 2,5 дБ. Но все равно получаемая цифра достаточно близка к тем лимитам, которые устанавливает протокол.

Таким образом, растущий спрос на те возможности, которые обеспечивает протокол FC, привел к увеличению объемов использования оптики в ЦОД. В свою очередь, проектировщики начали изыскивать способы грамотного построения кабельной системы для сети хранения, чтобы ее можно было быстро и эффективно наращивать.

ЗНАЙ СВОЙ ПРЕДМЕТ

Так каким же образом должна выглядеть кабельная система в ЦОД? На этот вопрос невозможно ответить, не имея представления о том, как будут организованы сеть передачи данных и сеть хранения данных (конечно, если это не машзал на 20–30 стоек). На все большем числе объектов следование традиционной схеме оборачивается провалом, причем в крупных ЦОД такая схема иногда физически нереализуема, а если все же удается ее внедрить, это приводит либо к серьезным финансовым затратам, либо к нехватке емкости и постоянной потребности в изменении кабельной инфраструктуры.

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

О чем следует помнить, так это об управлении по внешнему каналу (outofband management — возможность администрировать устройства, не используя основную сеть передачи). Об этом, например, нередко забывают специалисты Cisco, поскольку такая сеть не вписывается в архитектуру Unified Fabric Architecture (UFA). В реальности же подобная сеть имеется практически всегда. И о ее существовании неплохо вспоминать до начала проектирования СКС, а не после завершения монтажа.

Рисунок 3. Централизованная схема с прямым подключением.

ТРИ ТОПОЛОГИИ

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

В зависимости от этого кабельная система реализуется в соответствии с одним из трех вариантов:

• схема с центральным кроссом (DirectConnect);
• схема Top of Rack (ToR);
• зонная схема (Zone).

Централизованная схема. Скорее всего, если только вы не создаете ЦОД на 200–300–400 стоек, сеть хранения будет строиться по централизованной схеме, когда все оборудование будет сведено в центр, как физически, так и топологически. Именно эта схема в первую очередь рассматривается при обдумывании проекта ЦОД, когда приходится решать, как доставить сервис в шкафы. В этом случае все оборудование — не только коммутаторы ядра, но также устройства распределения и доступа, директора FC и системы хранения — сконцентрировано в одном месте. Это предполагает построение достаточно масштабной медной и оптической (с учетом FC) систем.

Достоинства. Такая схема лучше всего подходит для небольшого ЦОД — любой сервис можно подать в любое место серверной комнаты. Она обеспечивает четкое разграничение обязанностей вследствие разнесения оборудования — пассивным кроссом могут заниматься одни специалисты, активным оборудованием — другие. Решение вполне конкурентоспособно и с точки зрения обеспечения физической безопасности и разграничения контроля.

К тому же оно обеспечивает эффективное использование портов сетевого оборудования — количество потребителей и, следовательно, количество портов можно четко просчитать как для целей наращивания, так и для оценки загрузки.

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

Top of the Rack. Противоположный подход к централизации представляет собой децентрализация, когда коммутаторы доступа размещаются внутри стойки. И хотя многие поставщики СКС поначалу были против этой схемы, боясь, что она приведет к сокращению потребления кабелей, большинство проектов, реализованных по этой схеме, как минимум не дешевле любых других (в части СКС).

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

В соответствии с концепцией ToR уровень доступа перемещается ближе к серверам. Для обеспечения отказоустойчивости должно быть установлено как минимум два коммутатора. В одном шкафу или соседних — это другой вопрос. Кроме того, возможно, потребуется коммутатор для внешнего управления OOB (такие примеры есть, но, на мой взгляд, они не вполне оправданны с экономической точки зрения). Кроме того, если пропагандируемые Brocade идеи найдут воплощение на практике, в шкафу будут располагаться один-два коммутатора-директора FC, так что от четырех до шести юнитов в нем окажется занято сетевым оборудованием. Зато до шкафа будет проложена только оптика (медь нужна исключительно для OOB). Магистральный канал (uplink) должен быть достаточно надежным — иначе при его потере теряется не одно устройство, а целая стойка (что особенно актуально в свете рассмотренной выше концепции).

Внутри стойки прокладываются оптические шнуры. Однако, по моему глубокому убеждению, от этого многие станут отказываться в самом ближайшем будущем по причине экономической неэффективности — 10BaseT сегодня стал дешевым решением (сетевая карточка Intel в Москве стоила весной менее 500 долларов). Таким образом, внутри шкафа будет прокладываться медь (шнуры Категории 6A) вместо оптики.

Как говорилось в начале статьи, схема ToR изначально задумывалась для FCoE, и для нее она наиболее актуальна. На горизонтальном уровне применяется универсальная среда передачи для FC и Ethernet, несмотря на то что на уровне распределения она опять делится на две части. Такая система гораздо проще в администрировании. Впрочем, на реальных объектах реализацию FcoE наблюдать не доводилось. В результате кабельная система для Ethernet реализуется по схеме ToR, а для FC — по Direct Connect. Из-за того что вся оптика проводится в центр, получается много оптики в шкафу.

Достоинства. СКС становится в основном оптической и при этом имеет гораздо меньшие размеры. Конечно, для FC по-прежнему требуется много оптики, но с этим можно бороться другими способами. Если все правильно спроектировано, а в качестве горизонтальной кабельной системы используется претерминированная оптика, то такое решение легко наращивается. Собственно саму СКС легко эксплуатировать — количество переключений небольшое.

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

Поскольку они весьма чувствительны к перегреву, надо использовать оборудование доступа, которое разрабатывалось для установки в серверную стойку, например коммутаторы Nexus 2xxx.

Недостатки. Если не используется виртуализированная сетевая инфраструктура (Cisco Nexus, Juniper QFabric), то от схемы ToR лучше отказаться — вряд ли вас привлекает возможность получить на 200 стоек 400 потенциальных точек отказа и администрирования. Эксплуатация такой сети требует серьезных усилий, особенно в плане управления и поддержки, — решение хоть и универсальное, но на каждое устройство необходим свой сервисный контракт. Надо очень тщательно просчитывать экономическую эффективность данного решения при планируемом сроке жизни ЦОД. В ряде случаев смысл в этом есть, но подозреваю, что многие клиенты, которые строили инфраструктуру по такой схеме, делали это наобум. Нужно также просчитывать стоимость портов и эффективность их использования. В принципе, у Cisco и Juniper, например, есть коммутаторы доступа с небольшим числом портов, начиная от 8. Подобрать оборудование, которое соответствует текущим потребностям, не проблема, но вот как его дальше наращивать?

Зонная структура. В средних и небольших ЦОД (если у вас 20–30–50 стоек в одном машзале) зонную схему применять нецелесообразно (за исключением случаев, когда не хватает доступного пространства). Идея проста — создать минимальную единицу наращивания для большого помещения.

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

Чаще всего внутри зоны коммутаторы доступа располагаются в конце ряда (End of Row, см. Рисунок 4, а). Когда необходимо обеспечить физическое разнесение уровня доступа, они располагаются с обоих концов ряда. Такой подход значительно повышает отказоустойчивость при неплохой гибкости.

Рисунок 4. Различные зонные схемы: а — в конце ряда, б — в середине ряда, в — с выделенным сетевым рядом.

Интересный вариант — установка коммутаторов в центре ряда (Middle of Row, см. Рисунок 4, б). Это позволяет развести кабельные трассы, которые идут от коммутаторов доступа на уровень распределения. Если объем оптики велик, то при помощи подобной конфигурации удается корректно развести кабели по разным трассам. Когда они проложены под фальшполом, помехи для системы охлаждения оказываются минимальны.

Зоны с выделенным сетевым рядом (см. Рисунок 4, в) организуются преимущественно на больших площадках (предыдущие два варианта используются и в относительно небольших ЦОД). Один такой ряд, представляющий собой выделенное пространство, где сосредоточены кабельная инфраструктура и коммутаторы доступа, обслуживает несколько рядов серверных шкафов. По большому счету такая зона — мини-ЦОД по схеме Direct Connect в виде модуля.

Для эффективного зонирования надо иметь представление о том, каким образом мы будем размещать оборудование, кто будет выступать в роли потребителей, где будут устанавливаться блейдсерверы, монолитные системы (типа Superdome) и т. д. Зонная структура при всей ее внешней привлекательности требует серьезного планирования со стороны заказчика в первую очередь, чего, к сожалению, практически никогда не бывает. Универсальную структуру, обеспечивающую установку любого оборудования в любой точке машзала, создать невозможно (или такой проект окажется слишком затратным). Если мы знаем, где и какое оборудование будет стоять (СХД, ленточные библиотеки, отдельные конструктивы, корзины с блейдами и т. д.), тогда структура как локальной, так и кабельной сети станет более понятной. А заодно решится вопрос, достаточно ли воздушного охлаждения или придется точечно применять другие решения.

Зонирование — правильная мера, но заказчики должны представлять, как это будет выглядеть. К сожалению, слишком часто они даже не знают, какое оборудование у них будет установлено: «Нам надо сделать ЦОД, а потом мы туда будем что-нибудь ставить, и это чтонибудь может быть чем угодно». Но за заказчика эту проблему никто не решит.

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

Недостатки. Зонирование не подходит для небольших ЦОД (за исключением тех случаев, когда не хватает пространства для прокладки кабелей). Если требуется максимально использовать дорогостоящие порты, то оптимальный выбор — централизованная схема. А когда планируется сделать всю сеть полносвязной и заказчик собирается использовать FCoE, то лучше подойдет ToR.

Степан Большаков — технический директор подразделения Enterprise Solutions компании Commscope в России и СНГ. С ним можно связаться по адресу: sbolshakov@commscope.com.