Как устроено облако VMware внутри. Сети и сетевая связанность

Сегодня мы поговорим о том, как живет «облако» VMware на стороне корпоративного IaaS-провайдера, что кроется в особенностях его реализации и какие сервисы могут оставаться вне поля зрения клиента. Предлагаем рассмотреть важные детали, вынеся на повестку дня следующие вопросы:

  • Как можно организовать сеть внутри облака?
  • Какие сетевые сервисы предлагают корпоративные IaaS-провайдеры?
  • Как реализуется сетевая безопасность облака?

Для построения полноценного сервис-ориентированного и адаптивного под задачи любой сложности облака VMware используется набор продуктов VMware vCloud Suite, или сокращенно vCS. Из всего набора продуктов VMware vCloud Suite рассмотрим ключевые, с помощью которых можно построить облако, организовать внутри него сети, гарантировать должный уровень безопасности и обеспечить эффективное управление облачной площадкой.

vsphere.png

Поскольку речь идет об облаке на базе VMware, предлагаем вспомнить особенности платформы виртуализации VMware vSphere 5.5, которая обеспечивает следующую функциональность:

  • динамическую балансировку нагрузки на серверы и системы хранения данных с достижением оптимальной производительности для приложений заказчиков;
  • высокую доступность с возможностью автоматического перезапуска виртуальных серверов при сбое отдельного аппаратного сервера;
  • изоляцию виртуальных инфраструктур различных заказчиков друг от друга на сетевом уровне (по уровню безопасности такая изоляция практически не уступает физической).

Таким образом, vSphere можно назвать фундаментом облака, без которого, как и в строительстве, нельзя возвести здание.

А для обеспечения безопасности и устойчивости к различным внутренним и внешним угрозам необходим набор продуктов vCloud Networking and Security, который аналогично можно сопоставить с перекрытиями и стенами здания.
vCloud Director, входящий в состав vCloud Suite, представляет собой главный компонент, являющийся мощным инструментом управления облаком.
Для самостоятельного управления виртуальной инфраструктурой клиенту предоставляется доступ к персональному порталу самообслуживания. В облаке VMware такой портал, как правило, реализуется на основе vCloud Director и с помощью веб-интерфейса позволяет управлять следующими компонентами:

 

  • Отдельными виртуальными машинами: создание, изменение выделенных аппаратных ресурсов, доступ к консоли виртуальной машины и другие операции.
  • Виртуальным приложением vApp — комплексом взаимозависимых виртуальных машин, необходимых для реализации одного сервиса (например, серверы баз данных, серверы приложений и терминальные серверы для трехзвенной архитектуры).
  • Виртуальными сетями и сетевым взаимодействием между машинами.
    Графический интерфейс позволяет визуализировать сетевые соединения, благодаря чему процесс становится аналогичным простой перекоммутации кабелей на физической инфраструктуре.

Сочетание vSphere с набором продуктов vCloud Networking and Security дает возможность сформировать так называемую облачную ячейку. Облачная ячейка представляет собой базовый набор ресурсов, который может быть «разрезан» на более мелкие составляющие. На их основе в дальнейшем и создаются различные по масштабу независимые друг от друга облака. Количество облаков при этом зависит от реально доступных вычислительных ресурсов.

Как организовать сеть внутри облака VMware?

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

  • независимостью от оборудования;
  • возможностью быстрой инициализации;
  • возможностью развертывания без прерывания работы систем.

Сеть внутри облака VMware может быть организована с использованием различных сценариев. Остановимся подробно на каждом из них.

Построение внешней маршрутизируемой подсети с количеством IPv4/IPv6-адресов согласно требованиям клиента.

Такие типы внешних маршрутизируемых сетей часто именуют External networks, которые представляют собой, по сути, вход и выход во внешний мир. Например, выход в Интернет или доступ к этой сети извне посредством технологий организации удаленного доступа.

Пример фрагмента внешней маршрутизируемой сети компании «ИТ-ГРАД» Рисунок 1. Пример фрагмента внешней маршрутизируемой сети компании «ИТ-ГРАД»

