Под облаками

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

Виртуализация серверов, а также ресурсов хранения данных оказывает большое влияние на архитектуру сетей в облачных средах. Для корпоративных сетей можно достаточно точно предсказать потребность в ресурсах хранения на определенный период, поэтому в обозримом будущем здесь может оказаться оправданным разделение на внешние (Front-End) и внутренние (Back-End) сети, то есть на сети передачи данных и сети хранения. Оба типа сетей в средне- и долгосрочной перспективе будут базироваться на технологии Ethernet, но при этом совсем не обязательно объединять их.

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

ИЗМЕНЕНИЕ ПОТОКОВ ПЕРЕДАЧИ ДАННЫХ

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

ВОПРОС ПРОИЗВОДИТЕЛЬНОСТИ

Другим важным фактором является производительность внутри сети. В настоящее время стандартом считается подключение серверов со скоростью 10 Гбит/с (через 10 Gigabit Ethernet, 10GbE). Желательно, чтобы порты для каскадирования на коммутаторах поддерживали 40 Gigabit Ethernet, а в обозримом будущем и 100 Gigabit Ethernet. Соответственно, владельцу такой сети при выборе коммутаторов следует обратить внимание на высокую плотность портов 40GbE, а также хотя бы на наличие пути миграции на 100GbE.

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

TRILL И SPB

Инженерная группа Интернета (IETF) разработала технологию прозрачного межсоединения множества каналов (Transparent Interconnection of Lots of Links, TRILL), а институт IEEE предложил свой стандарт кратчайшего соединения с помощью мостов (Shortest Path Bridging, SPB). По своей основополагающей идее обе технологии очень схожи: посредством протокола состояния канала (Link State Protocol) — в данном случае с помощью протокола обмена данными между промежуточными системами (Intermediate System to Intermediate System, IS-IS) — коммутаторы создают базу данных обо всех доступных путях передачи. Обращаясь к этой базе данных, они в каждом конкретном случае принимают решение о выборе маршрута для пакета. При этом все доступные каналы задействуются одновременно, но петель не возникает.

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

ФАНТАЗИИ НА ТЕМУ КОММУТИРУЮЩИХ СТРУКТУР

В последнее время некоторые производители активно пропагандируют использование так называемых фабрик (Fabric).

Такие структуры объединяют все коммутаторы облачной сети в одно логическое устройство и воспринимаются извне как большой коммутатор. На первый взгляд эта концепция может показаться очень соблазнительной, поскольку она позволяет управлять всей сетью через одну-единственную логическую инстанцию. Производители соответствующих решений охотно используют в качестве рекламного лозунга такое понятие, как «сеть с одним переходом» (Single-Hop Network). Однако к подобным обещаниям следует относиться чрезвычайно осторожно. Во-первых, все представленные на рынке решения для создания коммутирующих структур представляют собой сугубо проприетарные технологии, то есть владелец такого решения будет вынужден приобретать все сетевые компоненты у определенного производителя.

Во-вторых, понятие «сеть с одним переходом» по своей сути не более чем рекламный трюк, ведь и сети с топологией типа Fabric имеют несколько уровней. Так, к примеру, если нужно переслать пакет с одного коммутатора в стойке (Top-of-Rack, ToR) на другой, то путь этого пакета по-прежнему будет пролегать через несколько уровней. Упомянутый «один переход» является сугубо виртуальным и в действительности не оказывает никакого положительного влияния ни на избыточное бронирование (Overbooking), ни на продолжительность задержек (Latency) в сети. Кроме того, в тех сетях, где используются такие структуры, существенно затрудняется поиск неполадок, поскольку практически отсутствует возможность воздействия на ее поведение вручную, а маршруты и правила, которым следуют потоки данных в этой структуре, неясны и запутанны. Поэтому от использования таких проприетарных решений рекомендуется воздержаться.

ОТКРЫТАЯ АЛЬТЕРНАТИВА

Решение OpenFlow от Open Networking Foundation похоже на только что рассмотренное и отличается лишь тем, что является открытым. Цель этой архитектуры — отделение плоскости управления (Control Plane) коммутаторов от плоскости данных (Data Plane). При этом решение о выборе дальнейшего пути следования данных принимается внешним контроллером OpenFlow на основе потоков (Flow). В объединение Open Networking Foundation входят практически все более или менее известные производители сетевого оборудования, поэтому концепцию OpenFlow и стандартизированные решения можно считать синонимичными понятиями. Однако тестовых сред создано пока немного — преимущественно в университетах, и, таким образом, пройдет еще несколько лет, пока технология OpenFlow достигнет рыночной зрелости. Тем не менее эта спецификация вполне может стать серьезной альтернативой для сетей в ЦОД.

Оптимальная на сегодняшний день реализация структуры второго уровня для облачных сред предполагает комбинацию двух существующих технологий: организацию стека (Stacking) из нескольких стоечных коммутаторов и использование технологии Multi-Switch Link Aggregation Groups (MLAG). Стеки объединяют несколько (обычно не более восьми) стоечных коммутаторов в одно логическое устройство. В отличие от концепции Fabric, это реализуется посредством отдельной шины, имеющей пропускную способность до нескольких сотен гигабит в секунду. Этот метод наиболее успешно применяется именно для объединения стоечных коммутаторов, поскольку позволяет сократить количество коммутаторов, требующих администрирования, и реализовать трафик «восток — запад» между соседними стойками через внутреннюю шину, а не через ядро сети. Затем стеки соединяются с ядром через группы MLAG.

