Linked mode vmware что это
I think most of you out there will love managing your VMware Infrastructure using a single management console. And you can do this with VMware vCenter Linked Mode. Think of it like this: you have different regions/sites, and in every one of them different vCenter servers, which means multiple consoles opened on your desktop. You can reduce this to only one console, by linking the vCenter servers together; and this is what I’m going to show you today.
A single vCenter can manage 300 ESX host with 3000 virtual machines, but using linked mode can manage 1000 ESX hosts with 10000 virtual machines. As you can see having a single management console for multiple vCenter servers is not the only reason to linked them together. However, to do this you need to have the proper license, because is not going to work with Foundation or Essential Edition. More information about the Linked Mode prerequisites can be found here. Before I start I need to mention one more thing, I you have multiple forests or domains in your environment, trust needs to be created between them.
For this lab I have three VMware vCenter 5 servers that are all part of a single domain, and all traffic is allowed between the servers. To start on one of the vCenter servers open the linked mode configuration wizard from Start > All Programs > VMware > vCenter Server Linked Mode Configuration.
The VMware vCenter wizard will appear. Click Next to skip the Welcome screen and continue.
Since we want to link our vCenter servers, we are going with the default option here which is Modify linked mode configuration.
Again we are going with the default selection here, so click Next to continue.
A warning is displayed telling us that older versions of vCenter servers are not supported. We can only link version 5 or later servers in this configuration.
In the server box, type the FQDN of the remote vCenter server and click Next. Leave the default port, but make sure that your firewall permits traffic on this port.
To start configuring the link just click Continue.
At the end you will be notified if the installation succeeded. Click Finish to close the wizard.
Open the vSphere client and connect to one of the linked vCenter servers. Now you can manage both servers using a single console. Great haaa.
Now let’s link a third vCenter server, by running the wizard again. Almost forgot, you need to do this from the vCenter server that is not linked. If you run the wizard from one of the already linked servers is not going to work; you will only have the option to isolate the server instance but not to join one, since those servers are already joined.
Log on to the third server and go to Start > All Programs > VMware > vCenter Server Linked Mode Configuration. When you get to the point where you need to put the vCenter server FQDN address, you have two options here. You can type the address of the first vCenter server or the second one, it doesn’t matter. For the sake of this example I will type the address of my second vCenter server, because I typed the first one when I’ve made the first link.
After the link is done, open the vShpere Client and connect to any one of these three servers we just linked. And voilà…everything worked out just fine. We have our three vCenter in Linked Mode.
Delphi site: daily Delphi-news, documentation, articles, review, interview, computer humor.
vCenter версии 4 позволяет объединять несколько серверов vCenter в группу. Подключившись к одному серверу vCenter из такой группы, мы можем видеть и управлять объектами каждого сервера vCenter из группы. Это очень удобно, если у вас есть несколько серверов vCenter. Например, отдельные серверы для производственной и тестовой инфраструктур или разные vCenter в разных ЦОД компании.
Подключить сервер vCenter к группе можно как на этапе установки, так и в произвольный момент позже.
Серверы vCenter, объединенные в группу, используют децентрализованную систему совместной работы (Peer-to-Peer). Если один сервер vCenter может обслуживать до 1000 серверов ESX(i) и 10 000 включенных ВМ (рекомендательное ограничение), то до десяти vCenter в одной группе Linked Mode позволят вам мониторить и управлять до 3000 серверами ESX(i) и 30 000 ВМ.
Обратите внимание: эту возможность включает только vCenter Server с лицензией «Standard». То есть vCenter Server Foundation не получится добавить в группу Linked Mode.
В объединенной таким образом инфраструктуре вам доступны:
1) назначение глобальных ролей - то есть раздача прав по всей инфраструктуре;
2) глобальный поиск объектов;
3) управление всеми лицензиями.
Выглядит это так (рис. 1.9):
Рис. 1.9. Работа с несколькими vCenter в одном окне Для хранения и синхронизации данных между экземплярами vCenter Server в группе Linked Mode использует Microsoft Active Directory Application Mode (ADAM). Сегодня ADAM известен как Microsoft Active Directory Lightweight Directory Services (AD LDS). ADAM устанавливается автоматически при установке vCenter Server. Каждый экземпляр ADAM хранит данные всех серверов vCenter одной группы. Эти данные содержат:
- информацию для соединения - IP-адреса и номера портов;
- сертификаты и их отпечатки (Thumbprints);
Один раз в день данные из ADAM выгружаются в резервную копию, которая хранится в БД сервера vCenter. В случае повреждения ADAM vCenter будет использовать данные из последней резервной копии для его восстановления.
Подключить vCenter к группе Linked Mode можно как на этапе установки, так и в любой другой момент. Пользователь, который запускает процесс присоединения сервера vCenter к группе, должен обладать правами локального администратора и на локальной системе, и на системе (системах), где установлены прочие серверы vCenter этой группы.
Требования к инфраструктуре следующие.
Все серверы vCenter должны находиться в одном домене AD или в разных доменах с двухсторонними доверительными отношениями. Само собой, важна правильная настройка синхронизации времени и DNS.
Но vCenter Server не должен быть установлен на контроллере домена - это воспрепятствует его добавлению в группу. Также не получится добавить vCenter в группу, если он установлен на терминальном сервере.
Если вы хотите объединить в группу несколько (например, три) серверов vCenter на этапе их установки, то ваши действия следующие.
1. Установить первый из них. Так как на этом этапе он является единственным, никакой группы для него не указываем.
2. Установить второй, когда установщик задаст вопрос про Linked Mode - указать FQDN сервера с первым vCenter. Теперь первые два vCenter в группе.
3. Третий vCenter, предположим, мы не устанавливаем с нуля, а обновляем с Virtual Center 2.5 до vCenter 4. Наши действия - сначала обновить, затем добавить к группе, указав FQDN первого или второго сервера vCenter.
Теперь все три сервера vCenter принадлежат одной группе.
Если вы хотите добавить к группе уже установленный vCenter, то это также весьма не сложно: Start ^ All Programs ^ VMware ^ vCenter Server Linked Mode Configuration.
Выберите пункт Modify Linked-Mode configuration и укажите FQDN любого сервера vCenter, в группу с которым вы хотите добавить текущий.
Для удаления сервера vCenter из группы следует воспользоваться приложением «Programs and Features» (Программы и компоненты) или «Add or Remove program» (Установка и удаление программ) для Windows Server 2008 или бо лее ранних версий соответственно. Выбрать там VMware vCenter Server, нажать Change и в мастере отказаться от членства в группе Linked Mode.
Прочие подробности, рекомендации и инструкции см. в актуальной версии «ESX and vCenter Server Installation Guide».
Delphi site: daily Delphi-news, documentation, articles, review, interview, computer humor.
Идея их заключается в следующем: в случае использования стандартных вКоммутаторов у вас разные (пусть очень часто и идентично настроенные) виртуальные коммутаторы на каждом сервере. Акцент я хочу сделать вот на чем: создать и поддерживать эту, пусть даже идентичную, конфигурацию придется вам. При необходимости, например, создать еще одну группу портов для еще одного VLAN вам потребуется повторить это простое действие на всех серверах ESX(i).
А в случае создания распределенного коммутатора вы получаете один-един-ственный (логически) коммутатор, существующий сразу на всех серверах ESX(i).
Вы настраиваете только этот, логически единый коммутатор. Новую группу портов из примера выше вы создадите один раз, и она появится для всех серверов ESX(i), входящих в распределенный коммутатор.
ВМ, даже при миграции с сервера на сервер, остаются не только на том же коммутаторе, но и даже на том же порту распределенного виртуального коммутатора (это называют Network vMotion). Это позволяет проще настраивать политики безопасности, осуществлять мониторинг трафика ВМ, привязываясь даже к отдельному порту вКоммутатора.
В отличие от стандартных виртуальных коммутаторов VMware, distributed vSwitch поддерживают Private VLAN и двухсторонний traffic shaping (о том, что это такое, см. в разделах 2.4.2 и 2.4.4). В версии 4.1 в список уникальных возможностей распределенных коммутаторов добавились такие функции, как:
- Network IO Control - возможность гибко настраивать минимально и максимально доступные ресурсы пропускной способности для трафика разных типов. Подробности о NIOC см. в главе 6, посвященной распределению ресурсов;
- Load Based Teaming - балансировка нагрузки между физическими контроллерами одного вКоммутатора в зависимости от нагрузки на каждый контроллер.
Еще один плюс - распределенный вКоммутатор доступен в реализациях от VMware и от Cisco.
Вариант от Cisco, распределенный виртуальный коммутатор Cisco Nexus 1000V, приобретается независимо от vSphere (но подойдет не любая лицензия vSphere, на момент написания - только Enterprise Plus). Он обладает всеми возможностями, присущими сетевому оборудованию от Cisco. Позволяет добиться того, что все используемые коммутаторы в сети компании созданы одним производителем (здесь имеется в виду Cisco), и сетевые администраторы могут управлять ими точно так же, как коммутаторами физическими, снимая, таким образом, эти задачи с администратора vSphere. Однако рассмотрение настроек и возможностей этого решения в данной книге описано не будет.
Здесь будет описан распределенный виртуальный коммутатор от VMware. Возможность им пользоваться появляется после активации лицензии, дающей на него право, - сегодня это vSphere Enterprise Plus (и ее ознакомительный 60-дневный период после установки vSphere, Evaluation-лицензия).
Как я уже сказал, dvSwitch - объект скорее логический, как таковой существующий только для vCenter. Мы создали один распределенный вКоммутатор, но на каждом сервере, для которых он существует, автоматически создаются стандартные вКоммутаторы, скрытые от нас (рис. 2.11). Таким образом, де-факто распределенный коммутатор является шаблоном настроек. Мы создаем его и указываем настройки в vCenter - это control plane по документации VMware, то есть уровень управления. А после включения в созданный распределенный коммутатор серверов ESX(i) vCenter создает на них стандартные коммутаторы, скрытые от нас. По документации VMware это IO Plane, прикладной уровень. За всю работу отвечают скрытые коммутаторы на серверах ESX(i), все управление осуществляется только через vCenter.
Рис. 2.11. Иллюстрация сути распределенного виртуального коммутатора Источник: VMware
Минусом такой схемы распределенного виртуального коммутатора VMware является возросшая сложность, в частности зависимость от vCenter. vCenter является управляющим элементом для dvSwitch, и при недоступности vCenter у администратора нет возможности менять настройки распределенного коммутатора и даже переключать виртуальные машины на другие группы портов. Однако даже при недоступности vCenter сеть будет продолжать работать - ведь за техническую сторону вопроса отвечают скрытые от нас коммутаторы на каждом ESX(i), теряется только возможность изменения настроек.
Кстати, подключение самого vCenter к распределенному коммутатору не поддерживается VMware.
Подключитесь клиентом vSphere к vCenter. Предполагается, что в иерархии vCenter уже создан объект Datacenter, уже добавлены серверы. Распределенный виртуальный коммутатор создается для объекта Datacenter, и существовать для серверов из разных Datacenter один dvSwitch не может.
Пройдите Home ^ Networking. В контекстном меню объекта Datacenter выберите пункт New vNetwork Distributed Switch.
В запустившемся мастере нас спросят:
- Name - имя создаваемого вКоммутатора. Влияет только на удобство;
- Number of dvUplink ports - максимальное количество подключений ко внешней сети - привязанных vmnic - на каждом сервере. Обратите внимание: один такой вКоммутатор может существовать для серверов с разной конфигурацией, с разным количеством доступных сетевых контроллеров -а здесь мы ограничиваем максимальное число используемых для данного dvSwitch контроллеров на одном сервере;
- дальше вам предложат выбрать серверы, для которых будет существовать создаваемый вКоммутатор. Выбор можно осуществить или изменить позже. Если будете выбирать серверы сейчас, то вам покажут свободные физические сетевые контроллеры на каждом выбранном сервере - и вы сможете выбрать те из них, что будут использоваться для создаваемого вКоммута-тора. По ссылке View Details вам покажут исчерпывающую информацию о физическом сетевом контроллере - драйвер, производитель, статус подключения (link status), PCI-адрес, доступные через него подсети IP - не покажут здесь только MAC-адрес;
- на последнем шаге можно будет снять флажок Automatically create a default port group. Если он стоит, то автоматически будет создана группа портов со 128 портами и именем по умолчанию. Имя по умолчанию малоинформативно, поэтому я рекомендую этот флажок снимать и создавать группу портов самостоятельно, после создания вКоммутатора.
Обратите внимание. У стандартных вКоммутаторов число портов настраивается для них самих, группы портов «безразмерные». У распределенных вКоммутаторов наоборот. Вы можете создать до 248 распределенных виртуальных коммутаторов для сервера. На одном сервере может быть до 4096 портов стандартных и распределенных вКоммутаторов. Это означает, что если не задавать заведомо огромных значений числа портов, то с ограничениями с этой стороны вы не столкнетесь.
Когда вы создали dvSwitch, то на странице Home ^ Inventory ^ Networking вы видите картинку примерно как на рис. 2.12.
Здесь «Demo_dvSwitch» - это сам объект - распределенный вКоммутатор. Объект «Demo_dvSwitch-DVUplinks-28» - это группа портов, в которую объединены его подключения ко внешним сетям. То есть те порты вКоммутатора, к ко-
Рис. 2.12. Свежесозданный dvSwitch
торым подключены физические сетевые контроллеры серверов, на которых этот dvSwitch существует. Нужен этот объект для получения информации о внешних подключениях - обратите внимание на столбцы в закладке Ports для данной группы портов. Число 28 в названии - это случайным образом сгенерированное число, для уникальности имени этого объекта.
Ну и «Demo_dvPortGroup» - созданная вручную группа портов, туда можно подключать ВМ, а также виртуальные сетевые контроллеры Service Console и VMkernel.
Обратите внимание. При использовании стандартных виртуальных коммутаторов невозможно поместить в одну группу портов виртуальные машины и интерфейс VMkernel или Service Console. На распределенных виртуальных коммутаторах VMware это возможно, на dvSwitch в одной группе портов могут сосуществовать и ВМ, и интерфейсы SC и VMkernel в любых сочетаниях.
Кстати говоря, объект «VM Network» на этом рисунке - это группа портов на стандартных виртуальных коммутаторах серверов этого vCenter.
VMware vCenter Enhanced Linked Mode (ELM) allows virtual infrastructure admins to connect and manage multiple vCenter Server instances together, through a single pane of glass.
By joining vCenter Servers together in Enhanced Linked Mode, they become part of the same Single Sign-On (SSO) domain, allowing administrators to log into any of the linked vCenter Servers simultaneously using a single set of credentials.
As well as roles and permissions, ELM also enables the sharing of tags, policies, and search capabilities across the inventories of all linked vCenter Servers from the vSphere Client.
An example of a common ELM setup is the management and workload vCenter Servers from the primary and secondary sites (for a total of 4) linked together, improving ease of administration and usability.
Example vCenter Enhanced Linked Mode Setup
How to Configure Enhanced Linked Mode for Existing vCenter Server Appliances
If you have existing vCenter Server deployments in separate SSO domains, then you can still join the vCenter Servers together in Enhanced Linked Mode using the SSO command line utility.
First, confirm your vCenter Server instance is not already using Enhanced Linked Mode as part of an existing SSO domain:
- Log into the vSphere Client
- Select the vCenter Server (top level) from the inventory
- Click the Linked vCenter Server Systems tab
- If you cannot see this option, click the … icon to reveal more
- Review the list of linked vCenter Server systems
- If the list is blank, then ELM is not setup
The steps below will demonstrate repointing a source vCenter, not already in ELM, to an existing target SSO domain. You will need to amend the syntax with the following values:
- –src-emb-admin Administrator
- The source SSO domain administrator, account name only. The default is administrator.
- replication-partner-fqdn FQDN_of_destination_node
- The Fully Qualified Domain Name (FQDN) of the target vCenter Server.
- –replication-partner-admin SSO_Admin_of_destination_node
- The target SSO domain administrator, account name only. The default is administrator.
- –dest-domain-name destination_SSO_domain
- The target SSO domain name, the default is vsphere.local.
Additionally, please note that:
- Whilst ELM is supported with vSphere 6.5 Update 2 and later, SSO domain repointing is only supported with vCenter 6.7 Update 1 onwards
- The command line utility requires the Fully Qualified Domain Name (FQDN) of the vCenter Server and will not work with the IP address
- The source vCenter Server is unavailable during domain repointing
- Ensure you have taken a file-based backup of the vCenter Server to protect against data loss
First, SSH onto the source vCenter Server. During the repointing exercise, you can migrate tags, categories, roles, and privileges.
Check for any conflicts between the source and destination vCenter Servers using the pre-check command:
cmsso-util domain-repoint -m pre-check –src-emb-admin Administrator –replication-partner-fqdn FQDN_of_destination_node –replication-partner-admin SSO_Admin_of_destination_node –dest-domain-name destination_SSO_domain
To migrate any data generated during pre-check, and repoint the vCenter Server to the target domain, run the execute command:
cmsso-util domain-repoint -m execute –src-emb-admin Administrator –dest-domain-name destination_SSO domain
If you did not run the pre-check then run the full execute syntax:
cmsso-util domain-repoint -m execute –src-emb-admin Administrator –replication-partner-fqdn FQDN_of_destination_node –replication-partner-admin SSO_Admin_of_destination_node –dest-domain-name destination_SSO_domain
You can validate ELM using the Linked vCenter Server Systems view in the vSphere client, outlined above. Alternatively, you can use the following command:
./vdcrepadmin -f showpartners -h FQDN_of_vCenter -u administrator -w SSO_Admin_Password
1. Deploying the vCenter Server Appliance
As you probably know, this is also called stage 1 of the deployment which actually just puts the vCenter Server appliance on the ESXi host and assigns an IP address and name. During this process we will not get the option to configure Enhance Linked Mode, that’s for the second stage of the deployment.
Presuming you already have at least one vCenter server up and running with a minim version of 6.0, let’s start the installation wizard of our second one in the branch office. Mount the vCenter Server Appliance (VCSA) ISO and from the vcsa-ui-installer > win32 directory launch the installation wizard.
If there is no vCenter Server running in your environment, follow this guide to install your first one, then continue with the instructions bellow.
In the vCenter Server Installer window that opens up click on Install.
Since there is nothing to do on the Introduction page, click Next to move forward.
Accept the license agreement and continue the wizard.
On the vCenter Server deployment target page we need to provide an ESXi server with it’s credentials located in our branch office, since this is the branch office vCenter Server deployment. Once you are done completing all the fields click Next.
On the Certificate Warning window that pops-up just hit Yes to continue.
Here, we need to provide a name and password for our virtual appliance. The name we type in the VM name field will appear in the vCenter inventory; it is not the guest name.
Choose the size of the appliance based on how many ESXi hosts and VMs this vCenter server will manage then click Next.
Select the datastore from the target ESXi host where the vCenter Server appliance will sit then continue the wizard. To save storage space, you can enable Thin Disk Mode so the appliance disks will not occupy the entire provisioned space. They will grow as more disk space is required.
This is where we provide to the wizard the network information for our vCenter Server. Just make sure that before you click Next on this wizard screen you already have an A record created in DNS with the same name as you put in the FQDN filed that points to the IP address you typed in the IP address filed.
If everything looks good in the Review page, click Finish to start the vCenter Server appliance deployment.
Once this is done, we will have to go trough the second stage of the deployment where we will configure the Enhanced Linked Mode feature.
What is the Difference Between Enhanced Linked Mode and Hybrid Linked Mode?
Hybrid Linked Mode is concerned with linking your on-premises vCenter Server with a cloud vCenter Server. The key difference is that Hybrid Linked Mode does not join the same SSO domain, but instead maps through the connection using either a Cloud Gateway Appliance or an LDAP Identity Source.
You can set up on-premises vCenter Servers in Enhanced Linked Mode, and still connect these to a cloud vCenter Server using Hybrid Linked Mode. An example of this is a hybrid cloud setup with VMware Cloud on AWS providing the cloud vCenter, linked with vCenter Servers in your data centre(s).
Example vCenter Hybrid Linked Mode Setup
2. Configuring Enhanced Linked Mode for the vCenter Server appliance
Now that stage 1 of our vCenter Server appliance has finished successfully, it is time configure the second one. This is the part where we point the Platform Service Controller (PSC) of this vCenter appliance to the one in our headquarter site. To begin this process just hit the Continue button in the vCenter Server Deployment Wizard.
On the Introduction page of the wizard click Next since there is nothing we can configure here.
In the second screen of the wizard we are given the option to configure a custom NTP server for our vCenter appliance or go with the default choice which is to synchronize time from the ESXi host it’s sitting on. I encourage you to always provide a time server because this way all your servers and devices will be synchronized.
Believe it or not, but all this work that we did above was for this window only. This is where we link this PSC/vCenter to the one in our headquarters datacenter. In the first field, type the remote vCenter server FQDN or IP address then the SSO domain, username and password. When you are done click Next.
Join or not join the Customer Experience Improvement Program, I will leave this up to you.
On the Ready to complete page, review the configuration, and if everything is good, click the Finish button to configure this Platform Services Controller (PSC) and link it with the headquarter one.
We get a warning before stage two of the deployment starts, informing us that we will not be able to stop or pause the process. We are good, we know what we are doing, so click OK to start the installation.
Once the deployment starts, be prepared to wait, because it will take a few dozen minutes to finish.
Once it is done, we are presented with a link that opens the vSphere Web client.
At this point, it does not matter which vCenter Server address we use to access the web interface, because once the vCenters are linked we can see all of them here. Now off course, we can implement some restrictions, but by default, as an admin, we have the option to manage all the linked vCenter Servers from one single point. Pretty cool I might say!
Because of the self-signed certificate, we will get that nasty certificate error page in the browser. Just continue to launch the vSphere Web client, and if you want to get rid of the certificate error, you can replace it with a trusted one from an internal Microsoft PKI or from a public one.
Logging into the second vCenter server we get the same view.
If we have more than two vCenter Servers linked together using ELM, the result should be the same no matter what vCenter we use to log in.
Wrap Up
I hope that you enjoyed this article and that you now have a better idea of how to properly set up Enhanced Linked Mode in vCenter 7.0. If there are any questions, please let me know in the comments below.
If you are the VMware administrator of some large environment or maybe a consultant and need to deploy new vCenter servers in the company’s branch offices, you can do this very elegantly so after you are done, all the vCenter servers can be accessed, managed and configured trough a single interface. Based on VMware’s dictionary, this is called Enhanced Linked Mode (ELM) which allows us to link two or more vCenter servers together for ease of administration. Well…the linking actually happens between the Platform Service Controllers (PSC) where vCenters are connected to as you will see later on. Since the PSCs will be in the same SSO domain, they will replicate permissions, licenses, tags, policies, roles across all linked vCenter Servers. This feature will also allow us to view and search all of the linked vCenters inventories, and manage them trough a single vSphere Web Client session.
Unfortunately, if you are running vCenter Server Foundation or Essentials it is not going to work because Enhanced Linked Mode requires vCenter Server Standard licensing. Enhanced Linked Mode also has some limitations:
- For vCenter Servers deployments with external PSCs (external PSCs were deprecated by VMware starting with vCenter 6.7) we can join up to 10 external PSCs and 15 vCenter Server systems in a single SSO domain.
- For those vCenter Servers with an embedded PSC, we can join up 15 nodes in one SSO domain.
Now that we know the ins and outs, let’s start deploying a new vCenter Server in one of our branch offices and join it to an already existing SSO domain which is running in our headquarters datacenter. If your vCenter servers are already deployed and you want to take advantage of the Enhanced Linked Mode feature, you can do so starting with vCenter Server version 6.5U2 which I am going to discuss in a future article. Right now we are going to concentrate only on new vCenter Server deployments which we want to linked them together.
Summary
Since VMware deprecated the External Platform Service Controller starting with vCenter 6.7, the configuration of Enhance Linked Mode has been simplified a lot. As you just saw, implementing this feature not only helps us reduce the complexity of our virtual environment but also making it easy for the rest of the admins. We can create a CNAME record in our DNS and give the name to the rest of the departments that need to use the virtual infrastructure, and that’s it, all they have now is just one FQDN for the entire VMware environment. From here on, all we need to manage are the permissions.
How to Configure Enhanced Linked Mode with vCenter 7.0
To configure Enhanced Linked Mode a vCenter Server with an existing SSO domain must already be in place. This may be through an existing vCenter in your environment, or by deploying one from scratch.
If you are deploying a greenfield environment then install vCenter Server as normal, creating a new SSO domain by default as part of the process.
Follow the process outlined below to configure Enhanced Linked Mode with your second, or further vCenter Servers in the environment.
- Follow stage 1 of the vCenter Server 7.0 install process as normal.
- Stage 1 deploys the appliance to your target host and datastore, whilst configures the appliance size and network settings.
- Once stage 1 is complete you are prompted to continue to stage 2.
- The SSO domain configuration is done during stage 2 configuration.
vCenter Server Stage 2 Install
- Click next. Verify the network, time, and SSH settings, click next again.
- On the SSO Configuration page change the default option from the new SSO domain, to join an existing SSO domain.
vCenter Server Join Existing SSO Domain
- Enter the details of the vCenter Server for the target SSO domain, along with the existing administrator password.
- Click next. Configure the Customer Experience Improvement Program (CEIP) accordingly and click next again.
- Review the settings and click finish to finalise the deployment.
- Once complete, log into vCenter Server as normal.
- You should now see the vCenter along with any linked vCenter Servers from the vSphere Client.
- You can further validate the ELM configuration by selecting the vCenter Server (top level) from the inventory and clicking the Linked vCenter Server Systems tab.
- The linked vCenter Servers will now be listed.
vCenter Server Configured Enhanced Linked Mode
What are the Requirements for Enhanced Linked Mode in vCenter 7.0?
- An embedded Platform Services Controller (PSC) deployment
- At least 2, and a maximum of 15, vCenter Server Appliances (VCSA) in the same SSO domain
- vCenter Server Standard licensing, ELM is not included with vCenter Server Foundation or Essentials
- All vCenter Servers must be running the same version
If you are running vCenter 7.0 then both the Windows vCenter and the external Platform Services Controller are deprecated.
For previous versions, or non-compliant deployment types, review the following steps:
- vCenter 6.0 – vSphere 6.0 is out of support, whilst ELM was available with vCenter 6.0, it required external PSC node(s), which is also no longer a supported deployment option in vCenter 7.0. Upgrade to vSphere 6.5 or 6.7 first, and then upgrade to vCenter 7.0.
- vCenter 6.5/6.7 – ELM is supported with the embedded PSC from vCenter 6.5 Update 2 and later. However, due to the end of support approaching on October 15 2022 for both vSphere 6.5 and 6.7, you should still consider upgrading to vCenter 7.0.
- Windows vCenter – Windows vCenter Servers are not supported with ELM or with vCenter 7.0. During the upgrade process, you can migrate all your configuration and historical data to the vCenter Server Appliance from the vCenter 7.0 upgrade UI.
- External PSC – The external PSC deployment model is not supported with vCenter 7.0. During the upgrade process, you can consolidate your external PSC(s) into the embedded model using the converge tool built into the vCenter 7.0 upgrade UI.
Читайте также: