linked mode vmware что это
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.
В объединенной таким образом инфраструктуре вам доступны:
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 одной группы. Эти данные содержат:
— сертификаты и их отпечатки (Thumbprints);
Один раз в день данные из ADAM выгружаются в резервную копию, которая хранится в БД сервера vCenter. В случае повреждения ADAM vCenter будет использовать данные из последней резервной копии для его восстановления.
Подключить vCenter к группе Linked Mode можно как на этапе установки, так и в любой другой момент. Пользователь, который запускает процесс присоединения сервера vCenter к группе, должен обладать правами локального администратора и на локальной системе, и на системе (системах), где установлены прочие серверы vCenter этой группы.
Требования к инфраструктуре следующие.
Все серверы vCenter должны находиться в одном домене AD или в разных доменах с двухсторонними доверительными отношениями. Само собой, важна правильная настройка синхронизации времени и DNS.
Если вы хотите объединить в группу несколько (например, три) серверов vCenter на этапе их установки, то ваши действия следующие.
1. Установить первый из них. Так как на этом этапе он является единственным, никакой группы для него не указываем.
Теперь все три сервера 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».
VMware vCenter Enhanced Linked Mode configuration
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:
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.
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.
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.
If you closed by mistake the wizard window, open a browser and type the FQDN or IP address of the appliance followed by port 5480 (https://). This will launch the second stage of the deployment.
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.
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.
Want content like this delivered right to your
Linked mode with SSO for SRM
With the introduction of Single Sign On in vCenter 5.1, it poses a change in behaviour for those of you using linked mode. This post will outline some of the considerations for why or why not to use linked mode with SSO and SRM in 5.1, and how to install SSO in multi-site mode in order to take advantage of linked mode.
Mostly linked mode is used by customers with Site Recovery Manager for purposes of visibility of both your protected and recovery sites including protection status and looking at the placeholders so you can see what is protected for recovery. Linked mode also gives easier license sharing between sites, so you can install the same SRM key at both sites and have automated transfer of per-VM usage between sites when migrating or failing-over between sites.
Don’t forget, that doesn’t mean you can exceed the total number for which you are licensed, e.g. if you have a 75 VM SRM license you can install that license on both sites of the linked mode install, but you are still only allowed to protect up to 75 VMs whether it’s 50 on one site and 25 on the other, or 75 at one and zero at the other. What linked mode will do is allow you to failover and then protect back while automatically deducting the protected number of VMs from the appropriate license at either site depending on where your protected VMs are running.
Linked mode is *not* a prerequisite for using SRM. Even without Linked Mode you get a lot of benefit from SRM – it will happily show you all the DR information you need, from both protected and recovery sites in a single pane of glass. SRM works just fine with or without linked mode. If you want to use it, however, be aware that with 5.1, linked mode has a new prerequisite: Namely that SSO be installed at both sites, and that it be installed very specifically in “Multisite mode”. While the SRM plugin still uses the vSphere “thick client” which does not use SSO, the backend communication of the VCs will require multisite SSO.
Linked mode vCenter instances need to authenticate against what appears to be a single SSO instance, whether it is a single SSO instance at one site, multiple SSO instances in HA mode, or multiple SSO instances in multi-site mode. Of those options when using SRM, my preference is to either not use linked mode at all, or to deploy SSO in multisite mode. A single instance or an HA cluster at one site will always introduce the risk that you can not log in during a disaster.
Of course, the other choice is to not use linked mode, and to stand up independent VC and SSO instances at each site and manage them as separate entities all together. This is of course what you will do if you don’t want or need linked mode and multisite SSO. In any of these cases, SRM will be fine and your approach and architecture will merely alter how you manage the environment.
So the purpose of this post is a quick walkthrough of how to install (or upgrade) from vSphere 5.0 to 5.1 and move to SSO linked mode for use with SRM.
The first and most important factor is that you *cannot use the simple install process* of the vCenter installer. You *must* install each component individually. This is specifically because the simple install does not expose the functions of multi-site SSO or allow you to select primary and secondary roles of the SSO servers.
So first, let’s log into the primary site vCenter Server, open the installer and choose to install SSO independently as the first step.
The first requirement is to choose the appropriate SSO deployment type. What we will want to do is to “Create the primary node for a new vCenter Single Sign On installation.” This will set up SSO as a standalone entity for your local vCenter, but also give you the ability to join the second site’s SSO install to it when we get to that stage. You could be doing a new install, an upgrade from VC 5.0, or even installing SSO on a separate system from your VC – the point remains the same, to choose to create a new primary node.
Now it will want to know a password for the SSO system domain password. Choose a good password, and write it down! We’ll need it a few times throughout the install.
The next step is to choose the SSO sign-on type. We can choose to install a basic mode or a primary node for a new multimode SSO. Here we choose to “Create the primary node for a new vCenter Single Sign On installation” which will then give us the opportunity to join other SSO instance to this one.
The rest of the steps are fairly self explanatory – Keep in mind SSO domain admin password you choose, and keep both it and the https port written down somewhere, we’ll need that again later too.
Install or upgrade the Inventory service next, (and handle the certificates however you see fit). Hold off on the other pieces (web client, client, possibly VUM…) until after you’ve installed vCenter Server, which is what you should do next.
When you install vCenter Server itself, make sure you are *not* trying to join a Linked Mode instance – we are going to create a “standalone” instance and then later join the second site’s VC to this one. Also, when entering the SSO data into the VC install wizard, you’ll need to use the same ID and password you used for “admin@System-Domain” earlier.
One thing I quite like about this install is the ability to populate the administrators group with a domain admin group. You can either choose to leave the default “Administrators” group, populate it with an ID, or as I did, give it my “domainDomain Admins” entry so all my domain admins would be automatically recognized as SSO admins.
You should then be up and running with a primary multi-node SSO operating standalone, and a standalone VC 5.1 using local inventory services and the local SSO.
At this point you can optionally upgrade this site’s SRM to 5.1, which is a very basic process and really only requires 64 bit SRAs and a 64 bit ODBC in terms of required changes to the server for doing the upgrade.
Now let’s move over to the other site and log into the secondary vCenter.
Again, we will need to run the installer component by component, rather than using the simple installer, as we need to choose various SSO options to get it working.
The first step again is to do the SSO install. Here, we choose the option to “Join an existing vCenter Single Sign On installation.” rather than to create the primary node. The primary has already been crafted on the first site, we simply want to join into it.
The next step is to choose the “Multisite” installation type. This will give us the opportunity at the bottom of the window to input all of the information for our first site’s SSO installation. Since I installed SSO on my protected site’s vCenter Server, I give it the FQDN of my primary site VC, the https port we used earlier, and the SSO domain admin password we chose earlier so it can authenticate with the remote SSO. Told you we’d need them again.
Be careful here, look this screen over a few times. I can’t tell you how many times while in a rush I’ve entered the wrong site’s information on this type of screen! Ensure you have entered the *first site’s SSO location information* and *not* the name of the current system you’re installing it in!
You will also need to enter the admin password for the *local* SSO. Since we want to use a multisite SSO, guess what you want to enter here? The same password you used for the other SSO. Keep it all in identity.
Choose a database of your preference, give the SSO it’s local IP or FQDN, an appropriate set of credentials, and then a preferred port for the local SSO.
Again, my preference here is to use the same port that was used on the other site. Makes life so much easier when you don’t have to mess around with different ports in different sites…
It will take some time to install, and ultimately all is done. You will now have a multisite SSO installation with common IDs and passwords between sites. Keep in mind, if you make *any* changes to your SSO you will need to *MANUALLY* export, copy, and import those changes to have them reflect at the other site – please see KB article 2038677 (http://kb.vmware.com/kb/2038677)
Now you can install or upgrade your inventory service on this site. There will be further certificate choices, I personally use the autogen certs so things are easier for me in my lab.
Ultimately this is also fairly straightforward. Keep in mind that when your inventory service requests the SSO information you will need to give it the *local* SSO instance information like password and URL.
It will register and install, and now it’s time for vCenter server.
When we install this, we *do* now want to choose to install it as linked mode. When the screen comes up for linked mode or standalone, make sure you choose “Join a VMware vCenter Server group using Linked Mode to share information”. This is, however, not critical at all. You can quite happily install vCenter server as a local instance using a multisite SSO and not use linked mode. To get linked mode all you would have to do is (once the inventory service and web client are installed) go into the start menu and as traditionally done, alter your vCenter to join linked mode after the fact.
At this point your recovery site SRM will need to be installed or upgraded to 5.1.
Once that is done, and SRM is functional, you should be able to log into your vSphere client or use the web client, and you can see the wealth of detail visible from linked mode.
For example, looking at the protected site, you can see visually which VMs are protected, by their special icon, but also from the same interface you can examine the recovery site and see the placeholder VM icons represented by the lightning bolt.
We can also now do some interesting license management, installing a common SRM license in both sites, giving us the ability to share the license across sites and have it automatically use up licenses from the appropriate location depending on where the protected virtual machines reside.
Throughout the install process we have built out a primary site local SSO as the primary of a multisite installation, an inventory service hooked into that local SSO instance, and then a standalone vCenter Server using those components. At the second site we have installed a secondary SSO and joined it to that of the first site, then an inventory service using its local SSO, and lastly a vCenter Server that uses its local SSO and inventory service, but is connected by linked mode to the first site’s vCenter Server. The architecture should look like this:
So, what’s left? I haven’t addressed a handful of things in this posting – first and foremost the management of a multisite SSO instance requires you to be very familiar with the change control process and management tasks necessary to export and import the environment if you make changes. Please review this carefully, and understand exactly what’s going on in the documentation for SSO at http://pubs.vmware.com/vsphere-51/index.jsp?topic=%2Fcom.vmware.vsphere.install.doc%2FGUID-03E1B870-21BA-47A5-87C3-9413B077CCD0.html
The other aspect I think is important that I haven’t addressed is certificates. That is worthy of a few articles of itself, but keep in mind if you are using custom certificates for either VC or for SRM, you will need to do so across the board – we do not support using “mixed mode” certificates where one part uses custom and the other uses auto generated. And lastly – SRM 5.1 uses 2048 bit certificates, so if you’re upgrading you may have to do the whole lot!
Ken Werneburg
Group manager for Technical Marketing at VMware for storage and availability solutions. Twitter @vmKen