По сути, группа MLAG реализует традиционную функцию агрегации каналов (Link Aggregation Group, LAG) по стандарту IEEE 802.1AX (ранее 802.3ad): несколько физических каналов формируют один логический, что позволяет повысить общую пропускную способность сети, однако технология MLAG распределяет эти логические каналы в ядре по двум разным системам. Для внешних устройств этот процесс прозрачен: подключенный сервер или коммутатор в стойке «не знает», что он соединен с двумя разными системами, с его точки зрения он по-прежнему имеет дело с традиционной группой LAG. Строго говоря, технология MLAG проприетарна, поскольку необходимо, чтобы обе системы в ядре сети были выпущены одним производителем, однако это ограничение затрагивает исключительно уровень ядра и никак не проявляется за его пределами. Так в стойке можно устанавливать любые коммутаторы, и даже ядро сети при необходимости вполне реально заменить системами другого производителя.

ПРИМЕР ИЗ ПРАКТИКИ

Рисунок 1. Наименьшая структурная единица в архитектуре облачной сети представляет собой портативный оптимизированный ЦОД (Portable Optimized Datacenter, POD).

Практическое применение этих основополагающих принципов при создании облачных инфраструктур можно увидеть на примере архитектуры, разработанной компанией Extreme Networks для крупного провайдера облачных хостинг-услуг. Поскольку такая сеть должна допускать значительное масштабирование, в основу этой архитектуры положен модульный принцип. Наименьшей структурной единицей является так называемый портативный оптимизированный ЦОД (Portable Optimized Datacenter, POD), состоящий из двух стоек. В каждой стойке размещаются 20 серверов и системы хранения данных iSCSI емкостью около 50 Тбайт, а кроме того — стоечный коммутатор с 48 портами 10GbE и четырьмя портами для каскадирования 40GbE (см. Рисунок 1). Серверы и системы хранения подключены к обоим стоечным коммутаторам через группы MLAG. Когда ресурсов одного модуля POD перестает хватать, к нему просто добавляется еще один. В этом примере левые и правые стоечные коммутаторы обоих модулей образуют по стеку, то есть одно логическое устройство. Таким образом, на два POD по-прежнему приходится два логических стоечных коммутатора (см. Рисунок 2).

Рисунок 2. Левые и правые стоечные коммутаторы образуют по одному стеку. Таким образом, на два POD по-прежнему приходятся два логических стоечных коммутатора.

Когда сеть разрастается до четырех POD, формируется так называемая зона ЦОД (Datacenter Zone). Внутри этой зоны левые и правые стоечные коммутаторы тоже подключаются к одному стеку (см. Рисунок 3), то есть и здесь имеется всего два логических стоечных коммутатора. Пропускная способность соединений в стеке между отдельными коммутаторами в стойке составляет 160 Гбит/с. Преимущество такой архитектуры заключается в том, что трафику «восток — запад» не приходится покидать пределы своей зоны. Если виртуализация систем хранения будет ограничена одной зоной, такой трафик уже не пойдет через ядро сети, что, кроме прочего, положительно сказывается на избыточном бронировании восходящего соединения с ядром.

Рисунок 3. Когда сеть разрастается до четырех POD, формируется зона ЦОД. Внутри этой зоны левые и правые стоечные коммутаторы тоже подключаются к одному стеку.

ЛИКВИДАЦИЯ УРОВНЯ РАСПРЕДЕЛЕНИЯ

При рассмотрении этой архитектуры сразу же обращает на себя внимание отсутствие уровня End of Row (EoR), или распределения (Distribution Level). Причина в том, что при доступной сейчас плотности портов в коммутаторах ядра сети в большинстве случаев достаточно запланировать один или два уровня сети. Так, современные коммутаторы ядра сети могут предоставить до 768 портов 10GbE или 192 портов 40GbE в корпусе высотой 14U. При такой плотности размещения портов в архитектуре POD с использованием групп MLAG можно создать до 22 зон, связанных с ядром соединениями со скоростью 320 Гбит/с (см. Рисунок 4). От каждого стоечного коммутатора к ядру сети идет канал 40 Гбит/с. Все восемь каналов объединены в одно логическое соединение. В приведенном примере двухуровневая сеть сможет поддерживать до 176 стоек, вмещающих в сумме до 3520 серверов. Однако это еще далеко не предел: теоретически возможно расширение до более чем 9 тыс. серверов, имеющих до 128 тыс. виртуальных экземпляров.

Рисунок 4. Благодаря высокой плотности портов, архитектура POD с использованием групп MLAG позволяет создать до 22 зон, связанных с ядром соединениями со скоростью 320 Гбит/с каждое.

ОБЛАКАМ ТРЕБУЕТСЯ ВЫСОКАЯ МАСШТАБИРУЕМОСТЬ

Важнейший элемент проектирования облачных сред — это масштабируемость виртуализированных серверов, ресурсов хранения данных и сети. Ныне доступные сетевые технологии, такие как 40GbE, MLAG и создание стеков, позволяют строить масштабируемые и высокопроизводительные инфраструктуры, охватывающие от 40 до 9 000 серверов, без обращения к проприетарным технологиям. Благодаря этому такие архитектуры в равной мере пригодны как для ЦОД средних предприятий, так и для крупных облачных сред.

Олаф Хагеманн — менеджер по подготовке продаж в регионе DACH (Германия, Австрия, Швейцария) в компании Extreme Networks.