VMware vCloud Suite. Собираем облако

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

Введение

Как у же говорилось ранее, в состав vCloud Suite входит шесть основных продуктов;

  • vSphere c редакцией Enterprise Plus — платформа виртуализации являющаяся вычислительной основой,

  • vCenter Site Recovery Manager — решение, выполняющее автоматическое аварийное восстановление и тестирование критических ВМ и приложений на резервной площадке,

  • vCloud Networking and Security — набор продуктов для всестороннего контроля сети виртуальной инфраструктуры. Включает в себя;

    • vShield Endpoint — это прослойка работающая поверх VMsafe API. Позволяет сторонним производителям антивирусов интегрироваться с инфраструктурой VMware vSphere.

    • vShield App and Data Security — так же использует VMsafe и предназначен для внутренней защиты дата-центра. Это своего рода распределенный виртуальный межсетевой экран который контролирует трафик ВМ на уровне гипервизора а так же в некотором роде выполняет функции DLP-системы. Специальные правила позволяют разграничить сетевое взаимодействие между ВМ практически на любом уровне а администратор получает возможность мониторинга их взаимодействия.

    • vShield Edge — а это уже решение для защиты дата-центра от внешних напастей. Это своего рода защищенный шлюз во внешний мир. Здесь и межсетевой экран и балансировщик нагрузки, VPN, DHCP, NAT и прочее.

    • vSheild Managerсерверуправленияпродуктами vCloud Networking and Security. Распространяется в виде Virtual Appliance и включает в себя все три выше описанных модуля. При необходимости установка\удаление того или иного компонента производится из vSheild Manager.

  • vCloud Automation Center — средство автоматизации различных задач для крупных инфраструктур,

  • vCenter Operations Manager Suite — средства мониторинга и диагностики динамической виртуальной среды,

  • vCloud Director — средство управления облачной инфраструктурой. Дополнительный уровень абстракции над ресурсами vSphere делающий работу с ними удобной для обычного пользователя.

Примечание: В пред идущей статье, кроме указанных выше продуктов, были упомянуты такие решения как vCloud Connector и vFabric Application Director. К сожалению, хоть они и имеют отношению к vCloud Suite но в его состав не входят. Это моя ошибка, прошу прощения.

Самыми базовыми из представленных выше продуктов являются vSphere, vSheild(из состава vCloud Networking and Security) и vCD. Это своего рода костяк облака. В этой статье мы поговорим про особенности их работы и взаимодействия а так же настроим эту связку на нормальную работу. Фактически к концу статьи у нас будет готовое, рабочее облако.
В последующих статьях будут задействованы дополнительные продукты расширяющие функционал облака а так же рассмотрены более подробно некоторые технические аспекты. Так как все читатели имеют совершенно разный уровень знакомства с платформами VMware, некоторые продукты и механизмы будут описываться через мерно подробно что бы понятно было всем.

План работ

Чтобы упорядочить материал и дать более обзорное(пошаговое) представление о том что уже должно быть и что еще предстоит проделать я предлагаю следующий план;

  1. Развертывание базовой платформы vSphere (ESXi + vCenter).

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

  1. Подключение vSheild Manager к vCenter.

2.1 Импорт подготовленной виртуальной машины(Virtual Appliance) vSheild Manager на один из ESXi-хостов,
2.2 Настройка сети vSheild Manager и подключение к vCenter.

Эта работа так же должна уже быть проделана. В помощь на этом шаге будут даны ссылки.

  1. Развертывание vCD в виртуальной машине на одном из ESXi-хостов.

Этот пункт подробно рассматривался в первой части цикла.

  1. Создание первой ячейки (vCloud Cell).

4.1Подключение vCenter и vSheild Manager к vCD

Пункт будет подробно рассмотрен в этой статье.

  1. Уровни абстракции или за кулисами облака.

5.1 Создание корневого дата центра(Provide VDC),
5.2 Настройка сетей различных типов,
5.3 Создание организации (Organization),
5.4 Создание виртуального дата-центра организации(Organization VDC),
5.5 Создание vApp, 5.6 Создание каталога.

Данные пункты будут развернуто освещены в этой статье.

Подключение vSheild Manager

