Единая инфраструктура «Облако + физическое оборудование»

В данной статье мы расскажем о проблемах, которые могут возникнуть при объединении физического оборудования и облачных мощностей в единую инфраструктуру. Не у всех возникают такие ситуации, поскольку многие компании изначально размещают свои ресурсы полностью в публичном облаке, некоторые, если позволяют ресурсы, разворачивают собственные частные облака, а некоторые, не доверяя облачным технологиям, просто размещают всё на физических серверах. Но бывают проекты, которым, по тем или иным причинам, необходимо использовать как физические сервера так и облачные. Естественно, данные мощности должны быть связаны между собой сетью. Некоторые используют для этих целей сеть Интернет (напрямую или через VPN), но это не всегда безопасно и выгодно, так как объем трафика между серверами значительно превышает внешний. Это грозит чрезмерной загрузкой внешнего канала и, как следствие, увеличением расходов, из-за необходимости приобретать широкий Интернет-канал.

^[1]
Распространенная схема маршрута трафика при подключении через Интернет между физическим и виртуальным сервером в одном дата-центре.

Чтобы избежать подобных проблем лучше использовать отдельный канал под внутреннюю сеть. Если физические сервера размещены в одном дата-центре, либо все расположено в одном облаке, то это не проблема. Если же мощности находятся и в облаке, и на физических серверах, могут возникнуть проблемы, независимо от того, размещен проект в одном дата-центре или разнесен в нескольких. А если публичное облако находится в одном дата-центре, а физическое оборудование — в другом? Тут все еще сложнее.

^[2]
Распространенная схема маршрута трафика при подключении через Интернет между физическим и виртуальным сервером в разных дата-центрах.

Мы нашли решение подобной проблемы и успешно применили его в инфраструктуре одной московской оптово-розничной торговой компании. О чем расскажем далее.

Для начала давайте определимся, зачем и в каких случаях это может понадобиться:

• У компании есть физическое оборудование, размещенное в дата-центре, и есть намерение его и дальше использовать, но мощностей уже не хватает, а развиваться куда-то надо. Облако — отличное решение!
• Весь проект размещён на физических серверах (арендованных или своих), а руководство компании не доверяет облакам, но готово попробовать.
• Есть необходимость или желание иметь полную копию проекта, размещённого на физических серверах на случай отказа. Репликация в облако — хорошее решение.
• Есть необходимость или желание хранить бэкапы в облаке.
• Порой проекты невозможно полностью виртуализировать, или они выходят за рамки мощности облачных серверов. В данном случае возможно часть инфраструктуры разместить на физических серверах, а часть — в облаке.

Это далеко не все возможные причины, мы перечислили основные и наиболее распространенные, с которыми приходилось сталкиваться на практике.

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

• Юридические. Компания-разработчик облака не имеет своего собственного дата-центра, и размещается как обычный клиент colocation в одном или нескольких дата-центрах. В этом случае компания может продавать только свои облачные мощности, но связать своё сетевое ядро с ядром дата-центра у неё нет возможности.
• Технические. Компания-разработчик облака имеет свой дата-центр, но при разработке облака для него было создано отдельное сетевое ядро, и не была учтена возможность интеграции с ядром дата-центра. В силу технических ограничений позже это сделать проблематично (различные производители сетевого оборудования, ПО, модели оборудования и т.д.)
• Организационные. Компания-разработчик облака имеет свой дата-центр, но в силу организационных моментов дата-центр и облако — это два разных проекта, которыми занимаются две независимые команды. Разграничение сетевых ядер, например, может быть организовано в силу политики безопасности компании.

Если же облако и физическое оборудование находятся в разных дата-центрах, то возникает ещё больше нюансов, как в данном случае. Но все вопросы решаемы, если облако изначально было правильно спроектировано. Расскажем как это сделали мы.