Для создания внешней сети в облаке администратор vSphere создает отдельную группу портов с необходимыми параметрами. При формировании сетевого сегмента важно корректно указать шлюз, параметры одного или нескольких DNS-серверов (о DNS более подробно будет рассказано ниже), а также определить диапазон IP-адресов с соответствующей маской подсети. Каждая сеть должна иметь свое наименование, поэтому при настройке задается ее имя и описание. Если в сегменте планируется выдача публичных (белых) адресов, то для этого создаются соответствующие правила в таблице маршрутизации на маршрутизаторе.

Давайте рассмотрим пример внешней маршрутизируемой сети в облаке на примере компании «ИТ-ГРАД», обратившись к рисунку 1. Здесь мы видим наличие так называемых публичных хостов, доступ к которым извне должен быть организован на постоянной основе с доступностью 24/7.

К сайту компании www.it-grad.ru могут обращаться любые пользователи из любой точки мира. В том числе сотрудники самой компании могут работать удаленно, подключаясь к терминальным серверам, где установлены необходимые для работы приложения, а также использовать Outlook Web Access для доступа к почте через web. Как правило, публичные серверы, доступ к которым организуется извне, отделяют от внутренних ресурсов.

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

Построение изолированной подсети для связи между виртуальными машинами

pic1.jpg Рисунок 2. Фрагмент изолированной подсети в облаке

Помимо внешних маршрутизируемых сетей в облаке могут присутствовать изолированные подсети для связи межу виртуальными машинами. Необходимость таких сетей может быть обусловлена определенными задачами. Давайте рассмотрим пример на рисунке 2.
Согласно рисунку 2, в компании ИТ-ГРАД есть два контроллера домена (VM1 и VM2), которые должны выполнять репликацию баз данных активного каталога. Это необходимо для поддержания баз в актуальном состоянии. Кроме того, дополнительно развернут DNS-сервер (VM3), который хранит вторичную зону it-grad.ru. Серверы VM2 и VM3 должны взаимодействовать друг с другом для выполнения трансфера зоны.

Если на машине VM2 меняется содержимое основной зоны it-grad.ru, все изменения, связанные с зоной, должны быть переданы на машину VM3. Доступ к сети internal network 1 ограничен извне. В терминологии VMware такой тип сети именуется как сеть организации или Organizations Network, внутри которой ходит ее внутренний трафик.

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

Данный тип организации подсетей является наиболее распространенным и часто встречающимся на практике. Как правило, в большинстве компаний, которые переносят свою ИТ-инфраструктуру в облако, имеются ресурсы, доступ к которым необходим извне. А также имеется набор критичных сервисов и приложений, которые должны быть изолированы и защищены от внешнего доступа. Именно они помещаются в изолированный сегмент. Также бывают сценарии, когда таких изолированных сетей должно быть несколько. При этом подключать виртуальные приложения можно напрямую как часть сегмента организации или через виртуальный шлюз Edge Gateway с возможностью использования NAT.

Фрагмент облака с двумя изолированными сетями и сетью публичного доступа Рисунок 3. Фрагмент облака с двумя изолированными сетями и сетью публичного доступа

На рисунке 3 мы видим фрагмент облака, в котором представлены две внутренние подсети и одна публичная, каждая из которых отделена друг от друга. В этом сценарии реализован комбинированный подход.

Изолированная сеть Internal Network 1 рассматривалась ранее более подробно. Напомним, что в ней находятся контроллеры домена, выполняющие репликацию баз активного каталога, а также реализован трансфер зоны с сервером DNS и одним из контроллеров домена. В изолированной сети Internal network 2 находятся две виртуальные машины, выполняющие роль распределенной файловой системы. Между данными серверами выполняется репликация изменений файлов в каталогах Marketing и HR. Доступ к двум рассмотренным подсетям извне ограничен. Подсеть Public network 1, в свою очередь, является публичной, доступной из Интернета.

DMZ в виртуальной среде

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

Отличается ли DMZ в физической реализации от реализации ее в виртуальной среде публичного облака в модели IaaS?

Разберем все по порядку и начнем, пожалуй, с определения, важного для понимания сути вопроса.

