Как стать автором
Обновить
98.61
CloudMTS
Виртуальная инфраструктура IaaS

Организация сети в облаке и сетевая связность с облаком

Время на прочтение 3 мин
Количество просмотров 13K
Организация сети в облаке и сетевая связность с облаком

Здравствуйте, дорогие любители cloud computing.

Сегодня меня заставили написать пост о сетях – о тех сетях, что используются в нашем облаке. Я изо всех сил постараюсь объяснить, как тут все организовано, а также расскажу о том, как можно подключиться к нашему облаку.



Итак, для начала: если вы берете виртуальную машину у нас в облаке, то автоматически вам выдается внешняя маршрутизируемая сеть с маской /29. Это значит, что у вас сразу появляется не два, не три, не четыре, а целых 5 БЕЛЫХ АДРЕСОВ! Один адрес остается за нами для использования его на маршрутизаторе. А вот дальше начинается кастомизация под клиента. Это значит, что мы можем:

  1. выдать внешнюю маршрутизируемую сеть с бόльшим количеством адресов
  2. выдать изолированную сеть для связи между виртуальными машинами
  3. комбинировать различные варианты предоставления этих сетей
  • выдать одновременно внутреннюю и внешнюю сети
  • выдать 2 и более внешних сетей или внутренних сетей.

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

Случай 1 (легкий):
Вы приобретаете услугу по размещению в облаке своей виртуальной машины. Мы создаем пул ресурсов и выделяем вам сеть с 5 адресами. Вы настраиваете виртуальную машину в соответствии с полученными инструкциями и (ТАДАМ!) она работает (кто бы сомневался?).

image

image

Вам захотелось сэкономить и вы вместо того, чтобы взять еще одну машину для нового сайта, просто повесили алиасом еще один адрес. И (ТАДАМ!) – он тоже работает.

image


Случай 2 (еще проще, потому как мне еще не встречался):
Вы – разработчик. Причем такой разработчик, которому удобно работать в консоли VMware. Вам нужно организовать тестовый стенд, чтобы проверить очередной HelloWorld-проект. Отлично! Загружаем свои машины в облако (которое уже арендовано), подключаем их к выделенной внутренней сети, включаем и проверяем все, что хотим. Бонус: можно использовать любую адресацию внутри такого VLANа.

image

image

Случай 3 (запарный, но не сильно, т.к. требует примерно на 5 кликов мышкой больше, чем в 1 случае):
Вы пошли на поводу у «системы» и решили не выбиваться из общей массы тех, кто пользуется frontend/backend топологией. Например, у вас есть web-сервер с каким-то важным контентом и база данных, к которой этот самый сервер обращается. База данных должна быть недоступна со стороны интернета, потому как он наводнен всякими маргиналами, пытающимися эту самую базу украсть / взломать / допишите сами. Самый простой вариант защиты – оградить ее (базу, сервер баз данных) от общения с беснующимся Интернетом на 2 уровне сетевой модели OSI. И это тоже по силам нам. Мы выдаем 2 сети: богатую (целых 5 IP адресов) внешнюю сеть и безразмерную внутреннюю. WEB-сервер мы подключаем к этим двум сетям разными адаптерами (ДА, ТАКОЕ ТОЖЕ ВОЗМОЖНО!), сервер баз данных подключаем только ко внутренней сети. Получится примерно такая топология:

Организация сети в облаке: изолированный VLAN

image

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

Случай 4:
Есть у VMware продукт под названием vShield manager. Вкратце: это обычный firewall / router, реализованный в виде виртуальной машины. Помимо всего этого – его интерфейс интегрируется с vCloud и управлять настройками (правилами, маршрутизацией, IPSec и т.п. вещами) можно прямо из облака. Чем-то напоминает случай 3. Однако теперь вы сможете добавлять правила NAT и настраивать политики firewall под себя из графического интерфейса:

Настройка политик firewall из графического интерфейса

Случай 4a:
Этот случай очень напоминает предыдущий вариант, но в отличие от него в качестве маршрутизатора / брандмауэра используется не vShield, а другое решение (например MS TMG, Vyatta, либо специальным образом настроенный дистрибутив с opensource системой). Т.е. мы так же выделяем организации в облаке 2 сети: внутреннюю и внешнюю, и подключаем их к этому маршрутизатору.

Теперь я расскажу немного о том, как можно настроить безопасные подключения к своим облакам. Как вы уже догадались – существует 2 варианта подключения: на уровне 2 модели OSI и на уровне 3 той же модели.

Подключение на 2 уровне: вы либо тянете провод в наш ЦОД, либо арендуете VLAN у своего провайдера, который представлен в нашем ЦОДе. Мы пробрасываем этот линк в ваше облако и вуаля.

Подключение на 3 уровне осуществляется через общедоступную сеть Интернет при помощи туннелирования. Это самый простой способ. Реализуется он также на базе vShield, либо любого другого специализированного дистрибутива. vShiled предоставляет только IPSec туннели. Ниже пример действующего туннеля одного из наших клиентов:

image

Теперь вы знаете, как работают сети в облаке ИТ-ГРАД; как подключиться к своему облаку и что для этого нужно. Если вы реально заинтересованы – задавайте свои вопросы, я постараюсь помочь.
Теги:
Хабы:
+4
Комментарии 2
Комментарии Комментарии 2

Публикации

Информация

Сайт
cloud.mts.ru
Дата регистрации
Дата основания
Численность
201–500 человек
Местоположение
Россия