По сути, если vSphere используется для виртуализации серверного парка обслуживающего внутренних пользователей то необходимость в vSheild в большинстве случаев, едва ли оправданна. Для разграничения трафика различных серверов можно использовать классические VLAN-ы. А те несколько сервисов что доступны из вне могут быть перекрыты корпоративным или встроенным в ОС межсетевым экраном.
Но, при внедрении vCD, без vSheild не обойтись. Потенциально, vCD может обслуживать несколько совершенно различных организаций, по этому для более надежной изоляции и контроля ВМ одной организации от другой необходим vShield App and Data Security. Тоже и с доступом ВМ в Интернет, здесь может очень пригодится vSheild Edge Gateway о котором подробнее ниже.
В общем, наличие этого продукта обязательно и прежде чем двинуться дальше он должен быть внедрен в существующую инфраструктуру vSphere.
Для этого необходимо развернуть Virtual Appliance от VMware и выполнить настройку сети. Процедура довольно простая и дабы не описывать ее здесь предлагаю ознакомиться с ней тут.

Последним действием будет подключение vSheild к vCenter, более нечего делать не нужно, в дальнейшем при необходимости все будет выполняться автоматически.

Первая ячейка(vCloud Cell)

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

Связка этих компонентов во главе с vCD образуют в терминологии VMware облачную ячейку(Cloud Cell). Не взирая на число входящих в эту ячейку компонентов, это своего рода единая, самодостаточная, высокоурожайная сущность — но еще не облако. Это базовый набор ресурсов который в дальнейшем будет «разрезан» на меньшие кусочки на основе которых будут созданы различные по масштабу, независимые облака. Количество облаков, естественно зависит от реально доступных вычислительных ресурсов ячейки.

На уровне ячеек наблюдается интересная гибкость. Под управлением одного vCD может работать несколько отдельных инфраструктур vSphere с различными хранилищами и vSheild и все это будет одна единственная ячейка. Возможен и другой вариант, когда каждая из нескольких «сфер» подключена к разным vCD, при этом получается несколько ячеек. Такой вариант больше подходит в случаях когда несколько инфраструктур vSphere разнесены географически но при этом являются частями единой, распределенной облачной инфраструктуры.

Подключить vCenter и vSheild Manager довольно легко. Это самый первый шаг конфигурирования и выполняется он сразу же после входа в веб-консоль vCD на странице Home с помощью мастера Attach a vCenter. Мастер запросит лишь учетные данные администраторов vCenter и vSheild и на этом пожалуй все, можно двигаться дальше.

Виртуальные дата-центры или за кулисами облака

Наилучшим помощником в понимании этого материала вам послужит рисунок №1 на котором изображена вся иерархическая архитектура от нисших базовых объектов, до абстрактных высокоуровневых сущностей.

vmware_vcloud_suiteРис №1 Иерархия объектов vCD

Конечные облака, как уже говорилось создаются на базе ресурсов vSphere. Для того что бы определить сколько и каких ресурсов может использовать vCD предназначены специальные Provider VDCs(виртуальный дата-центр поставщика).

Provider VDCs — это набор ресурсов(процессор, память, датастор) отданный во владение vCD.
На более низком уровне, это стандартный пул ресурсов vSphere. Установка лимитов на этот пул прерогатива администратора. Лимитирование имеет смысл, когда под облачные нужды планируется отдать лишь часть вычислительных мощностей. В противном случае, в пуле ресурсов нет необходимости и создавая Provider VDC можно задействовать весь кластер vSphere.

Примечание: Создание пула ресурсов в vSphere становится возможным только при включенном DRS(Distributed Resource Scheduler)в параметрах кластера vCenter, даже если в его составе всего один узел.

Создаем первый Provider VDC

Задать параметры корневого дата-центра поможет мастер Create a Provider VDC. Это второй пункт на странице Home веб-интрфейса vCD.

На первом шаге необходимо указать имя и описания VDC а так же выбрать версию виртуального оборудования(Hardware Version) будущих ВМ. Максимальное поколение оборудования определяется в зависимости от версии ESXi. Если в кластере есть узлы с версией 4.x то придется оставить установленную по умолчанию версию 7. Соответственно для 5.0 наивысшее поколение 8, для 5.1 будет 9 и 10 для 5.5.
На втором шаге необходимо выбрать vCenter, пул ресурсов или кластер из которого будут выделены вычислительные ресурсы. Так же здесь необходимо указать внешнюю сеть(External Network) которой на данном этапе у вас еще нет по этому оставляем этот пункт без внимания до следующего раздела. Далее необходимо выбрать датастор и политику его использования(Storage Policies) если это vSAN. На этом создание Provider VDC заканчивается.

Примечание: Создавая Provider VDC на кластере целиком, пул ресурсов все равно создается, автоматически. Но, лимитов у него не будет. В будущем, при необходимости администратор может их установить.

Таких Provider VDC может быть множество. Тут все зависит от фантазии и потребностей. Например, если к vCD подключено несколько отдельных экземпляров vSphere то в один пул их ресурсы не как не объединить. Или же, может быть что один экземпляр vSphere разделен на пулы ресурсов на основе которых соответственно построены разные Provider VDC.

Концепция сетей vCD

Самое время вернуться к оставленному без внимания пункту External Network и подробно разобрать его предназначение.

Прежде чем поговорить и типах сети vCD стоит получить представление о таком компоненте облачной инфраструктуры как Edge Gateway краткое описание которого дано в начале статьи. Фактически это Virtual Appliance развертывание и управление которым осуществляется средствами vSheild Manager. Edge Gateway — выполняет роль шлюза и располагается между различными сегментами сети предоставляя такие возможности как;

  • Классический межсетевой экран,

  • DHCP-сервер,

  • VPN,

  • Балансировка нагрузки,

  • Трансляцию адресов(NAT),

  • Статическая маршрутизация.

Далее в этом разделе станет понятно его предназначение и способы использования.

Три базовых уровня сети

В инфраструктуре vCD существует три типа(уровня) сетей;

  • внешние сети(Externals network),

  • сети организации(Organizations Network),

  • сети vApp(сеть виртуальных приложений).

Примечание Рекомендую прямо сейчас обратиться к разделу «Концепция vApp» для понимания ниже следующего материала.

Все начинается с vApp так как именно здесь зарождается первый сетевой трафик. Обычно для каждого виртуального приложения создается собственный, изолированный сетевой сегмент. На уровне vSphere это отдельная группа портов, часто с уникальным VLAN id. Такой же принцип можно часто встретить во многих классических сетях, когда например контроллеры домена работают в одном сегменте а файловые сервера в другом и так далее. Настройки такой сети полностью во власти рядового пользователя(владельца) конкретного vApp.

Уровнем выше находится сеть организации(Organizations Network) в которой ходит ее внутренний трафик. Этот сегмент(их может быть несколько) под контролем администратора организации(Organization administrator). Если, vApp не является изолированным, что скорее всего, то оно подключается к сети организации для взаимодействия например с другими vApp. Здесь у администратора появляются варианты так как подключить виртуальное приложение можно напрямую(как часть сегмента организации)или же через виртуальный шлюз(Edge Gateway). В первом случае все прозрачно, во втором же возможны варианты, например NAT.

Следующим логическим уровнем являются внешние сети(Externals network). Этот сегмент инфраструктуры под контролем администратора vCD. По сути это выход(и он же вход) во внешний(относительно организации) мир, например в Интернет или на территорию заказчика по средствам VPN. К внешним сетям подключаются сети организаций и тут как и в случае с vApp есть варианты. Можно использовать Edge Gateway который будет как бронированная дверь для защиты организации а можно обойтись безе него и «выпустить» организацию на прямую. Так же, стоит отметить что подключение организации к внешней сети не является обязательным. В таком случае она будет изолированной от внешнего мира что может быть полезно например при тестировании.

Если заглянуть на уровень vSphere то все эти сети это обычные группы портов (Portgroup) виртуального коммутатора vSwitch, Distributed vSwitch или же Nexus 1000V часто отличающиеся лишь VLAN id и способом коммутации с физическими интерфейсами.

Создание внешней сети

В разделе Home, интерфейса vCD для этих целей служит мастер Create an external network помогающий выполнить настройку внешних сетевых сегментов.

Примечание: Прежде чем добавить новую внешнюю сеть vCD администратор vSphere должен создать для этих целей отдельную группу портов с нужными вам параметрами.

