Vmware vdc что это
Настроим взаимодействие основных компонентов, разберемся в многоуровневой архитектуре и создадим первое пользовательской облако.
Как у же говорилось ранее, в состав vCloud Suite входит шесть основных продуктов;
Примечание: В пред идущей статье, кроме указанных выше продуктов, были упомянуты такие решения как vCloud Connector и vFabric Application Director. К сожалению, хоть они и имеют отношению к vCloud Suite но в его состав не входят. Это моя ошибка, прошу прощения.
Чтобы упорядочить материал и дать более обзорное(пошаговое) представление о том что уже должно быть и что еще предстоит проделать я предлагаю следующий план;
Развертывание базовой платформы vSphere (ESXi + vCenter).
Этот пункт описываться не будет. Подразумевается, что vSphere уже развернута.
Подключение vSheild Manager к vCenter.
2.1 Импорт подготовленной виртуальной машины(Virtual Appliance) vSheild Manager на один из ESXi-хостов,
2.2 Настройка сети vSheild Manager и подключение к vCenter.
Эта работа так же должна уже быть проделана. В помощь на этом шаге будут даны ссылки.
Развертывание vCD в виртуальной машине на одном из ESXi-хостов.
Этот пункт подробно рассматривался в первой части цикла.
Создание первой ячейки (vCloud Cell).
4.1Подключение vCenter и vSheild Manager к vCD
Пункт будет подробно рассмотрен в этой статье.
Уровни абстракции или за кулисами облака.
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 который по аналогии можно назвать стенами облака.
Подключить vCenter и vSheild Manager довольно легко. Это самый первый шаг конфигурирования и выполняется он сразу же после входа в веб-консоль vCD на странице Home с помощью мастера Attach a vCenter. Мастер запросит лишь учетные данные администраторов vCenter и vSheild и на этом пожалуй все, можно двигаться дальше.
Виртуальные дата-центры или за кулисами облака
Наилучшим помощником в понимании этого материала вам послужит рисунок №1 на котором изображена вся иерархическая архитектура от нисших базовых объектов, до абстрактных высокоуровневых сущностей.
Рис №1 Иерархия объектов vCD
Конечные облака, как уже говорилось создаются на базе ресурсов vSphere. Для того что бы определить сколько и каких ресурсов может использовать vCD предназначены специальные Provider VDCs(виртуальный дата-центр поставщика).
Примечание: Создание пула ресурсов в 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 существует три типа(уровня) сетей;
внешние сети(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(если применяется) в настройках порт группы. Все это сильно зависит от ваших задач и может потребовать привлечения дополнительного специалиста для правильной настройки сети.
Почти в облаках. Создание организации
Для каждой организации создается отдельный портал(с собственным 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.
Рис №2 Обзор всех ресурсов vCD
Учетные записи пользователей
Так как неотъемлемой частью организации в том числе и виртуальной являются пользователи, то логично возникает вопрос где хранить и как управлять учетными данными. Здесь на помощь приходит интеграция со сторонним LDAP каталогом в том числе с Active Directory. Хотя vCD позволяет создавать и использовать свои собственные(локальные) учетные данные, при большем количестве пользователей, мне кажется это не удобным.
Итак, LDAP. В терминологии vCD может быть два вида каталогов, System LDAP и Organization LDAP. Первый может быть подключен на уровне самого vCD еще до создания дата-центров и организаций и служить для хранения учетных записей администраторов vCD с различными ролями. Второй же вид каталога доступен организациям для импорта учетных записей пользователей и администраторов организации. Фактически, это может быть один и тот же LDAP-каталог или совершенно разные. При создании новой организации, есть выбор; использовать System LDAP, его конкретный контейнер(OU), сторонний LDAP или использовать только локальные учетные данные.
Стоит отметить, что vCD лишь синхронизирует информацию о пользователях и группах и производит аутентификацию в каталоге LDAP. Не каких изминений в него не вносится, за это можно быть спокойным. Так же vCD не поддерживает иерархические домены.
Концепция vApp
Создание vApp
Теперь, когда организация создана, ей выделены все необходимые ресурсы и определены параметры сетей самое время создать то ради чего все это строилось а именно первое виртуальное приложение.
Рис №3 Портал организации.
Концепция каталогов
Это своего рода место хранения ISO-образов, шаблонов ВМ и целых vApp. Все они располагаются в разделе Catalogs на портале организации. Здесь можно создавать новые каталоги, подключать таковые из сторонних организация(зависит от политик) и определить права доступа к ним. Что бы образы ОС были доступны внутри организации необходимо загрузить их в созданный для этого каталог.
После этого образ легко подключается к ВМ с помощью команды Insert CDDVD from Catalog и установка ОС производит стандартно в окне VNC консоли vCD.
В этой статье мы прошли довольно сложный путь по созданию всех необходимых логических объектов облачной инфраструктуры vCD. Разобрались в принципах их работы и взаимодействия. Создали первое виртуальное приложение(vApp) и ВМ внутри него. Многие вещи, такие как создание и использование vShield Edge Gateway а так же прочие настройки vCD остались за кадром из за статейных ограничений. В следующей статье я постараюсь освятить оставленные без внимания особенности функционирования сетей их взаимодействие а так же ряд других аспектов касающихся интерфейса(Branding). Так же надеюсь что дело дойдет до остальных продуктов из состава VMware vCloud Suite.
Application Programming Interface — программный интерфейс приложений, описание способов для обмена данными между приложениями.
Classless Inter-Domain Routing — безклассовая адресации, которая позволяет гибко управлять пространством IP-адресов.
Чтобы обозначить конкретную CIDR-сеть, укажите начальный IP-адрес и маску подсети. Пример «10.10.10.1/24».
Командлет — это встроенная в PowerShell команда, которая выводит результат запроса в виде объекта или коллекции объектов.
Comma-Separated Values — текстовый формат для представления табличных данных.
Кастомизация (Сustomization) — изменение настроек ОС VM в соответствии с заданными в панели управления VMware Cloud Director. Выполняется автоматически при включении VM.
Distributed Denial of Service, распределённая атака типа «отказ в обслуживании».
Distributed Firewall — распределенный межсетевой экран, который позволяет фильтровать East-West трафик между VM внутри сети облака без использования Edge Gateway.
Dynamic Host Configuration Protocol — протокол, который позволяет устройствам автоматически получать IP-адрес и другие параметры для работы в сети TCP/IP.
Distributed Logical Router — виртуальный распределенный маршрутизатор.
Domain Name System — распределенная компьютерная система для получения IP-адреса по имени компьютера или устройства.
East-West — направление потока трафика между разными VM/vApp внутри виртуального ЦОД.
Edge Gateway NSX ESG
Edge Gateway — пограничный маршрутизатор, межсетевой экран. Отвечает за North-South трафик, т. е. за взаимодействие VM с интернетом.
NSX ESG (Edge Services Gateway) предоставляет доступ ко всем сервисам NSX Edge: Firewall, NAT, DHCP, Load Balancing, IPSec VPN, SSL L2 VPN, SSL L3 VPN.
В каждом новом виртуальном ЦОД создается один основной Edge Gateway с публичным IP-адресом.
Межсетевой экран, поддерживает настройку правил с определением: входящего и исходящего IP или диапазона IP адресов, входящего и исходящего порта и протокола передачи данных.
Graphics processing unit — графический процессор, предназначенный для обработки графики и высокопроизводительных вычислений.
Гипервизор (Hypervisor) — это программа, которая управляет аппаратным оборудованием и распределяет его ресурсы между несколькими различными ОС, позволяя запускать их одновременно на одном компьютере. Гипервизор изолирует ОС друг от друга, распределяет ресурсы между запущенными ОС и управляет этими ресурсами.
В виртуальном ЦОД на базе VMware используется аппаратный гипервизор VMware ESXi.
Приложение, разработанное штатными сотрудниками внутри организации без привлечения иных компаний и лиц.
Input/Output Operations Per Second — количество операций ввода/вывода в секунду.
IP Security — набор протоколов для защиты данных, которые передаются по IP.
Оptical disc image — образ оптического диска.
Key Management Service — сервер активации Windows и MS Office.
Logical switch — виртуальный логический коммутатор для организации L2.
Media Access Control address — уникальный аппаратный идентификатор оборудования. Имеет длину 48 бит (6 байт) и записывается как шесть шестнадцатеричных чисел, разделенных двоеточием, тире или точками.
Network Address Translation — технология, которая преобразует приватные IP-адреса во внешние и наоборот.
Network Interface Controller — cетевой адаптер.
North-South — направление потока трафика, который либо входит в виртуальный ЦОД, либо выходит из него.
South-трафик — это данные, поступающие в виртуальный ЦОД через Edge Gateway и/или другую сетевую инфраструктуру. North-трафик — данные, выходящие из внутренней сети виртуального ЦОД во внешнюю.
Open Virtual Appliance — стандарт хранения и распространения виртуальных машин. Состоит из одного файла, который является TAR-архивом файлов формата OVF.
Open Virtualization Format — стандарт хранения и распространения виртуальных машин. Пакет OVF состоит из нескольких файлов: файл описания конфигурации VM (.ovf) и образы виртуальных дисков.
Сеть организации (Org VCD Network) — это сеть на Edge Gateway, которая связывает всю инфраструктуру. К ней можно подключить любые VM и vApp, а также через нее виртуальный ЦОД получает доступ к внешним сетями за пределами организации.
Изначально в организации нет сетей. После того как системный администратор SberCloud создаст необходимую сетевую инфраструктуру, пользователь с ролью Organization administrator сможет создавать сети организации и управлять ими.
Representational State Transfer — набор архитектурных принципов для построения распределенных масштабируемых веб-сервисов.
Remote Desktop Protocol — протокол для удаленного управления ОС Windows (протокол удалённого рабочего стола).
Serial ATA — интерфейс обмена данными с накопителями информации.
Serial Attached SCSI — интерфейс обмена данными с накопителями информации.
Security IDentifier — идентификатор безопасности в ОС Windows.
Service Level Agreement — соглашение об уровне предоставления услуги.
Снепшот — это копия данных VM и всего состояния системы. С его помощью можно вернуться к работоспособному состоянию виртуальной машины после неудачного обновления, тестирования приложений или других потенциально опасных действий. Снепшот хранится вместе с виртуальной машиной, поскольку его назначение — быстро вернуть предыдущее состояние VM.
Снепшоты — не резервные копии. В отличии от снепшотов, резервные копии хранятся отдельно от виртуальных машин, чтобы копии не повредились вместе с оригиналами. Их назначение — восстановить данные в случае аварий, сбоев и других непредвиденных событий.
Solid-state drive — запоминающее устройство на основе микросхем памяти и управляющего контроллера.
Secure Shell — сетевой протокол для удаленного управления операционной системой и туннелирования TCP-соединений. Шифрует весь трафик, включая передаваемые пароли.
Secure Sockets Layer — криптографический протокол защиты обмена данными.
Организация (или Tенант) — логический объект VMware Cloud Director, который включает совокупность вычислительных ресурсов, каталогов и пользователей. Организация может состоять из одного или нескольких виртуальных ЦОД.
vApp (контейнер) — это логический объект VMware Cloud Director, который состоит из одной или нескольких VM. vApp позволяет объединить несколько VM в группу и упростить тем самым их администрирование.
В vApp можно создать изолированную сеть, доступную только VM внутри vApp.
Шаблон vApp (vApp Template) — образ VM с установленной ОС, настроенными приложениями и различными данными. Шаблоны vApp хранятся в каталогах. С помощью шаблонов можно разворачивать VM единообразно для всей организации.
Сеть vApp (vApp Network ) — это сеть внутри vApp. Она создается при развертывании vApp и удаляется, когда удаляется vApp. Сеть vApp может быть изолирована от других сетей или подключена к сети организации.
Сети vApp позволяют VM внутри vApp взаимодействовать друг с другом, а также c VM в других vApp через подключение к сети организации.
Виртуальные процессорные ядра.
Виртуальный ЦОД (Virtual Data Center, VDC) — логический объект VMware Cloud Director, который объединяет виртуальные ресурсы и распределяет их между пользователями. В виртуальном ЦОД размещаются VM и vApp, с которыми работают пользователи. В одной организации могут размещаться один или несколько виртуальных ЦОД.
Каталог (Catalog) — логический объект VMware Cloud Director, в котором хранятся шаблоны vApp и медиафайлы. Доступ к содержимому каталога есть у владельца каталога и у пользователей, которым владелец предоставил доступ.
Виртуальное дисковое пространство.
Виртуальная машина (Virtual Machine, VM) — это виртуальный аналог физического компьютера, на котором можно запускать ОС, приложения, сервисы и выполнять те же функции, что и на физическом оборудовании. Кроме этого VM также поддерживают операции виртуальной инфраструктуры, такие как создание снепшота и перемещение VM с одного хоста на другой.
VM — основа облачной инфраструктуры и именно VM используют ресурсы облака. По умолчанию в виртуальном ЦОД нет готовых VM, их нужно создавать с нуля или разворачивать из шаблонов.
Virtual Private Network — обобщенное название технологий, позволяющих обеспечить одно или несколько защищенных сетевых соединений (защищенную логическую сеть) поверх другой сети (далее — виртуальная частная сеть).
Виртуальная оперативная память.
Unified Extensible Firmware Interface — прошивка, которая используется вместо BIOS.
VMware Cloud Director (vCD) - это платформа управления программно-определяемым центром обработки данных (SDDC) VMware. Его удобный интерфейс HTML5 обеспечивает безопасный доступ на основе ролей к вашим облачным ресурсам, в том числе на мобильных устройствах.
На платформе VMware Cloud Director вы можете использовать:
- пользовательский интерфейс для управления виртуальными машинами,
- для определения групп и ролей организации,
- управление вычислительными ресурсами и ресурсами хранения,
- библиотеки для создания vApps и виртуальных машин из шаблонов,
- мониторинг задач и событий,
- vCloud Availability Disaster Recovery-as-a-Service (DRaaS).
Ниже приведен краткий обзор термонологии и функциональности.
Virtual Data Center
На домашней странице вы можете получить обзор использования ваших ресурсов.
Administration
Users and Groups
Организация может содержать произвольное количество пользователей и групп. Доступ пользователям и группам внутри организации предоставлятся путем назначения прав и ролей .
Roles
Роли - это наборы прав, назначаемых пользователями или группами. Использование ролей упрощает распределение прав на совершение действий в системе. По умолчанию вы можете назначить следующие роли:
- Catalog Author (разрешить пользователю создавать и публиковать каталоги)
- Console Access (пользователь может видеть статус и настройки виртуальной машины, а также пользоваться её гостевой операционной системой)
- Defer to Identity Provider (более длинное объяснение)
- Organization Administrator (позволяет управлять пользователями и группами в своей организации и назначать им роли)
- vApp Author (позволяет использовать каталоги и создавать vApp-ы)
- vApp User (позволяет использовать существующие vApp-ы)
Права дают доступ и/или позволяют выполнять действия в Cloud Director. Каждое право определяет вид интерфейса и доступ на уровне объектов Cloud Director. У каждой организация может быть свой набор прав и ролей, назначенных пользователям и группам. Также можно создавать свои роли.
Identify providers – SAML
SAML (Security Assertion Markup Language) - это стандарт, обеспечивающий безопасную двухэтапную аутентификацию и авторизацию. С помощью поставщика удостоверений SAML (например, Azure AD, RSA, IBM Cloud Identity, Keycloak, диспетчера удостоверений VMware) пользователи и группы могут быть проверены, а организации могут быть подключены к Microsoft Active Directory.
Certificate Management
Вы можете импортировать необходимые сертификаты для решений VMware (NSX-Gateway, Load Balancer и т. Д.).
Взаимосвязанные центры обработки данных, расположенные в нескольких разных географических точках, называются мультисайтами. В контексте Cloud Director Multisite позволяет управлять различными виртуальными центрами обработки данных из единого интерфейса. Для общего использования одного сегмента локальной сети в двух виртуальных дата центрах (cross-VDC networking) требуется мультисайт.
Quotas
Можно указать, сколько виртуальных машин пользователи могут хранить и запускать в организации VDC .
Есть также несколько других вариантов политик и настроек, которые вы можете настроить (общие, электронная почта, персонализация гостя, метаданные, политики).
Datacenters - отсюда все вычислительные ресурсы и ресурсы хранения управляются
Compute
vApps
vApp - это контейнер, в котором вы можете назначать различные права и настройки виртуальным машинам. vApp может состоять из одной или нескольких виртуальных машин. Несколько виртуальных машин могут образовывать многоуровневое приложение (например, веб-сервер, базу данных и сервер безопасности). vApp позволяет управлять несколькими виртуальными машинами как одной службой и настраивать различные правила и параметры (закрытая сеть, правила брандмауэра и т. д.). Вы также можете настроить различные параметры запуска виртуальных машин. Например, если vApp включает в себя веб-сервер и сервер базы данных, которые необходимо запускать в определённой последовательности, то в настройках vApp можно указать порядок, в котором эти серверы запускаются и задержку между запусками.
Virtual machine
В рамках VM вы можете создавать отдельные виртуальные машины, не принадлежащие vApp. В виртуальных машинах вы можете управлять параметрами существующих виртуальных машин (например, делать снимок "snapshot").
(Anti)Affinity rules
Affinity / Anti-Affinity rules позволяют пользователям vCD указывать, как планировщик распределенных ресурсов vSphere (DRS) должен развертывать виртуальные машины на хостах (виртуальных узлах):
- VM - VM Affinity (VM должны находиться на одном хосте)
- VM - VM Anti-Affinity (VM должны находиться на разных хостах)
- VM - host Affinity (VM должны быть на определенных хостах)
- VM - host Anti-Affinity (VM не могут находиться на определенных хостах)
Например, вы можете привязать одну виртуальную машину к одному хосту, а другую виртуальную машину к другому хосту и хранить их отдельно.
Эти правила можно использовать для оптимизации затрат на лицензирование (если плата за лицензию взимается за количество физических ядер сервера, правила Affinity могут ограничивать количество серверов, на которых может работать виртуальная машина), повышения доступности и отказоустойчивости (если продублированные виртуальные машины работают на разных хостах) и уменьшить сетевую задержку (когда виртуальные машины работают на одном хосте).
Kubernetes policies
Здесь пользователь vCD может управлять различными внешними / внутренними сетями, сетями VDC организации и сетями vApp.
Edges
Edge Gateway (граничный шлюз) - это виртуальный маршрутизатор, который соединяет внутреннюю сеть с внешней сетью и предоставляет такие услуги, как:
vCloud Director поддерживает решения для граничных шлюзов IPv4 и IPv6.
Security
Named (ранее independent) диски - это автономные виртуальные диски, которые создаются в виртуальном центре обработки данных организации. Администраторы и авторизованные пользователи в организации могут создавать, изменять и удалять диски, а также подключаться к виртуальным машинам. По сути, он действует как внешний жесткий диск, используемый в VDC. Не предназначен для активного резервного копирования данных, так как снимок (snapshot) не может быть создан с этого диска.
В разделе «Политики хранения» вы можете получить обзор дисковых томов хранилища vCloud и информации.
Libraries
Библиотеки - это место, где вы можете хранить свои шаблоны (например, OS, vApp, VM, ISO).
Пользователи имеют привилегированный доступ к шаблонам vApp и медиафайлам, которыми они владеют или которыми с ними делятся.
vApp templates
Шаблон vApp - это предварительно настроенная виртуальная машина или несколько машин, которые можно развернуть в облаке за считанные минуты. WaveCom имеет готовые шаблоны ОС, которые можно использовать для развертывания. Вы также можете создать шаблон из существующих виртуальных машин или vApp и использовать их в будущем. Также можно создать шаблон, загрузив образ OVA / OVF.
В Media & Other вы можете увидеть ISO-образы Wavecom OS, а также загрузить свои собственные и подключить их к виртуальной машине.
Monitor
Task
На панели задач "Монитор" можно увидеть все задачи, время когда они были запущены и их статус. Монитор - это первый шаг к устранению проблем в вашей среде. Монитор задач показывает длительные операции, такие как создание виртуальной машины или vApp.
Events
В Events вы можете просматривать системный журнал для отслеживания событий на уровне системы. Вы можете находить и устранять неисправные события, а также просматривать события по пользователю.
vCloud Availability
Доступность vCloud в vCloud Director - это решение Disaster Recovery-as-a-Service (DRaaS), которое позволяет легко и безопасно запускать рабочие процессы локального центра обработки данных в другом центре обработки данных в случае возникновения чрезвычайной ситуации. Предполагается, что сайт аварийного восстановления настроен в соответствующих центрах обработки данных.
По всем затронутым темам вы можете найти больше руководств в нашего веб-сайта раздел помощи и на канале YouTube.
В среде Cloud Director вы можете использовать «Quick Search» для еще более простой навигации, расположенный вверху справа под кнопкой «Help».
Если у вас есть дополнительные вопросы, кнопка «Help» в правом верхнем углу также направит вас к руководству VMware Tenant Portal.
Служба помощи клиентам:
Пн-Пт +372 685 0000
Не секрет, что довольно продолжительное время администраторы VMware зависели от стандартных виртуальных коммутаторов (вКоммутаторов, vSS), которые одновременно работают только с одним физическим хостом. То есть в случае использования vSS они должны присутствовать на каждом сервере, а при необходимости создания дополнительной группы портов для еще одного VLAN требуется повторить одно и то же действие на всех серверах ESX/ESXi. В случае с vDS мы имеем дело с единственным логическим коммутатором, охватывающим сразу все серверы ESX/ESXi. Помимо озвученного, vDS обеспечивает централизованное управление сетью и улучшает безопасность за счет наблюдения за «состоянием здоровья». Для понимания разницы между стандартным и распределенным коммутатором VMware vSphere сравним некоторые функциональные особенности:
| Стандартный коммутатор VMware vSphere | Распределенный коммутатор VMware vSphere | |
| Передача данных 2-го уровня | ||
| Поддержка VMware vSphere vMotion | ||
| VMware vSphere Network vMotion | ||
| Группировка по степени загруженности | ||
| Ограничение скорости трафика к ВМ | ||
| Разметка IEEE 802.1 p | ||
| Поддержка VMware vCenter | ||
| Протокол LLDP |
Специфика централизованного управления
Теперь, когда мы вкратце рассмотрели функциональные особенности виртуального распределенного коммутатора, уделим внимание вопросу управления инфраструктурой. С развитием концепции централизованного доступа выполнять рутинные задачи стало куда проще. Как в этом вопросе помогает vDS и что из этого получается, рассмотрим далее.
Из сказанного нетрудно сделать вывод и ответить на распространенный вопрос: как влияет недоступность vCenter на функционирование виртуальной инфраструктуры с распределенным виртуальным коммутатором?
Ответ очевиден: vDS продолжит работу с некоторыми ограничениями, где сетевая коммуникация между ВМ будет по-прежнему доступна. Но если в этот момент потребуется внести изменения в сетевые настройки машины, прибегаем к помощи стандартного коммутатора и подключаем к нему ВМ. Это необходимо потому, что в этот момент конфигурация vDS недоступна для редактирования. Следовательно, требуется привести vCenter в рабочее состояние.
Сетевые особенности VMware vDS
Прежде чем говорить о сетевых особенностях vDS, перенесемся в абстрактный центр обработки данных и посмотрим, как обстоят дела при возникновении сетевых проблем. Практически любые изменения, которые необходимо выполнить, связаны с ручной конфигурацией, что дополнительно увеличивает административные издержки. А как в подобной ситуации ведет себя стандартный виртуальный коммутатор? В случае с vSS обеспечивается программный контроль над организацией сети отдельно взятых ESX-/ESXi-хостов, что в определенной степени вызывает другие проблемы. Поскольку vSS-экземпляры присутствуют на каждом узле, администратору приходится выполнять конфигурацию и мониторинг в режиме host-by-host, что не исключает совершения ошибок. В случае с vDS проблема нивелируется средствами программно-определяемого механизма и обеспечивается ряд дополнительных функций, повышающих производительность сети. Сюда относится механизм фильтрации трафика и контроль сетевых операций ввода-вывода.
vSS или vPS
Беря во внимание дополнительные функции, которыми наделен распределенный виртуальный коммутатор, возникает вопрос: зачем же все-таки выбирать между vDS и vSS? Ответ на удивление прост: зачастую выбор зависит от желания сэкономить деньги. Дело в том, что стандартный vSS включен в каждую версию vSphere, в то время как vDS доступен только при использовании vSphere редакции Enterprise Plus, представляющей собой самый дорогой вариант лицензирования VMware. Хотя высокая стоимость и компенсируется дополнительными возможностями в виде поддержки NetFlow, мониторинга «состояния здоровья», зеркалирования портов и прочих особенностей, бюджет не каждой компании готов потянуть такое решение. Однако цена оправдывает средства. Помимо сказанного, VMware vDS обладает гораздо большей гибкостью и имеет следующие особенности:
- обеспечивает централизацию операций по управлению сетевой конфигурацией узлов VMware ESXi;
- предлагает расширенный функционал для сетевых администраторов;
- выполняет мониторинг состояния сетевых компонентов виртуальной инфраструктуры на разных уровнях и устраняет возникшие проблемы;
- отвечает за резервное копирование и восстановление конфигурации сети в случае сбоев;
- выполняет приоритизацию различного типа трафика и другое.
К тому же с выходом в свет последних релизов vSphere, а речь идет о 5 и 6 версиях, добавился ряд новых функций и обновлений, касающихся в том числе и сетевых инструментов VMware. Например, в vSphere 5 доступна поддержка зеркалирования портов и добавлен протокол обнаружения канального уровня. Первое позволяет сетевому коммутатору посылать копии трафика с одного свитч-порта на другой, а второе обеспечивает сбор детализированной информации о сетевых устройствах. Кроме того, с выходом новой версии серверной платформы виртуализации vSphere каждый раз происходит увеличение максимумов конфигурации тех или иных компонентов платформы, в том числе vDS. Так, максимальная конфигурация хостов на один распределенный виртуальный коммутатор в vSphere 6.0 составляет 1000, тогда как в vSphere 6.5 это значение увеличилось до 2000.
Резюмируя
В этой статье мы познакомились с особенностями распределенного виртуального коммутатора vDS, уделив внимание функциональным особенностям решения. Чтобы проверить, насколько хорошо усвоен пройденный материал, предлагаем пройти тест на применимость использования виртуальных свитчей, в том числе распределенного виртуального коммутатора в виртуальном окружении.
Читайте также: