Сегодня мы поговорим о том, как живет «облако» VMware на стороне корпоративного IaaS-провайдера, что кроется в особенностях его реализации и какие сервисы могут оставаться вне поля зрения клиента. Предлагаем рассмотреть важные детали, вынеся на повестку дня следующие вопросы: Как можно организовать сеть внутри облака? Какие сетевые сервисы предлагают корпоративные IaaS-провайдеры? Как реализуется сетевая безопасность облака? Для построения полноценного сервис-ориентированного и адаптивного под задачи любой сложности облака VMware используется набор продуктов VMware vCloud Suite, или сокращенно vCS. Из всего набора продуктов VMware vCloud Suite рассмотрим ключевые, с помощью которых можно построить облако, организовать внутри него сети, гарантировать должный уровень безопасности и обеспечить эффективное управление облачной площадкой. Поскольку речь идет об облаке на базе 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-адреса, в таком случае потребуется конфигурация брандмауэра и настройка правил публикации каждого из серверов, расположенных в этой внешней сети. Построение изолированной подсети для связи между виртуальными машинами Рисунок 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? Разберем все по порядку и начнем, пожалуй, с определения, важного для понимания сути вопроса. В чем же разница? Ответ на поставленный вопрос следует начать с особенностей типов имен, поскольку в этом пункте чаще всего возникает путаница. Имена делятся на две категории: HOSTS-имена и NETBIOS-имена, характеристики которых представлены в таблице 1. Типы имен HOSTS-имена Используются как в локальных сетях, так и в Internet. Могут содержать до 255 символов. Могут содержать разделители и специальные символы. Могут состоять из нескольких частей, например mail.it-grad.ru. Имена разрешаются в IP-адреса посредством службы DNS. NETBIOS-имена Используются только в локальных сетях. Могут содержать максимум 16 символов. Являются «плоскими» именами, не могут содержать разделителей. Пример NETBIOS-имени: server1. Имена разрешаются в IP-адреса посредством службы WINS. За разрешение HOSTS-имен в IP-адреса отвечает служба DNS. Данный сервис довольно часто разворачивается в облаке IaaS-провайдера. Служба DNS Без этой службы сложно представить как существование Интернета, так и любой сети в целом. И не важно, реализована она в облаке на стороне хостинг-провайдера или развернута в рамках любого существующего предприятия. Данная служба давно зарекомендовала себя как важный и необходимый элемент, облегчающий жизнь как администраторам, так и обычным пользователям. Технологию доменных имен можно сравнить с адресной книгой в мобильном телефоне. Ведь каждый раз, когда мы звоним тому или иному человеку, мы находим его в списке контактов и совершаем звонок. По такому же принципу работает служба 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-конфигурацией, необходимо выполнять на каждом узле. Статическая конфигурация порождает излишние административные издержки. Чреваты ошибки при конфигурации, человеческий фактор. Отсутствие гибкости. При переносе устройства из одной сети в другую не происходит автоматической реконфигурации. Нужна ручная перенастройка. Конечно, далеко не всем виртуальным машинам в облаке присваиваются динамические IP-адреса. Зачастую определенным серверам, выполняющим различные роли, необходима статическая конфигурация IP, которую администратор облака настраивает вручную. Помимо процесса разрешения имен и выдачи IP-адресов в «жизни» облака существуют и другие задачи, такие как преобразование сетевых адресов. NAT Рисунок 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. А далее пакет отправляется через внутренний интерфейс к соответствующему серверу согласно запросу. При этом внутренние адреса хостов остаются скрытыми для «внешних глаз». Балансировка сетевой нагрузки для веб-серверов (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. Также при необходимости использования выделенных аппаратных решений корпоративные IaaS-провайдеры, как правило, предоставляют клиентам возможность размещения собственных сетевых устройств в том же дата-центре, где размещается облачная платформа. Опубликовано 06.02.2015 19:36:00 автором E.Yudina Ссылка на источник.
