- tocdepth
2
Архитектура платформы Облако VMware
Платформа Cloud.ru Облако VMware, построенная на базе решения VMware Cloud Director, добавляет уровень абстракции ресурсов для облегчения многопользовательской работы и обеспечения совместимости между облаками, построенными по стандарту Cloud API.
Логически платформа Облако VMware состоит из следующих компонентов:
Физические вычислительные ресурсы, ресурсы хранения и сетевые ресурсы передаются на уровень vSphere, где создаются пулы ресурсов, виртуальные коммутаторы и политики хранения.
Пулы ресурсов и хранилища данных передаются на уровень Cloud Director и подключаются к виртуальным центрам обработки данных провайдера.
Чистые виртуальные вычислительные ресурсы и ресурсы хранения предоставляются пользователям через виртуальные центры обработки данных. Пользователи потребляют чистые виртуальные ресурсы из виртуальных центров обработки данных с помощью различных моделей предоставления ресурсов.
Возможность совместного использования арендаторами ресурсов VMware Cloud Director обеспечивается следующими ключевыми конструкциями:
- ЦОД провайдера: Provider VDC (pVDC)
Группа вычислительных ресурсов и ресурсов хранения, находящихся под управлением одного сервера vCenter Server. Виртуальный центр обработки данных провайдера может состоять из одного или нескольких пулов ресурсов. Он объединяет пулы ресурсов с одной или несколькими политиками хранения и может предоставлять ресурсы нескольким арендаторам (организациям).
- Организации (тенанты)
Логическая единица многопользовательского доступа, представляющая собой единую логическую границу безопасности. Организация содержит пользователей и виртуальные центры обработки данных.
- ЦОД организации: Organization VDC (Org VDC)
Подгруппа вычислительных ресурсов, памяти, ресурсов хранения, сетей и сетевых маршрутизаторов, выделенных из виртуального центра обработки данных провайдера. Виртуальный центр обработки данных — среда развертывания, в которой могут быть развернуты и использованы виртуальные приложения vApp. Виртуальные центры обработки данных организации не могут охватывать несколько арендаторов.
ЦОД провайдера: Provider VDC (pVDC)
Виртуальный центр обработки данных (VDC) — стандартный контейнер для пула вычислительных, дисковых (хранение) и сетевых ресурсов. Существует два типа виртуальных центров обработки данных — ЦОД провайдера и ЦОД организации. Виртуальный центр обработки данных провайдера собирается из пулов ресурсов и хранилищ данных, представленных политиками хранения, управляемыми одной группой ресурсов vCenter Server. pVDC может охватывать несколько пулов ресурсов (или выделенных кластеров) и формировать эластичные центры обработки данных организаций.
Ниже приведены лучшие практики для проектирования виртуального центра обработки данных провайдера:
Смешивание типов распределения ресурсов (allocation) для ЦОДов организаций в рамках ЦОДа провайдера возможно, но усложняет управление емкостью, особенно когда разные типы распределения (allocation) имеют разные SLA производительности.
С точки зрения удобства управления рекомендуется создавать резервные копии виртуальных центров обработки данных провайдера с помощью кластеров vSphere. Также можно разделить кластер на несколько пулов ресурсов и назначить их разным ЦОДам провайдера. Это может быть полезно, когда в одном кластере развернуты ВМ, не управляемые Cloud Director. В этом случае вручную установите ограничения пула ресурсов, чтобы Cloud Director понимал, какое количество ресурсов может потреблять каждый ЦОД провайдера из разделенного кластера vSphere.
Каждая зона доступности должна иметь свои собственные ЦОДы провайдера. Это позволяет создать ЦОД организации для конкретного сайта.
Создавайте выделенные ЦОДы организации поверх выделенного клиентом кластера в выделенном клиентом ЦОДе провайдера.
Сетевой пул VXLAN, из которого создаются организационные сети VDC и vApp, создается автоматически при создании каждого центра обработки данных провайдера. Каждый пул сетей VXLAN представлен рамками сети VXLAN, охватывающими кластеры, которые принадлежат данному провайдеру VDC. ЦОД организации может использовать любой сетевой пул, но только один.
Виртуальный центр обработки данных одного провайдера может предоставлять различные уровни хранения, представленные политиками хранения, но только один уровень предоставления вычислительных ресурсов. ЦОД провайдера может охватывать несколько кластеров vSphere (пулов ресурсов), однако он привязан к одному серверу vCenter Server.
Несколько ЦОДов провайдера могут быть использованы по следующим причинам:
Облаку требуется больше вычислительных мощностей, чем может предоставить один vCenter Server.
Требуются многоуровневые вычисления. Каждый ЦОД провайдера сопоставляется с кластерами vSphere с различными характеристиками (производительность или SLA).
Требуется, чтобы рабочие нагрузки выполнялись на физически раздельной инфраструктуре (в разных зонах доступности).
- Размещение виртуальной машины при ее создании
При создании виртуальной машины механизм размещения помещает ее в пул ресурсов виртуального центра обработки данных провайдера, который наилучшим образом соответствует требованиям виртуальной машины. Для виртуального центра обработки данных организации создается пул субресурсов в пуле ресурсов виртуального центра данных провайдера, и виртуальная машина размещается в этом пуле субресурсов.
Когда виртуальная машина включается, механизм размещения проверяет пул ресурсов виртуального центра обработки данных провайдера, чтобы убедиться, что он все еще может включить виртуальную машину. Если нет, механизм размещения перемещает виртуальную машину в пул ресурсов виртуального центра обработки данных провайдера с достаточным количеством ресурсов для работы виртуальной машины. Подпул ресурсов для виртуального центра данных организации создается, если он еще не существует. Если перемещение требует передачи файлов виртуальной машины, используется передача протокола NFC по сети управления или сети инициализации.
Организации (тенанты)
Организации являются единицей многопользовательского доступа в VMware Cloud Director и представляют собой единую логическую границу безопасности. Организация VMware Cloud Director сопоставляется с конечным клиентом. Организации могут использовать локальные учетные записи или прямую интеграцию LDAP (с дополнительным SSPI), а также интегрироваться с помощью SAML2 или OAuth с совместимым поставщиком идентификационных данных (Workspace ONE Access, Microsoft Active Directory Federation Services, OpenAM и т.д).
Административная организация обычно создается для обеспечения глобальных каталогов и других общих служб (серверы лицензирования, хранилища исправлений и т.д.). Управление доступом системного администратора VMware Cloud Director может осуществляться с помощью встроенной аутентификации LDAP или путем федерации со службой VMware vCenter Single Sign-On, которая обеспечивает бесшовную интеграцию управления между VMware Cloud Director и объектами VMware vSphere. При федерации vCenter Single Sign-On при попытке входа в систему системный администратор VMware Cloud Director перенаправляется на VMware vSphere Web Client для аутентификации. Поэтому для администраторов требуется надлежащее сетевое подключение не только к VMware Cloud Director, но и к конкретному VMware vSphere Web Client. VMware vCenter Single Sign-On также может обеспечивать двухфакторную аутентификацию для доступа провайдера.
Управление пользователями
Ниже перечислены рекомендации по управлению пользователями:
Нежелательно использовать локальные учетные записи VMware Cloud Director.
Пользователь или администратор организации может изменить пароль пользователя, только если это локальная учетная запись VMware Cloud Director.
Параметры LDAP организации должны быть настроены системным администратором. Ячейки VMware Cloud Director должны иметь сетевой доступ к LDAP-серверам.
Интеграция Active Directory SSPI позволяет осуществлять единый вход для арендаторов, уже прошедших аутентификацию в домене Active Directory.
Провайдер идентификации (IdP) SAML 2.0 может быть настроен администратором организации. Арендатор может использовать свой собственный IdP (Active Directory), не требуя сетевого соединения между ячейками VMware Cloud Director и IdP-серверами.
Аутентификация OAuth 2.0 позволяет пользователю проходить аутентификацию с помощью единого токена, предоставленного внешним поставщиком услуг идентификации. Поставщик услуг может отозвать права на настройку OAuth у администратора организации и управлять ею от его имени для интеграции сторонних порталов или объединения нескольких экземпляров VMware Cloud Director.
Права управления пользователями могут быть отозваны у администратора организации, что может быть полезно, если провайдер управляет учетными записями в централизованном провайдере идентификации и не хочет разрешать арендаторам создавать локальные учетные записи.
Гранулированный доступ на основе ролей: RBAC
В VMware Cloud Director имеется возможность создания гранулированных ролей на уровне арендаторов и систем. Это важно для поставщиков услуг, которые хотят разграничить доступ арендаторов к определенным функциям (например, к расширенным сетевым сервисам). Это также позволяет арендаторам создавать собственные роли, соответствующие структуре их команды (например, администратор сети). И, наконец, администратор системы может создавать дополнительные роли в контексте системы с доступом к подмножеству функций. Роль — набор прав, которые могут быть назначены пользователю или группе. Пример прав арендатора — настройка IPSEC VPN. Примером прав системного администратора является включение/выключение хоста.
В VMware Cloud Director имеются следующие возможности:
Роли не являются глобальными, а зависят от организации.
Поставщик услуг может создавать новые шаблоны ролей.
Шаблоны ролей используются для создания ролей, специфичных для организации.
Поставщик услуг может выборочно предоставлять права конкретным организациям.
Администраторы организаций могут создавать свои собственные роли для конкретных организаций из подмножества предоставленных прав.
Новые роли могут быть созданы в контексте системы из подмножества прав системного администратора.
Когда создается новая организация, она имеет доступ ко всем правам, которые используются в шаблонах ролей.
Системный администратор может предоставить дополнительные права организации с помощью Cloud API:
GET /api/admin ...— получить ссылки на все права в экземпляре VCD;
GET /api/admin/org/<org-id>/rights ...— получить ссылки на все права в организации;
PUT /api/admin/org/<org-id>/rights ...— редактировать права в организации.
Системный администратор или администратор организации может создавать новые роли в своей организации с помощью Cloud API: POST /admin/org/<org-id>/roles.
ЦОД организации: Organization VDC (Org VDC)
Виртуальный центр данных организации — подгруппа вычислительных ресурсов, ресурсов хранения и сетевых ресурсов, выделенных из виртуального центра данных поставщика и сопоставленных с организацией. Виртуальные центры обработки данных организации — среда развертывания, в которой vApp могут быть размещены, развернуты и включены.
Типы распределения ресурсов для Org VDC
В Org VDC применяются следующие типы распределения ресурсов:
Allocation VDC (пул распределения).
Reservation VDC (резервирование ресурсов).
- Пул распределения ресурсов Allocation VDC
Ниже приведены замечания по проектированию неэластичного пула распределения VDC:
Пул распределения Allocation Pool Org VDC ограничен размером первичного пула ресурсов (кластер провайдеров VDC).
При создании неэластичного пула распределения Org VDC, создается дочерний пул ресурсов с ограничениями CPU и памяти, установленными для распределения Org VDC, и резервированием, установленным на гарантированный процент x.
Арендатор не может перераспределять память.
Арендатор может перераспределять vCPU (использование CPU ограничено распределением CPU в Org VDC).
Накладные расходы на память ВМ относятся на счет арендатора.
- Пул с резервирование ресурсов Reservation VDC
VDC типа резервирования используется для предложения выделенных услуг, когда арендатор получает собственные вычислительные ресурсы (например, кластер vSphere). Арендатор может устанавливать резервирование, ограничения и доли на уровне ВМ и управлять переподпиской ресурсов. Максимальный размер VDC — это полезная емкость кластера (после удаления HA N+1 и накладных расходов гипервизора), уменьшенная на необходимый ресурс для развертывания граничных шлюзов. Пограничные шлюзы могут быть развернуты в пулах вторичных ресурсов VDC провайдера, что полезно в сценариях кластера NSX-T Edge. В этом сценарии кластер для пограничных шлюзов можно разделить между многими различными VDC провайдера, разделив его на созданные вручную пулы ресурсов.
На следующем рисунке основной пул ресурсов каждого поставщика VDC представляет собой выделенный кластер, который может быть размером до двух хостов. Кластер NSX-T Edge содержит несколько небольших пулов ресурсов, которые добавляются к каждому Reservation Org VDC в качестве вторичных пулов ресурсов.
Такая конструкция позволяет использовать высокодоступные экземпляры NSX-T Edge (активные/пассивные), когда арендатор хочет приобрести только два кластера хостов и оплатить лицензирование программного обеспечения (например, ПО базы данных) для одного хоста, при этом второй используется только для отказоустойчивости.
Не рекомендуется использовать VDC типа резервирования в общем кластере. Арендатор может создать ВМ произвольного размера, поскольку его физические вычислительные ресурсы ограничены пулом ресурсов Org VDC, а не выделенными ресурсами VDC. Например, внутри Org VDC, которому выделено 100 ГБ ОЗУ, можно включить ВМ с 200 ГБ ОЗУ. Если объем памяти ВМ превышает лимит пула ресурсов, хост ESXi, на котором запущена ВМ, скорее всего, приведет к свопингу памяти, которую он физически не может предоставить. Свопинг может создать значительную нагрузку на хост и его хранилище и негативно повлиять на другие рабочие нагрузки арендатора.
Сети
Для обеспечения гибкой и безопасной сетевой инфраструктуры в мультитенантной облачной среде VMware Cloud Director использует многоуровневую сетевую архитектуру с четырьмя категориями сетей. Подробнее с сетями платформы Облако VMware можно ознакомиться в документации.
Эти категории сетей включают:
внешние сети;
сети виртуальных центров обработки данных организации (VDC);
сети групп центров обработки данных;
сети vApp.
Для большинства типов сетей платформы Облако VMware требуются дополнительные объекты инфраструктуры, такие как пограничные шлюзы и сетевые пулы.
- Внешние сети
Внешняя сеть предоставляет аплинк, соединяющий сети и виртуальные машины в среде VMware Cloud Director с внешними сетями, такими как VPN, корпоративная интрасеть или общедоступный интернет. Внешняя сеть поддерживается либо одной сетью vSphere, либо несколькими сетями vSphere, либо логическим маршрутизатором уровня 0 центра обработки данных NSX-T.
- Сетевые пулы
Сетевой пул — набор изолированных сегментов сети второго уровня, которые можно использовать для создания сетей vApp и определенных типов организационных сетей VDC по требованию. Сетевые пулы должны быть созданы до сетей VDC организации и сетей vApp. Если они не существуют, единственным доступным для организации вариантом сети является прямое подключение к внешней сети. Создать сетевой пул может только системный администратор.
- Сети виртуальных центров обработки данных организации
Сети виртуальных центров обработки данных (VDC) организации позволяют vApps взаимодействовать друг с другом или с внешними сетями за пределами организации. В зависимости от подключения сети VDC организации к внешней сети существует несколько различных типов сетей VDC организации. Сети VDC организации обеспечивают прямое или маршрутизируемое подключение к внешним сетям или могут быть изолированы от внешних сетей и других сетей VDC организации. Для маршрутизируемых подключений требуется пограничный шлюз и сетевой пул в организационном VDC.
- Сети групп центров обработки данных на базе центра обработки данных VMware NSX-T
Сети групп центров обработки данных — тип организационных сетей VDC, которые совместно используются одним или несколькими VDC и к которым могут подключаться vApps. Системный администратор или администратор организации создает сети групп центров обработки данных и привязывает их к одной группе VDC. VMware Cloud Director поддерживает изолированные, импортированные, прямые и маршрутизируемые сети групп центров обработки данных, которые поддерживаются VMware NSX-T.
- Сети vApp
Сети vApp позволяют виртуальным машинам взаимодействовать друг с другом или, если есть подключение к сети VDC организации, с виртуальными машинами в других vApp. Сеть vApp находится внутри vApp. Сеть vApp может быть изолирована от других сетей или подключена к сети VDC организации. Каждый vApp содержит сеть vApp. Сеть создается при развертывании vApp и удаляется при неразвертывании vApp. Администратор организации настраивает и контролирует сети vApp.
Виртуальные машины в vApp могут подключаться к сетям vApp, которые могут быть изолированными, прямыми или маршрутизируемыми, а также к сетям VDC организации. В vApp можно добавлять сети разных типов для решения различных сетевых сценариев. Виртуальные машины в vApp могут подключаться к сетям, которые доступны в vApp. Если вы хотите подключить виртуальную машину к другой сети, вы должны сначала добавить эту сеть в vApp. vApp может включать сети vApp и сети VDC организации. Изолированная сеть vApp содержится внутри vApp. Можно также маршрутизировать сеть vApp в сеть VDC организации, чтобы обеспечить подключение к виртуальным машинам за пределами vApp. Для маршрутизируемых сетей vApp можно настроить сетевые службы, такие как межсетевой экран и статическая маршрутизация. Можно подключить vApp непосредственно к сети VDC организации.
Если у вас есть несколько vApp, содержащих идентичные виртуальные машины, подключенные к одной сети VDC организации, и вы хотите запустить vApp одновременно, вы можете оградить vApp. Ограждение vApp позволяет включать виртуальные машины без конфликтов, изолируя их MAC- и IP-адреса.
- Пограничные шлюзы
Пограничный шлюз обеспечивает подключение маршрутизируемой сети VDC организации к внешним сетям и может предоставлять такие услуги, как балансировка нагрузки, трансляция сетевых адресов и межсетевой экран. VMware Cloud Director поддерживает пограничные шлюзы IPv4 и IPv6. Для пограничных шлюзов используется решение VMware NSX-T.
Каталоги
Каталог — контейнер для шаблонов vApp и медиафайлов (ISO) в организации. Администраторы организации и авторы каталогов могут создавать каталоги в организации. Содержимое каталога может быть совместно использовано другими пользователями или организациями в VMware Cloud Director или опубликовано во внешней среде для доступа организаций, не входящих в VMware Cloud Director.
VMware Cloud Director содержит частные каталоги, общие каталоги и каталоги с внешним доступом. Частные каталоги включают шаблоны vApp и медиафайлы, которыми можно делиться с другими пользователями в организации. Если системный администратор разрешает общий доступ к каталогам для организации, можно открыть общий доступ к каталогу организации для создания каталога, доступного другим организациям в VMware Cloud Director. Если системный администратор разрешает публикацию внешних каталогов для организации, можно опубликовать каталог организации для доступа организаций за пределами VMware Cloud Director. Организация за пределами VMware Cloud Director должна подписаться на внешний опубликованный каталог, чтобы получить доступ к его содержимому.
Можно загрузить пакет OVF непосредственно в каталог, сохранить vApp как шаблон vApp или импортировать шаблон vApp из vSphere. Члены организации могут получить доступ к шаблонам vApp и медиафайлам, которые принадлежат им или к которым они предоставили общий доступ. Администраторы организации и системные администраторы могут открыть общий доступ к каталогу для всех в организации или для определенных пользователей и групп в организации. Каталоги поддерживают версионность и могут быть развернуты с определенной политикой хранения.
Облачные приложения: vApps
vApp представляет собой контейнер для программного решения и является стандартной единицей развертывания в VMware Cloud Director. Он имеет операции включения, состоит из одной или нескольких виртуальных машин, виртуальных сетей и метаданных и может быть импортирован или экспортирован как пакет OVF.
При запуске vApp VMware Cloud Director создает виртуальные сети и виртуальные машины и потребляет резервирование виртуальных центров обработки данных организации. Частично включенный vApp — состояние vApp, в котором одна или несколько виртуальных машин в vApp отключены, но сети и резервирование все еще используются. vApp в состоянии Stopped освобождает все ресурсы, кроме ресурсов хранения. Стандартизированные шаблоны vApp для распространенных гостевых операционных систем предоставляются в глобальном каталоге ресурсов. Арендаторы могут создавать собственные vApp или импортировать их через Cloud Connector или импорт OVF.
Ниже перечислены соображения по проектированию развертывания vApp:
При создании ВМ в vApp выберите правильную операционную систему в свойствах ВМ. Неправильно указанная операционная система влияет на представленное виртуальное оборудование.
Установите VMware Tools, чтобы воспользоваться преимуществами действий по отключению гостевой операционной системы и сценариями настройки гостя (назначение IP и т.д.).
Ограничения конфигурации виртуальных машин могут быть введены при развертывании с помощью задачи блокировки (см. статью базы знаний VMware CPU and Memory Limit enforcement for Cloud Director. Веб-сайты сторонних производителей не контролируются Cloud.ru, и содержимое этих сайтов может меняться).
Состояние vApp (память) можно сохранить в каталоге. vApp с состоянием (в состоянии Suspended) можно перемещать между Org VDC. Однако состояние не сохраняется в случае, когда используется импорт и экспорт OVF. Это также относится к миграции Org VDC между экземплярами vSphere.
Изменять размер можно только у SCSI-дисков. Расширение гостевого раздела не выполняется. Диски не могут быть уменьшены. Изменение размера диска во время развертывания из каталога в Org VDC с поддержкой быстрой инициализации приводит к созданию полного клона с гораздо меньшим временем развертывания.
Ограничения VMware Cloud Director
При подготовке к практической эксплуатации стоит обратить внимание на ограничения и особенности конфигурирования VMware Cloud Director, которые накладываются на следующие виртуальные объекты:
Виртуальный ЦОД.
Платформа виртуализации.
Виртуальные сети.
Виртуальные машины.
Рассмотрим детали каждого виртуального объекта.
Ограничения и особенности виртуального ЦОДа
Виртуальные процессорные ядра |
В одном виртуальном ЦОДе можно использовать ядра CPU только с одинаковой частотой. Необходимо, чтобы виртуальные ядра CPU обслуживались процессорами одного типа. |
|---|---|
Виртуальная оперативная память |
Требуемый объем vRAM дополнительно учитывайте при определении размера виртуальных дисков выбранного профиля для размещения swap-файлов виртуальных серверов. Минимальное значение vRAM для виртуального ЦОДа — 1 ГБ. |
Виртуальные диски |
При определении размера виртуальных дисков отдельно учитывайте требуемый объем дискового пространства для размещения swap-файлов виртуальных серверов. |
Скорость доступа в интернет |
По умолчанию предоставляется безлимитный доступ в интернет в общем канале на скорости до 100 Мбит/с. Доступно также подключение через выделенный гарантированный канал на скорости до 1000 Мбит/с. Заданная скорость гарантируется внутри транспортной сети Cloud.ru, т.е. от порта пограничного маршрутизатора узла связи Cloud.ru. |
Подключение к сервису в облаке через интернет — NAT |
По умолчанию выделяется один IP-адрес. Для публикации нескольких приложений с одинаковыми портами TCP (80, 443 и т.д.) необходимы дополнительные IP-адреса. Для приложений с динамически выделяемыми портами (FTP, SIP, H.323 и т.д.) могут возникнуть проблемы с недоступностью сервиса. Необходимо фиксировать диапазон динамически выделяемых портов в настройках приложения и прописывать их в правилах DNAT. Альтернативный вариант — выделить один IP-адрес на сервис и настроить правило Static DNAT. |
Подключение к сервису в облаке через IPsec VPN |
Необходимо наличие сетевого оборудования с поддержкой IPsec VPN. На одном Edge Tier-1 можно организовать до 25 IPsec-тоннелей. |
Выделенное L2-подключение |
Для разворачивания требуется участие операторов облачного провайдера. Возможность настроить подключение самостоятельно через VMware Cloud Director отсутствует. Максимальная производительность подключения — 10 ГБ/с. Для максимальной утилизации подключения значение MTU на всем пути следования трафика должно быть не менее 9000 байт. |
Distributed Firewall (DFW) |
По умолчанию функция недоступна, ее необходимо подключить отдельно. |
Конфигурация Edge Gateway |
По умолчанию — Compact. Применяется для создания небольших вычислительных сред с малым количеством сервисов. Если необходимо обрабатывать большое количество сетевых функций, можно изменить конфигурацию на Large, Quad-Large, X-Large. |
Ограничения и особенности платформы виртуализации
Максимальное количество пользователей на один тенант |
7500 |
|---|---|
Максимальное количество VM на один vApp |
128 |
Максимальное количество vApp на один тенант |
5000 |
Максимальное количество виртуальных ЦОДов в одной группе DCG |
16 |
Максимальное количество локальных сетей в одной группе DCG |
200 |
Максимальное количество правил NAT на один Edge Gateway |
8192 |
Максимальное количество правил Edge Gateway Firewall на один Edge Gateway |
5000 |
Максимальное количество правил Distributed Firewall на один NIC |
4000 |
Максимальное количество IP-адресов на один IP Set |
4000 |
Дополнительно вы можете ознакомиться с поддержкой кастомизации операционных систем в виртуальных машинах в документации платформы Облако VMware.
Ограничения и особенности виртуальных сетей
ORG VCD Network |
|
|---|---|
DHCP |
|
DHCP Binding |
|
DHCP Relay |
|
DHCP-сервер на VM |
По умолчанию сообщения DHCPACK (запрос на получение IP-адреса) и DHCPOFFER (предложение сервера) запрещены политикой безопасности платформы виртуализации. Для включения данного типа трафика обратитесь в техническую поддержку. |
Distributed Firewall (DFW) |
Для получения доступа обратитесь в техническую поддержку. |
Edge Gateway Firewall |
|
SNAT |
|
DNAT |
|
IPSec VPN с типом сессий policy-based |
|
IPSec VPN с типом сессий route-based |
Для настройки обратитесь в техническую поддержку. |
L2 VPN |
|
Load Balancer |
Для настройки обратитесь в техническую поддержку. Если у вас есть доступ к Личному кабинету Cloud, воспользуйтесь инструкцией Настройка Load Balancers. |
Shared network / Data Center Groups (DCG) |
Настройка общей локальной сети (DCG). Для получения доступа к DCG обратитесь в техническую поддержку. |
Static Routes |
Для настройки обратитесь в техническую поддержку. |
Ограничения и особенности виртуальных машин
Ограничениям, накладываемым на виртуальные машины и особенностям конфигурирования в VMware Cloud Director, посвящена отдельная ветвь документации.
для Dev & Test