На первом шаге, необходимо выбрать vCenter и одну из доступных группу портов(Port group). Далее, нужно задать конфигурацию этого сегмента а именно указать шлюз, DNS-сервера, диапазон IP-адресов и маску подсети для автоматической настройки ВМ включенных в эту область. Имейте в виду что отказаться от подобной настройки или использовать вместо этого существующий DHCP-сервер нет возможности. Ну и наконец, последнее что остается придумать имя и описание для новой внешней сети.

Не опытному специалисту может показаться, что все очень просто но на самом деле это лишь вершина айсберга. Наиболее важные настройки выполняются на уровне виртуального коммутатора vSphere и пограничного маршрутизатора. Например, если ВМ в этом сегменте планируется выдавать публичные(белые) IP-адреса то должны быть соответствующие правила в таблице маршрутизации на вашем маршрутизаторе. Соответственно настроен должен быть и vSwitch а так же задан правильный VLAN(если применяется) в настройках порт группы. Все это сильно зависит от ваших задач и может потребовать привлечения дополнительного специалиста для правильной настройки сети.

Почти в облаках. Создание организации

Теперь когда vCD имеет некий набор ресурсов(Provider VDC) и настроенные сетевые сегменты самое время поговорить о наивысших сушностях облака — организациях(Organizations).
Organizations — это и есть те самые виртуальны облака(IaaS) в которых «живут» конечные пользователи\клиенты. По сути это совокупность ресурсов, пользователей а так же администраторов организации и правил ограничивающих их.

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

Создать новую организацию, поможет мастер Create a new organization в разделе Home интерфейса vCD.

На первом шаге указываем имя организации и здесь же видим как формируется URL по которому будет доступен портал самообслуживания. Далее следует определиться с параме
трами LDAP. Здесь я рекомендую ознакомиться с разделом «Учетные записи пользователей»дабы понимать о чем идет реч.

На следующем шаге можно создать локальных пользователей vCD для этой организации и назначить им желаемые роли. Рекомендуется создать хотя бы одного такого пользователя с ролью (Organization administrator) на случай если LDAP будет не доступен.

Далее необходимо настроить параметры совместного использования ресурсов(Sharing). Разрешать ли пользователям публиковать свои каталоги для других организаций и можно ли подписываться на каталоги из внешних облаков. Это еще одна из концепций vCD о которой подробнее будет ниже.

Далее следуют параметры SMTP-сервера для отправки различных уведомлений, а так же адреса получателей.

Ну и на конец, следуют различные квоты. Максимальное время работы vApp, максимальное число ВМ на пользователя, число одновременных подключений через консоль vCD а так же число интенсивных операций вывода\вывода. Здесь же устанавливаются параметры политики блокировки учетных записей при не удачных попытках авторизации.

Администратор организации, в дальнейшем может переопределить практически все из перечисленных параметров кроме настроек LDAP.

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

Виртуальные дата-центры организации

Пожалуй главным ограничителем является объем ресурсов доступных организации и всем ее пользователям соответственно. Определяется это администратором vCD путем выделения части ресурсов от одного из Provider VDC. Выделяемый организации пул ресурсов называется Organization VDC(виртуальный дата-центр организации). По сути это такой же пул vSphere который создается внутри родительского Provider VDC но уже с установленными лимитами.

Создание Organization VDC

Что бы выделить организации некоторые ресурсы необходимо ее выбрать и на панели действий нажать Allocate resources.

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

Тут стоит понимать, что технически выделение ресурсов производится на уровне пула vSphere c gjvjom. параметров Reservation, Limit и Shares.

Модели выделения ресурсов;

  • Allocation Pool — модель в которой присутствует понятие гарантированной резервации ресурсов, но отсутствует понятие лимита. То есть расти такой пул может пока не упрется в ресурсы Provider VDC.

  • Pay-As-You-Go — модель при которой отсутствует понятие резервации на уровне пула и так же могут отсутствовать какие либо ограничения. Создается иллюзия бесконечности ресурсов организации. А для каждой ВМ определяется гарантированный объем ресурсов которые она получит при запуске. При этом подсчет ресурсов ведется только во время работы ВМ.

  • Reservation Pool — модель при которой максимум и гарантированный минимум имеют одинаковоезначение. То есть гарантированный объем одновременно и является максимом.

Далее выберем датастор и указываем выделяемый организации максимальный объем и следом сетевой пул. Далее предлагается создать Edge Gateway, но в этой статье мы этого делать не будем. Ну и наконец указываем имя vDC.

Интерфейс консоли vCD(Рис №2) хорошо иллюстрирует иерархию ресурсов vCD.

vmware_vcloud_suiteРис №2 Обзор всех ресурсов vCD

Учетные записи пользователей

Так как неотъемлемой частью организации в том числе и виртуальной являются пользователи, то логично возникает вопрос где хранить и как управлять учетными данными. Здесь на помощь приходит интеграция со сторонним LDAP каталогом в том числе с Active Directory. Хотя vCD позволяет создавать и использовать свои собственные(локальные) учетные данные, при большем количестве пользователей, мне кажется это не удобным.

Итак, LDAP. В терминологии vCD может быть два вида каталогов, System LDAP и Organization LDAP. Первый может быть подключен на уровне самого vCD еще до создания дата-центров и организаций и служить для хранения учетных записей администраторов vCD с различными ролями. Второй же вид каталога доступен организациям для импорта учетных записей пользователей и администраторов организации. Фактически, это может быть один и тот же LDAP-каталог или совершенно разные. При создании новой организации, есть выбор; использовать System LDAP, его конкретный контейнер(OU), сторонний LDAP или использовать только локальные учетные данные.

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

Концепция vApp

На уровне vCD отсутствует понятие виртуальной машины как самой по себе здесь используется концепция vApp — виртуальных приложений. По нормальному, vApp это группа ВМ, вместе выполняющих некую задачу и не обязательно но обычно работающие в одной под сети одного сегмента(VLAN). Например сервер баз данных и подключенный к нему веб-сервер(один или множество) обрабатывающий некое веб-приложение является классическим примером vApp. Эти ВМ в идеале действуют как единое целое. Так же на уровне vApp могут быть определены особые правила сетевого взаимодействия между ВМ и отличный от других vApp способ связи с внешним миром. B даже если необходима просто отдельно стоящая ВМ то сперва нужно создать vApp и лишь «внутри» него появится возможность разместить ВМ.

Создание vApp

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

Для этого необходимо войти на портал организации по уникальному URL. И в разделе My Cloud выбрать New vApp. Первым делом предлагается выбрать виртуальный дата-центр в котором будет создан vApp и задать ему имя. На втором шаге появится возможность создать одну или несколько ВМ. Параметры создания ВМ стандартны, имя, тип ОС, количество CPU, объем диска и прочее. Далее задаем параметры сети и на этом пожалуй все. Работа с ВМ внутри vApp аналогично таковому процессу в vSphere по этому сложностей вызывать не должно. Далее по логике нужно подключить ISO-образ к ВМ и установить на них ОС. Прежде чем это сделать необходимо ознакомиться с еще одной концепцией vCD — каталогами.

vmware_vcloud_suiteРис №3 Портал организации.

Концепция каталогов

Это своего рода место хранения ISO-образов, шаблонов ВМ и целых vApp. Все они располагаются в разделе Catalogs на портале организации. Здесь можно создавать новые каталоги, подключать таковые из сторонних организация(зависит от политик) и определить права доступа к ним. Что бы образы ОС были доступны внутри организации необходимо загрузить их в созданный для этого каталог.
После этого образ легко подключается к ВМ с помощью команды
Insert CD\DVD from Catalog и установка ОС производит стандартно в окне VNC консоли vCD.

Выводы

В этой статье мы прошли довольно сложный путь по созданию всех необходимых логических объектов облачной инфраструктуры vCD. Разобрались в принципах их работы и взаимодействия. Создали первое виртуальное приложение(vApp) и ВМ внутри него. Многие вещи, такие как создание и использование vShield Edge Gateway а так же прочие настройки vCD остались за кадром из за статейных ограничений. В следующей статье я постараюсь освятить оставленные без внимания особенности функционирования сетей их взаимодействие а так же ряд других аспектов касающихся интерфейса(Branding). Так же надеюсь что дело дойдет до остальных продуктов из состава VMware vCloud Suite.