Изначально было решено, что строить отдельное сетевое ядро под облако не имеет смысла. Это было связано с тем, что мы хотели максимально унифицировать сетевые услуги для части инфраструктуры на физическом оборудовании в наших дата-центрах, и для ресурсов проекта в облаке. Фактически такие услуги как: Защита от DDoS-атак, Балансировка трафика, Организация VPN, Полосы доступа в Интернет, Выделенные каналы связи и другие услуги оказываются в рамках проекта одинаково, будь то физическое оборудование или облако.

Останавливать на описании сетевого ядра сейчас не будем, по нему есть отдельный пост ^[3] с фотографиями и описанием. Расскажем только о решении, касаемо облака.
Понятно, что облачные ресурсы находится в отдельных стойках, имеют свои коммутаторы, но ядро используется общее. В стойках, где размещено облако, стоят коммутаторы Cisco Catalyst серии 3750X объединённые в единый стек. От ядра прокинуто по четыре аплинка до двух коммутаторов в одну из стоек. Естественно данные аплинки резервируют друг друга, и в случае выхода из строя одного из коммутаторов, части ядра, или аплинка клиент этого не заметит.

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

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

В то же время система виртуализации Hyper-V, которая установлена на хостах, прекрасно понимает разделение трафика на VLAN-ы. Архитектура достаточно простая:

• Трафик приходит на сетевой адаптер физического сервера.
• Сетевой адаптер полностью пропускает сетевой трафик, «не обращая внимания» на VLAN-ы до виртуального коммутатора Hyper-V (функция VLAN Promiscuous).
• Далее виртуальный коммутатор Hyper-V разделяет трафик на VLAN-ы, и передаёт нужный трафик нужным виртуальным сетевым адаптерам.
• Операционная система в виртуальном сервере через виртуальный сетевой адаптер получает нужный трафик как «untagged».

Если виртуальному серверу необходимо получать трафик из нескольких изолированных VLAN-ов, то добавляется несколько виртуальных сетевых адаптеров, каждому из которых назначается определённый VLAN.

^[4]
Примерная схема организации внутренней сети между физическими и виртуальными серверами в данном проекте.

Как это реализовано в данном проекте? Процесс подключения происходит следующим образом:

• Клиенту было выделено два VLAN-а с заведенными туда подсетями. Например, VLAN1 10.1.1.0/24 и VLAN2 10.1.2.0/24.
• Виртуальному серверу добавлен виртуальный сетевой адаптер, подключённый к VLAN1.
• Физический сервер отдельным сетевым портом подключен к коммутатору в стойке. На порт подаётся VLAN2.
• В ядре настроена маршрутизация между сетями 10.1.1.0/24 в VLAN1 и 10.1.2.0/24 в VLAN2 (надо понимать, что связь между серверами будет по L3).
• На виртуальном сервере на новом сетевом адаптере назначен ip-адрес из подсети 10.1.1.0/24 (Если это единственный сетевой адаптер, то прописывается и шлюз этой подсети. Если другой шлюз уже прописан на другом сетевом адаптере, то просто прописывается маршрут для сети 10.1.2.0/24).
• На физическом сервере было выполнено всё то же самое, но только для сети 10.1.2.0/24.
• Готово! Теперь между серверами есть внутренняя изолированная сеть, а трафик ходит через сетевое ядро.

^[5]
Упрощенная схема организации внутренней сети между физическими и виртуальными серверами для данного примера.

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

Схема достаточно простая, и, главное, универсальная. Никаких костылей ни в облаке, ни в ядре городить не пришлось.

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

В случае же, если физическое оборудование находится в другом дата-центре, этот вопрос тоже решаем. В этом случае со стороны облака ничего не меняется: всё тот же дополнительный сетевой адаптер, VLAN, подсесть. А вот со стороны физического оборудования нужно дополнительно организовывать канал. Можно организовать MPLS-канал через наших партнёров-операторов связи, или самостоятельно договориться с оператором связи о MPLS-канале до нашей точки присутствия.

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

Как видно, если подойти к решению комплексно, то можно реализовать любое пожелание клиента. Естественно, что один из главных вопросов который возникнет, это стоимость того или иного решения. Но это уже отдельный разговор. ;)

Автор: 3los