История вопроса: Enhanced Linked Mode для объединения vCenter
Во многих средах виртуализации VMware требуется единовременно управлять несколькими экземплярами vCenter Server, например при распределении нагрузки по разным датацентрам или кластерам. Исторически для этой цели использовался механизм Enhanced Linked Mode (ELM) – так назывемый «расширенный связанный режим» vCenter. ELM позволяет связать несколько серверов vCenter в рамках единого домена Single Sign-On, благодаря чему администратор может войти в один клиент vSphere и получить единый интерфейс управления всеми связанными vCenter.
При классическом ELM до 15 экземпляров vCenter Server могли быть объединены в одну группу, используя общую базу SSO для аутентификации и репликации данных конфигурации. Это означало единые учетные записи и права: достаточно один раз настроить пользователя или добавить лицензию – и эти данные реплицировались между всеми связанными vCenter в домене SSO. Например, роли, тэги, глобальные разрешения, политики хранения и прочие объекты, созданные на одном vCenter, автоматически становились доступными на других системах в связанной группе благодаря репликации каталогов VMware Platform Services Controller (PSC). Таким образом, Enhanced Linked Mode значительно упрощал жизнь администраторам, предоставляя «единую консоль» для нескольких vCenter и устраняя дублирующие настройки на каждом экземпляре.
Однако у подхода ELM существовали и ограничения. Во-первых, настроить связанный режим можно было только при развертывании vCenter – в процессе установки следовало либо создать новый домен SSO, либо присоединиться к существующему (что и объединяло vCenter с уже установленным экземпляром). Присоединить к домену SSO уже работающий vCenter задним числом было непростой задачей (требовались утилиты cmsso для изменения конфигурации). Во-вторых, надежность и масштабируемость ELM имели пределы: официально поддерживалось до 15 vCenter в одном домене, при большем числе производительность и стабильность могли ухудшаться. Репликация данных SSO между узлами PSC происходила периодически (примерно каждые 30 секунд), и при сбоях сети или несинхронности времени возникали проблемы рассинхронизации. Любые неполадки с доменом SSO (службой VMware Directory) затрагивали сразу все связанные vCenter. Кроме того, ранее для реализации ELM часто требовались внешние контроллеры PSC и балансировщики нагрузки, что усложняло архитектуру. Хотя начиная с vSphere 7.0 PSC встроен, а Enhanced Linked Mode поддерживается и с Embedded PSC, весь механизм ELM остаётся наследием старой архитектуры, требующим тщательного планирования обновлений (все связанные vCenter должны быть совместимых версий SSO) и создающим жесткую связанность между компонентами.
Нововведения VMware Cloud Foundation 9: единый SSO и отказ от ELM
С выходом VMware Cloud Foundation 9.0 произошёл переломный момент в подходе к связыванию vCenter. VCF 9 вводит принципиально новую архитектуру единого входа (Single Sign-On) для всех компонентов частного облака, устраняя необходимость в классическом ELM для объединения серверов vCenter. Фактически, в окружениях на базе VCF 9 Enhanced Linked Mode более не используется для объединения vCenter в единый домен SSO. Поддержка ELM в vCenter 9.0 сохранена лишь для целей совместимости при обновлении существующих инфраструктур, но в самом VMware Cloud Foundation 9 единое управление несколькими vCenter теперь реализовано иным способом – через сервисы VCF Operations и группировку vCenter.
Главным двигателем этих изменений стал VCF Identity Broker – новый компонент VMware Cloud Foundation 9, обеспечивающий современный механизм SSO для всей платформы. Он предоставляет единый вход для всех ключевых интерфейсов администрирования: консоли VCF Operations, клиента vSphere, интерфейса NSX Manager и других. То есть администратор, единожды прошедший аутентификацию через VCF SSO, может бесшовно переключаться между разными инструментами управления облаком.
Новая система основана на брокере идентификации (VCF Identity Broker, VIDB) и поддерживает интеграцию с широким спектром внешних провайдеров удостоверений. В частности, поддерживаются современные протоколы и каталоги, такие как Active Directory/LDAP, федерация AD (ADFS), Azure AD (Entra ID), Okta, Ping Identity, а также любые совместимые SAML 2.0 провайдеры. Это позволяет организациям легко привязать Cloud Foundation к своей корпоративной системе управления учетными записями и даже включить многофакторную аутентификацию.
Новая архитектура SSO в VCF 9 работает по модели федерации: вместо единого домена vSphere SSO, как это было при ELM, используется внешний брокер, доверенный всеми компонентами. За счёт этого отпадает необходимость «связывать» сами vCenter на уровне службы каталогов – достаточно, что у них настроен общий внешний источник идентификации (IdP). Стоит подчеркнуть: VCF 9 не поддерживает Enhanced Linked Mode напрямую, однако благодаря единому SSO более в нём и нет нужды, чтобы получить общий доступ ко всем окружениям через один клиент. Вместо ELM появилась упрощённая функция группировки vCenter на уровне VCF, которая и обеспечивает единое представление нескольких vCenter в интерфейсе vSphere Client.
Отказ от классического ELM продиктован стремлением упростить архитектуру и повысить надёжность управления облаком. Теперь компоненты vSphere не объединяются «напрямую» в единый домен – вместо этого ими централизованно "заведует" VCF Operations, распределяя аутентификацию через брокер. Это снижает связанность между vCenter: сбой одного сервиса не парализует всю связку, как могло быть с ELM. Кроме того, снимаются ограничения старого подхода – новый механизм группировки рассчитан на будущий рост и масштабируемость в рамках «флота» (fleet) vCenter, управляемого Cloud Foundation. Компания Broadcom прямо указывает, что следует переходить от ELM к новым механизмам управления. В документации по VCF 9 рекомендуется не планировать развертывание новых связанных групп vCenter с ELM, а при обновлении существующих инфраструктур конвертировать каждый vCenter в автономный режим и использовать группировку через VCF Operations. Функции, которые ранее обеспечивались Enhanced Linked Mode – единый SSO, синхронизация ролей и тэгов, единая точка API и т.д. – теперь реализованы на уровне VCF Operations и сопутствующих сервисов. Иными словами, Cloud Foundation берёт на себя задачи по объединению информации из разных vCenter, избавляя от необходимости поддерживать устаревший механизм PSC/ELM.
Настройка единого SSO (VCF Identity Broker) в Cloud Foundation 9
VMware Cloud Foundation 9 вводит новую консоль управления – VCF Operations, через которую осуществляется настройка всех сервисов, в том числе и единого SSO. Начальный шаг для организации единого входа – развертывание брокера идентификации (VCF Identity Broker, VIDB) и подключение каталога пользователей. Cloud Foundation позволяет выполнить это в одном из двух режимов:
Встроенный (embedded) – брокер запускается непосредственно на управляющем vCenter в домене управления VCF. Этот вариант подходит для небольших развёртываний Cloud Foundation (например, один экземпляр VCF, один vCenter управления и несколько доменов рабочих нагрузок), где не требуется масштабирование на множество площадок.
Внешний кластер (appliance) – брокер развертывается как отдельный кластер из трёх виртуальных модулей (для отказоустойчивости). Такой вариант рассчитан на крупные инфраструктуры: внешний VIDB способен обслуживать до пяти экземпляров VCF одновременно, объединяя их в единое пространство идентификации. Использование отдельного кластера повышает масштабируемость и надёжность (отказ одного узла не нарушит работу SSO).
При включении VCF SSO мастер настройки предложит выбрать режим и развернуть брокер. Далее администратор указывает, какой провайдер удостоверений использовать. Как отмечалось, доступен широкий выбор: от классической интеграции с Active Directory/LDAP до федерации через SAML 2.0 провайдеры. VCF 9 расширил перечень поддерживаемых IdP: помимо ранее доступных Okta, Microsoft Entra ID (Azure AD) и Active Directory Federation Services, добавлена поддержка Ping Identity и сторонних SAML-провайдеров. В каждом случае есть нюансы по определению групп и пользователей, которым будет позволен вход – продуктовая документация описывает их подробно (например, для LDAP можно выбрать группы безопасности AD, для SAML – использовать SCIM или Just-In-Time provisioning). Важно спланировать, какие группы или аккаунты из корпоративного каталога будут наделены правами администратора Cloud Foundation, и настроить их соответствующим образом на стороне IdP.
Настроив подключение к внешнему каталогу и развернув Identity Broker, администратор может включить единый вход (SSO) для компонентов Cloud Foundation. VCF Operations значительно упрощает эту задачу: достаточно перейти в раздел Identity & Access (Идентификация и доступ) и выполнить Component Configuration – указать, какие именно системы следует привязать к общему SSO. В случае базовых инфраструктурных компонентов – vCenter Server и NSX Manager – активация сводится к установке флажка напротив них в консоли VCF Operations.
Можно сразу включить SSO для нескольких сервисов пакетно – настройка займёт считанные минуты. Фактически, VCF под капотом регистрирует ваш брокер как доверенного Identity Provider для vCenter и NSX (и других сервисов, если требуется), после чего эти компоненты начинают принимать федеративную аутентификацию.
После успешной конфигурации SSO возникает завершающий шаг – назначение ролей и прав доступа пользователям из нового источника. Поскольку ранее vCenter жили каждый в своём изолированном SSO-домене, права для внешних пользователей там не были заданы. Теперь, когда Identity Broker привязан, нужно зайти на каждый компонент под его локальной учетной записью администратора (например, administrator@vsphere.local для vCenter) и выдать необходимым группам/пользователям из каталога соответствующие роли.
Это разовое действие: к примеру, вы можете назначить группе администраторов из AD роль CloudAdmin в VCF Operations, роль Administrator в каждом vCenter, и соответствующую роль Enterprise Admin в NSX Manager. После этого члены данной группы смогут входить через единый SSO и получать административный доступ ко всем компонентам без использования локальных учётных записей.
Совет: на данном этапе рекомендуется перестать использовать общую учётную запись admin/administrator@vsphere.local для повседневной работы. Вместо этого каждому инженеру выделяется персональный аккаунт (например, в Active Directory) с соответствующей групповой принадлежностью, и вход выполняется через корпоративный IdP. Это повышает безопасность (можно задействовать MFA, проводить аудит действий по именам) и устраняет необходимость распространять пароли от локальных админов среди команды.
После того как SSO настроен и роли назначены, Cloud Foundation 9 фактически предоставляет единое пространство идентификации. Администратор может зайти в консоль VCF Operations под своим корпоративным логином и оттуда в один клик переходить в vSphere Client или NSX – повторная аутентификация не потребуется. Теперь пришло время объединить сами vCenter Server в группы для удобного управления.
vCenter Server Linking в VCF 9
Настроив механизм единого входа, мы получаем возможность реализовать новый подход к "связыванию" vCenter – через VCF Operations. В Cloud Foundation 9 для этого введено понятие групп vCenter (vCenter Groups). Группа vCenter – это логическое объединение двух или более экземпляров vCenter Server, которое настраивается на уровне VCF и позволяет просматривать их вместе в интерфейсе vSphere Client. По сути, это и есть функциональный аналог прежнего Enhanced Linked Mode – только реализованный непосредственно в VMware Cloud Foundation и без нужды объединять SSO-домены вручную.
Настройка группировки vCenter выполняется через консоль VCF Operations 9.0. В разделе Infrastructure Operations откройте вкладку Configurations и выберите плитку vCenter Linking.
Далее нажмите Create Group и запустите мастер настройки. В мастере достаточно выбрать из списка те vCenter Server, которые вы хотите связать воедино. Все vCenter, добавляемые в одну группу, должны использовать общий провайдер идентификации (Identity Broker), настроенный на предыдущем этапе. Иными словами, они уже должны быть подключены к VCF SSO – в противном случае консоль попросту не позволит их сгруппировать.
Дайте группе понятное имя (например, по названию проекта или площадки) и подтвердите ее создание. VCF Operations автоматически произведёт все необходимые действия «за кадром» – после этого экземпляры vCenter, входящие в группу, будут считаться связанными.
Когда группа vCenter создана, можно проверить результат. Войдите в vSphere Client под учётной записью VCF SSO – т.е. используя вариант авторизации через ваш настроенный IdP, а не локальный аккаунт vsphere.local. После успешного входа вы увидите знакомую картину: в левой панели vSphere Client отобразятся несколько vCenter Server сразу, в едином дереве навигации. Например, ниже показан фрагмент интерфейса, где присутствуют сразу два экземпляра: управляющий mgmt-vcenter и vCenter из домена рабочей нагрузки wld01-vcenter – оба доступны для обзора и управления через одну консоль.
Обратите внимание: если войти под локальной учётной записью конкретного vCenter (например administrator@vsphere.local данного экземпляра), то вы не увидите другие системы – интерфейс покажет только данный vCenter, как это было раньше. Поэтому для использования сквозного обзора всегда применяйте вход через общий брокер (федерацию). Кроме того, необходимо, чтобы пользователь (или группа), под которым вы заходите, имел соответствующие права админа на всех связанных vCenter. Если в каком-то из vCenter вашему аккаунту не выданы права – этот экземпляр не отобразится в списке (либо будет виден только для чтения). Поэтому рекомендуется заранее, как упоминалось, наделить ваши группы безопасности нужными ролями во всех vCenter, включенных в группу.
В остальном поведение среды при связке через VCF 9 почти неотличимо от классического ELM. Вы можете просматривать объекты инвентаря (кластеры, хосты, ВМ и т.д.) на всех vCenter, переключаясь между ними в навигационном дереве. Многие глобальные операции vSphere (клонирование ВМ между vCenter, миграция рабочих нагрузок, объединённый поиск и т.п.) доступны так же, как и при старом добром Linked Mode – благодаря тому, что у вас единая точка входа и единая аутентификация. Тем не менее, реализация “под капотом” отличается, поэтому некоторые действия потребуют выбора конкретного vCenter.
Например, при развёртывании новой ВМ или создании распределенного коммутатора система сначала попросит указать, в каком именно vCenter (из доступных вам) нужно выполнить операцию. Это логично, учитывая что теперь каждый vCenter остаётся самостоятельным объектом (со своим SSO-доменом), а VCF обеспечивает лишь уровень агрегации. Воспримите группу vCenter в VCF 9 как удобный «связующий слой», убирающий лишнюю аутентификацию и позволяющий просматривать несколько сред вместе, но не склеивающий их в монолит.
Стоит также отметить, что связывание vCenter через VCF Operations гибче, чем ELM. Вы сами определяете группы и состав vCenter в них. Теоретически возможно создать несколько групп из разных поднаборов vCenter (например, для разных команд администрирования). Однако чаще всего в одной VCF-инфраструктуре администраторы формируют единую группу, включающую все vCenter данного экземпляра VCF, чтобы видеть весь парк серверов сразу. Ограничений на число групп или число vCenter в группе в официальных материалах не указано – новая архитектура рассчитана на масштабирование под крупные облачные развертывания.
Лучшие практики и рекомендации по миграции с ELM
Переход на VMware Cloud Foundation 9 открывает новые возможности упрощения управления, но требует и планирования миграции существующих сред с Enhanced Linked Mode. Ниже приведены рекомендации для системных инженеров, которые внедряют VCF 9 или обновляют до него инфраструктуру, где ранее использовался ELM:
Не используйте ELM в новых развёртываниях VCF 9. При проектировании новой инфраструктуры на Cloud Foundation 9 не планируйте объединять vCenter через старый механизм Linked Mode – в этом нет необходимости, и это не поддерживается штатными средствами VCF. Вместо этого сразу закладывайте интеграцию с корпоративным IdP и использование группировки через VCF Operations. Если вы развернули несколько vCenter в составе VCF 9, оставьте их в отдельных доменах SSO по умолчанию – централизованный SSO обеспечит Identity Broker.
Распланируйте интеграцию с каталогами пользователей. На этапе внедрения VCF 9 особое внимание уделите настройке VCF Identity Broker. Решите, будете ли вы использовать встроенный или внешний (отдельный) брокер – исходя из размеров вашей инфраструктуры и числа экземпляров VCF. Для крупного распределённого окружения выберите развёртывание отдельного кластера VIDB. Заблаговременно подготовьте среды Active Directory/LDAP или учетные записи в SAML-провайдере, которые станут источником прав для ваших администраторов. Лучшей практикой является создание одной или нескольких групп в AD (например, CloudAdmins или VCF-Operators) и назначение им требуемых ролей в VCF Operations, vCenter и NSX. Так вы сможете централизованно управлять составом админов через Active Directory, не раскрывая всем общий пароль. Использование федерации с MFA также повысит безопасность.
Миграция существующих связанных vCenter на новую модель. Если вы обновляете имеющуюся инфраструктуру с ELM до Cloud Foundation 9, необходимо провести конвертацию каждого vCenter в автономный режим. Проще говоря, перед (или сразу после) обновления vCenter до версии, входящей в VCF 9, нужно «разлинковать» старую группу ELM. Для этого один из подходов – использовать утилиту cmsso-util unregister на каждом vCenter, чтобы вывести его из общего домена SSO и создать отдельный встроенный домен для каждого (операция аналогична Convergence при отказе от внешнего PSC). VMware рекомендует после перехода на VCF 9 настроить группировку vCenter через VCF Operations вместо прежнего ELM. Имейте в виду, что поддержка ELM в vCenter 9.0 оставлена лишь временно, и в будущих версиях vCenter эта возможность будет полностью удалена. Поэтому перевод связанных vCenter в раздельные домены – шаг на опережение, который избавит вас от legacy-составляющей и облегчит дальнейшие апгрейды.
Сопоставьте глобальные объекты ELM с новой средой. В старой конфигурации ELM у вас могли быть настроены глобальные роли, теги, категории, библиотеки контента и другие сущности, общие для всех vCenter. После разделения доменов SSO эти объекты перестают автоматически реплицироваться. Новая платформа VCF 9 пока не предлагает «из коробки» мгновенной синхронизации тегов или ролей между vCenter (эти функции в разработке и могут появиться в будущих обновлениях). Поэтому перед расформированием ELM экспортируйте необходимые настройки: например, списки ролей и привилегий (есть PowerCLI-скрипты для экспорта/импорта ролей между vCenter), файл тэгов/папок (можно выгрузить через vSphere API), контент-библиотеки (переведите их в подписываемые, чтобы один vCenter выступал источником для других). После обновления и создания группы vCenter в VCF, импортируйте или воссоздайте важные глобальные объекты на каждом экземпляре, либо используйте возможности VCF/Aria для централизованного управления ими. Например, Cloud Foundation 9 располагает централизованным менеджером лицензий – достаточно единожды загрузить лицензионный файл в VCF Operations, и лицензии автоматически применятся ко всем компонентам стека (в этом плане новая модель даже удобнее ELM, где лицензии реплицировались, но добавлять их приходилось вручную на одном из vCenter).
Обучите команду новым процедурам. Переход на единую федеративную авторизацию может потребовать обновления операционных инструкций. Убедитесь, что все инженеры знают: для доступа ко всем vCenter теперь нужно входить через провайдер SSO Cloud Foundation (т.е. через корпоративный аккаунт), а не локальные учётные записи vCenter. Также админы должны понимать, что некоторые операции в интерфейсе vSphere потребуют выбора контекста vCenter (как упоминалось ранее). В целом освоение новой модели несложно, но в начальный период следует уделить внимание правильности входа и выдачи прав.
Следите за обновлениями и известными проблемами. Поскольку функция vCenter Linking в VCF 9 ещё относительно новая, рекомендуется отслеживать выпуск патчей и Known Issues от VMware. На форуме Broadcom Communities обсуждался, например, случай, когда при определённых сценариях несколько экземпляров VCF с общим брокером идентификации не могли быть сгруппированы напрямую – в будущем такие нюансы, скорее всего, будут устранены. Проверяйте раздел Product Support Notes в документации Cloud Foundation 9 перед обновлением, чтобы не столкнуться с сюрпризами. И конечно, поддерживайте резервные копии каждого vCenter отдельно: новый механизм Linking не избавляет от необходимости бэкапить базы каждого vCenter (он лишь объединяет их в интерфейсе).
Заключение
VMware Cloud Foundation 9 привносит качественно новый подход к интеграции и управлению несколькими экземплярами vCenter Server. Вместо устаревшего Enhanced Linked Mode с его сложностями и ограничениями приходит единый брокер идентификации и группировка vCenter на уровне VCF Operations. Для системных инженеров это означает более простую архитектуру (без внешних PSC и связующих доменов), более гибкое подключение к корпоративным каталогам пользователей и улучшенную безопасность за счёт отказа от общих учётных записей.
Хотя Enhanced Linked Mode формально ещё поддерживается в vSphere 8.x/9.0 для совместимости, курс VMware очевиден – федеративный SSO и централизованное управление заменят его полностью. Уже сегодня Cloud Foundation 9 демонстрирует все преимущества этого перехода: единый вход для всех компонентов (VCF, vCenter, NSX и пр.), единая точка контроля лицензий, сквозной обзор нескольких сред vCenter без усложнения их внутренней структуры. Для администраторов это означает меньше рутины при входе и настройке прав, а также возможность масштабировать инфраструктуру, не беспокоясь о потолке в 15 связанных vCenter.
При внедрении VCF 9 важно тщательно спланировать миграцию с учётом рекомендаций: разорвать старые ELM-связи, настроить брокер идентификации, распределить права и сгруппировать vCenter через VCF Operations. Результатом будет современная, безопасная и управляемая «флотилия» vCenter Server, готовая к росту. Cloud Foundation 9 даёт системным инженерам "один вход, чтобы управлять всеми vCenter" – и, судя по отзывам, это действительно упрощает операционную деятельность. Настало время попрощаться с Enhanced Linked Mode и воспользоваться новым «сверхсвязанным» режимом в полном объёме.
RSS