Итак, демилитаризованная зона (DMZ) — это сегмент сети, содержащий общедоступные сервисы и отделяющий их от внутренних, частных сетей организации.

На рисунке 3 сеть Public network 1, по сути, можно назвать демилитаризованной зоной.

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

Априори такой тип организации сети, по сравнению с внутренними изолированными сетями, считается более уязвимым в плане безопасности. Поскольку обращение к сегменту DMZ происходит из незащищенной сети Интернет, возможны попытки организации различных видов атак.

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

Возможен сценарий использования Front End / Back End брандмауэра. Пример такой схемы представлен на рисунке 4.

pic2.png

Рисунок 4. DMZ в сценарии Front End / Back End брандмауэра

В таком сценарии мы видим наличие двух фаерволов на границе каждой сети. При попытке атаки зоны DMZ из публичной, небезопасной сети Интернет, злоумышленник на своем пути встречает «защиту» в виде пограничного фаервола.

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

Более простым сценарием с DMZ является наличие одного брандмауэра, как продемонстрировано на рисунке 5. Такая модель носит название трехногой топологии и очень часто встречается на практике в силу своей бюджетности. Такая топология считается менее безопасной.

pic3.png Рисунок 5. DMZ в сценарии «трехногой» конфигурации

А как дело обстоит в облаке?

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

pic4.png Рисунок 6. Пример DMZ в облаке

Возможные сценарии организации DMZ в облаке:

  • Каждая зона DMZ физически отделена от остальных зон и содержит набор виртуальных машин. Такая конфигурация DMZ напоминает физическую конфигурацию, где разделение сетей происходит на физическом уровне, а не в инфраструктуре виртуализации.
  • Различные зоны разделены виртуально, но физически находятся на одном ESX-хосте. Каждая зона DMZ использует отдельный виртуальный свитч, гарантируя, что узлы, подключенные к виртуальному свитчу, отделены от хостов в других зонах. Взаимодействие между различными зонами DMZ происходит через физическую сеть. При такой конфигурации необходимо проверять, в правильной ли сети находится та или иная виртуальная машина.
  • Зоны DMZ полностью виртуализированы и при корректной конфигурации отделены друг от друга.

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

Сетевые сервисы IaaS-провайдеров

На сегодняшний день существует огромное количество различных сервисов, без которых трудно представить полноценную ИТ-инфраструктуру. Зачастую конечному пользователю виден только результат, но как же выглядит «закулисная жизнь» особо важных сервисов, какие функции они выполняют и что обычно предлагает облачный IaaS-провайдер?

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

Разрешение имен — это процесс, посредством которого происходит преобразование или, иначе говоря, сопоставление имен в IP-адреса. За данный процесс отвечают службы DNS и WINS, однако различные сервисы имеют определенные отличия в работе.

В чем же разница? Ответ на поставленный вопрос следует начать с особенностей типов имен, поскольку в этом пункте чаще всего возникает путаница. Имена делятся на две категории: HOSTS-имена и NETBIOS-имена, характеристики которых представлены в таблице 1.

Типы имен

HOSTS-имена NETBIOS-имена
  • Используются как в локальных сетях, так и в Internet.
  • Могут содержать до 255 символов.
  • Могут содержать разделители и специальные символы.
  • Могут состоять из нескольких частей, например mail.it-grad.ru.
  • Имена разрешаются в IP-адреса посредством службы DNS.
  • Используются только в локальных сетях.
  • Могут содержать максимум 16 символов.
  • Являются «плоскими» именами, не могут содержать разделителей. Пример NETBIOS-имени: server1.
  • Имена разрешаются в IP-адреса посредством службы WINS.

Таблица 1. Типы имен: HOSTS и NETBIOS

За разрешение HOSTS-имен в IP-адреса отвечает служба DNS. Данный сервис довольно часто разворачивается в облаке IaaS-провайдера.

Служба DNS

DNS (Domain Name System) представляет собой систему доменных имен, с помощью которой преобразуются символьные имена в IP-адреса, а также по IP-адресу извлекается информация об имени сетевого устройства.

