Сеть для «облака» КРОК

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

«Крок» первой из российских ИТ-компаний стала предлагать облачные решения на базе собственной разработки. По данным J’son & Partners Consulting (2012 год), она является лидером рынка облачных решений IaaS в России. Компания предоставляет своим заказчикам виртуализированные ИТ-ресурсы (серверы, дисковые массивы хранения и сетевую инфраструктуру, вместе составляющие надежный и катастрофоустойчивый виртуальный центр обработки данных «Крок»), а также предлагает в аренду ИТ-сервисы (SaaS), размещенные на серверах собственных ЦОД. Все услуги предоставляются через Интернет либо по выделенным каналам связи, а управлять ими заказчики могут с помощью специально разработанного «Крок» портала самообслуживания.

Облачные платформы развернуты в двух из трех ЦОД компании: «Волочаевская-1» и «Компрессор». Новейший мегаЦОД «Компрессор» общей мощностью 8 МВт и вместимостью 800 стоек введен в эксплуатацию в декабре 2011 года, его проект сертифицирован на уровень надежности Tier III по классификации Uptime Institute. Все три ЦОД «Крок» объединены общим оптическим кольцом с выходом на основные узлы обмена трафиком.

ВЗАИМОИСКЛЮЧАЮЩИЕ ЗАДАЧИ?

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

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

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

Если детализировать эти требования, то их можно разделить на две группы: одна связана с предоставлением транспорта как такового (Data Plane), другая — с реализацией функциональности для взаимодействия виртуализированных ИТ-ресурсов (Control Plane).

«ЖЕЛЕЗНАЯ ФАБРИКА»

Для передачи данных требовалось построить отказоустойчивую плоскую сеть L2, без использования протокола STP и с достаточно большой пропускной способностью. При решении этой задачи важно было избежать проблем классического Ethernet. «Ethernet обладает некоторыми родовыми болезнями: постоянная перестройка деревьев, штормы трафика, возникновение которых невозможно предсказать», — продолжает Руслан Заединов.

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

Рисунок 1. Использование технологии M-LAG в сети облачной платформы ЦОД компании «Крок». Два объединенных в группу M-LAG канала 10G от каждого коммутатора Summit X460 проложены к двум разным коммутаторам Summit X670.

В качестве коммутаторов доступа в сети ЦОД используются продукты Summit X460 производства Extreme Networks. По одному такому коммутатору установлено в каждой стойке с серверами (Top of Rack, ToR), при этом к каждому коммутатору подсоединяются не только серверы из «его» стойки, но и из соседней. Таким образом обеспечивается отказоустойчивое подключение серверов с балансировкой нагрузки. Для обслуживания 88 серверов (максимальное число серверов в одной стойке — 20) установлено восемь коммутаторов Summit X460, которые каналами 10GbE подключены к двум коммутаторам Summit X670, формирующим ядро сети (см. Рисунок 1). Коммутаторы Summit имеют полностью неблокируемую архитектуру, что позволяет одновременно использовать все их порты на полной скорости.

Главная особенность такого решения — в технологии кластеризации коммутаторов Multi-Switch Link Aggregation Groups (M-LAG), которая позволяет отказаться от устаревшего протокола STP, крайне медлительного да к тому же «замораживающего» часть сетевых ресурсов. Технология M-LAG базируется на стандартной функции агрегации каналов (Link Aggregation Group, LAG, стандарт IEEE 802.1ad), которая обеспечивает объединение нескольких физических каналов в один логический с целью повышения общей пропускной способности соединения. M-LAG распределяет эти логические каналы по двум разным системам: в описываемой сети два объединенных в группу M-LAG канала 10GbE от каждого коммутатора Summit X460 идут к двум разным коммутаторам Summit X670.

Для внешних устройств процесс работы M-LAG прозрачен: подключенный коммутатор доступа (или сервер) «не знает», что он соединен с двумя разными системами, с его «точки зрения», он по-прежнему имеет дело с традиционной группой LAG. Это позволяет использовать все преимущества M-LAG даже для подключения коммутаторов других производителей: например, в сети ЦОД «Волочаевская-2» эта технология применяется для взаимодействия с коммутаторами узла связи производства Cisco.

Два коммутатора Summit X670 соединены линками 40GbE, агрегированными в один канал 80GbE. Столь высокая пропускная способность необходима для «жизнедеятельности» облака, особенно когда происходят установка и настройка (или перенастройка) большого числа виртуальных машин и передаются «тяжелые» образы операционных систем.