Без этой службы сложно представить как существование Интернета, так и любой сети в целом. И не важно, реализована она в облаке на стороне хостинг-провайдера или развернута в рамках любого существующего предприятия. Данная служба давно зарекомендовала себя как важный и необходимый элемент, облегчающий жизнь как администраторам, так и обычным пользователям.

Технологию доменных имен можно сравнить с адресной книгой в мобильном телефоне. Ведь каждый раз, когда мы звоним тому или иному человеку, мы находим его в списке контактов и совершаем звонок. По такому же принципу работает служба DNS: когда пользователь обращается к какому-либо ресурсу по имени, например www.it-grad.ru, это имя сопоставляется с уникальным адресом сервера, на котором находится запрашиваемый ресурс, и перенаправляется на соответствующий узел, после чего пользователь видит открывшуюся страницу на экране.

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

Служба WINS

За разрешение NETBIOS-имен в IP-адреса отвечает служба WINS. При необходимости данный сервис разворачивается в облаке IaaS-провайдера, который наделен следующими особенностями.

WINS представляет собой службу регистрации и разрешения имен компьютеров, являясь аналогом DNS. Однако служба WINS сопоставляет только NetBIOS-имена сетевых устройств с их IP-адресами.

Если в облаке развернуть WINS-сервер, конечные пользователи могут обращаться к сетевым ресурсам, используя для этого короткие имена вместо запоминания IP-адресов. Более того, различные программы, старые операционные системы, которые могут работать только с NETBIOS-именами, и службы, установленные на виртуальных машинах, компьютерах и других устройствах, могут выполнять запросы NETBIOS-имен к WINS-серверу для разрешения имен в IP-адреса.

Служба DHCP

Искусством управления IP-адресами может похвастать всеми известная служба динамической конфигурации узлов в сети, а именно служба DHCP. С помощью данного сервиса виртуальные машины в облаке либо физические компьютеры автоматически получают IP-адреса и другие параметры, необходимые для работы в сети, организованной на стороне корпоративного IaaS-провайдера.

За счет реализованной модели клиент-серверного взаимодействия узел/компьютер в сети формирует запрос на получение IP-адреса, отправляя его доступному в сети DHCP-серверу. IP-адреса, выданные службой DHCP, являются динамическими. При необходимости внесения централизованных изменений в параметры IP сделать это можно централизованно на стороне сервера DHCP.

Конфигурация IP

Динамическая конфигурация (DHCP) Статическая конфигурация
  • Напомним, что динамическая конфигурация осуществляется посредством службы DHCP и происходит автоматически, совершенно прозрачно со стороны конечного пользователя.
  • Если на стороне DHCP-сервера выполнить централизованное изменение параметров, они автоматически применятся ко всем сетевым устройствам, которые с ним взаимодействуют.
  • Гибкость конфигурации. При переносе устройства из одной сети в другую происходит автоматическая перенастройка параметров IP.
  • Статическая конфигурация выполняется исключительно вручную.
  • Все изменения, связанные с IP-конфигурацией, необходимо выполнять на каждом узле.
  • Статическая конфигурация порождает излишние административные издержки.
  • Чреваты ошибки при конфигурации, человеческий фактор.
  • Отсутствие гибкости. При переносе устройства из одной сети в другую не происходит автоматической реконфигурации. Нужна ручная перенастройка.

Таблица 2. Конфигурация IP-адресов, статическая и динамическая

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

Важно: в облаке VMware функцию DHCP может выполнять vShield.

Помимо процесса разрешения имен и выдачи IP-адресов в «жизни» облака существуют и другие задачи, такие как преобразование сетевых адресов.

NAT

NAT (Network Address Translation) — это технология преобразования сетевых адресов.

pic5.png Рисунок 7. Фрагмент облака с использованием NAT