Несложный подсчет показывает, что при описанном выше двойном подключении серверов на каждом коммутаторе доступа Summit X460, оснащенном 48 гигабитными портами, часть таких портов остаются свободными. Их было решено использовать для создания отдельной сети, обеспечивающей управление серверами и сетевым оборудованием по внешнему каналу (out-of-band). Для этого была задействована реализованная в оборудовании Extreme Networks функция Virtual Router (VR), позволяющая на одном и том же коммутаторе создать две отдельные сети. В управляющей сети каждый сервер подключен отдельным гигабитным каналом к коммутаторам доступа, а сами коммутаторы объединены также гигабитными каналами. Резервирование в данном случае не требуется, поскольку какаялибо авария на этой сети не является критической — всегда можно перейти на управление через основные каналы (in-band).

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

Для построения катастрофоустойчивых решений и обеспечения миграции виртуальных машин и дисковых систем хранения огромное значение имеет наличие высокопроизводительной, отказоустойчивой сети не только в рамках одного ЦОД, но и между территориально удаленными ЦОД. Для организации взаимодействия между своими ЦОД специалисты «Крок» также решили использовать преимущества технологии кластеризации коммутаторов M-LAG, которая применяется в сети между ЦОД «Волочаевская-1» и «Компрессор».

Для этого в каждом центре обработки данных установлена пара коммутаторов, соединенных между собой двумя гигабитными каналами. Эти коммутаторы объединены в кластер посредством технологии M-LAG (см. Рисунок 2). Удаленные коммутаторы подключаются по принципу «каждый с каждым», что, благодаря использованию M-LAG, позволяет организовать отказоустойчивый канал с пропускной способностью 4 Гбит/с с балансировкой нагрузки. Две физические линии связи (длиной 7 и 11 км) пролегают по разным маршрутам, что повышает надежность связи между двумя ЦОД. Сейчас идет модернизация этих линков до 40 Гбит/с на каждый — это позволит обеспечить более высокую пропускную способность между ЦОД.

Рисунок 2. Взаимодействие между сетями ЦОД тоже организовано с использованием технологии M-LAG.

ВИРТУАЛЬНЫЕ ТУННЕЛИ

Требования, которые выдвинул бизнес к плоскости управления облачной сетью, поначалу поставили сетевых специалистов в тупик. Задача была следующей: создать минимум 1 млн изолированных сетей L2 с поддержкой функций контроля доступа (ACL), гарантией качества обслуживания (QoS), возможностью миграции виртуальных машин и т. д. Логика бизнеса была понятна: предположим, со временем в ЦОД придут 10 тыс. заказчиков и у каждого будет по 100 виртуальных сетей — вот вам и миллион. Но как выполнить эту задачу технически, если традиционная технология VLAN предусматривает максимум 4 тыс. идентификаторов?

«Стали искать решение, — рассказывает Максим Казаков, системный инженер «Крок». — Мы, конечно, знали про MPLS и про технологию MAC in MAC, но как к этому «прикрутить» миграцию виртуальных машин, не представляли. Уже тогда появились виртуальные коммутаторы, например Cisco vSwitch, но на тот момент они не работали с RedHat KVM — платформой с открытым исходным кодом, на базе которой построено наше облако».

Рисунок 3. Плоскость управления, обеспечивающая функционал для взаимодействия ресурсов ИТ, построена в соответствии с принципами SDN:  между программными коммутаторами Open vSwitch формируется сеть виртуальных туннелей, а управление этими коммутаторами осуществляется внешним контроллером по протоколу OpenFlow.

В результате поисков было решено строить плоскость управления на базе виртуальных коммутаторов Open vSwitch, которые, как и RedHat KVM, базируются на ПО с открытым исходным кодом. Для управления ими используется контроллер, точнее отказоустойчивый кластер контроллеров, разработанный компанией Nicira (являясь технологическим партнером Nicira, «Крок» имеет возможность влиять на развитие продуктов, этот статус сохранился и сейчас, после вхождения компании в состав VMware). Такая схема полностью соответствует идеологии сетей SDN (см. Рисунок 3). К тому же для взаимодействия между контроллером и программными коммутаторами Open vSwitch используется протокол OpenFlow.

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

Функционирующие на уровне гипервизоров коммутаторы Open vSwitch строят между собой туннели, образующие полносвязанную топологию. Как только трафик пользователя попадает в такой виртуальный коммутатор, он сразу помещается в свой туннель. Трафик разных клиентов не смешивается, а физическая сеть «не видит» их адресную информацию.

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

В настоящее время в двух ЦОД компании «Крок» применяются независимые кластеры контроллеров, однако в течение 2013 года планируется реализовать синхронизацию кластеров двух площадок (см. Рисунок 4).

Рисунок 4. Перспективы развития сети с синхронизацией двух территориально разнесенных контроллеров.

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

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

Александр Барсков — ведущий редактор «Журнала сетевых решений/LAN». С ним можно связаться по адресу: ab@lanmag.ru.