Для простоты понимания рассмотрим фрагмент облака, в котором используется технология NAT. На рисунке 7 в облаке находятся виртуальные машины, выполняющие роль почтового сервера (VM1), веб-сервера (VM2) и двух терминальных серверов(VM3 и VM4), а также развернут NAT на базе VMware vShield. Рассматриваемая сеть является публичной, и доступ к ресурсам должен быть предоставлен извне. Однако резервировать белые адреса под каждый хост не стали. Виртуальные машины внутри облака используют «приватные» адреса из подсети 192.168.1.0. А настроенный NAT имеет два интерфейса, один из которых смотрит во внутреннюю сеть (IP: 192.168.1.5), а другой — во внешнюю сеть Интернет (IP: 10.10.0.11).
Таким образом, если извне приходит запрос на доступ к почте https://mail.it-grad.ru или на доступ к сайту www.it-grad.ru либо происходит подключение к терминальным серверам tsg1.it-grad.ru, tsg2.it-grad.ru, все указанные имена «разрешаются» в белый IP-адрес NAT-сервера 10.10.0.11. А далее пакет отправляется через внутренний интерфейс к соответствующему серверу согласно запросу. При этом внутренние адреса хостов остаются скрытыми для «внешних глаз».

Важно: в облаке VMware функцию трансляции сетевых адресов(NAT) может выполнять vShield.

Балансировка сетевой нагрузки для веб-серверов (NLB)

Network Load Balancing (NLB) представляет собой средство балансировки сетевой нагрузки, повышая надежность и масштабируемость серверных приложений Интернета, используемых на веб-серверах.

Предположим, некая компания, продающая детали и комплектующие для автомобилей, перенесла свой сайт в облако хостинг-провайдера. К сайту обращается огромное количество пользователей, формируя запросы на покупку тех или иных деталей. При возрастании количества пользователей было решено организовать несколько веб-серверов с возможностью распределения нагрузки между ними (Web1, Web2, Web3) в случае обращения к ресурсу https:\\www.automobile.com. Достичь такого результата можно с помощью технологии балансировки сетевой нагрузки NLB.
В рассматриваемом примере на каждом узле Web1, Web2, Web3 выполняется отдельная копия заданного приложения для web. NLB распределяет входящие клиентские запросы между этими узлами.

Как включить NLB в облаке?

Рассмотрим наиболее часто применяемые варианты:

  • Вариант 1. Использование NLB-кластера на базе ОС Windows Server.
    В таком сценарии на каждом узле Web1, Web2, Web3 конфигурируется NLB, при этом все озвученные виртуальные машины объединяются в так называемый кластер NLB. При этом все входящие запросы распределяются между узлами в кластере. NLB позволяет обращаться ко всем компьютерам в кластере по одному и тому же IP-адресу кластера и поддерживает набор уникальных выделенных IP-адресов для каждого узла. Для приложений с балансировкой нагрузки при сбое на узле или его отключении нагрузка автоматически перераспределяется между работающими виртуальными машинами в облаке.
  • Вариант 2. В облаке VMware балансировку сетевой нагрузки для веб-серверов может выполнять vShield.

Сетевая безопасность облака

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

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

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

Интерфейс управления интегрирован с vCloud Director, что позволяет заказчику самостоятельно управлять межсетевым экраном из единого веб-интерфейса.
vShield может реализовать одновременно несколько функций. О некоторых из них в данной статье мы уже упоминали:

  • межсетевое экранирование;
  • трансляция сетевых адресов (NAT);
  • организация Site-to-site VPN-туннелей;
  • статическая маршрутизация;
  • DHCP-сервер;
  • балансировка сетевой нагрузки для веб-серверов.

Однако предложением использовать только vShield в облаке корпоративный IaaS-провайдер, как правило, не ограничивается. Клиент вправе выбирать. По выбору заказчика, исходя из требуемой функциональности, в качестве межсетевого экрана может быть самостоятельно использовано любое программное решение, поддерживаемое в среде VMware. Примером такого решения является облачный межсетевой экран Cisco ASA 1000V.

Напомним, что Cisco ASA 1000V представляет собой межсетевой экран для облачных вычислений, в котором используется базовая технология Adaptive Security Appliance (ASA), оптимизированная для надежной защиты многопользовательской виртуальной и облачной инфраструктуры.

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

Опубликовано 06.02.2015 19:36:00 автором E.Yudina в разделе Сети, в разделе Функциональность

/* */

Посетите наш сайт!

IaaS облако IT-GRAD

Подпишитесь на блог!

IaaS для бизнеса по кирпичикам