Remote Plug-in Multi-Instance Support

The remote plug-in architecture allows for multiple instances of the same remote plug-in to be deployed within an ELM environment. Instances of a remote plug-in provide distinct server processes that can be completely equivalent in function or can implement different versions of the plug-in functionality. The illustrations that follow show characteristics of some possible topologies.
For example, consider an ELM environment with three vCenter Server instances. Suppose that the following extension registration commands are issued:
./extension-registration.sh -action registerPlugin -url https://
vc1
.example.com/sdk -u "Administrator@vsphere.local" -p 'Admin!23' -c 'Example, Inc.' -n 'Remote Plugin Test' -s 'A test plugin demonstrating plugin instances' -k com.example.remoteplugin.test -pu "https://
pluginserver1
.example.com/path/to/plugin.json" -v "
1.0.0
" -st
plugin1_server_thumbprint
-remote
./extension-registration.sh -action registerPlugin -url https://
vc2
.example.com/sdk -u "Administrator@vsphere.local" -p 'Admin!23' -c 'Example, Inc.' -n 'Remote Plugin Test' -s 'A test plugin demonstrating plugin instances' -k com.example.remoteplugin.test -pu "https://
pluginserver2
.example.com/path/to/plugin.json" -v "
1.0.0
" -st
plugin2_server_thumbprint
-remote
./extension-registration.sh -action registerPlugin -url https://
vc3
.example.com/sdk -u "Administrator@vsphere.local" -p 'Admin!23' -c 'Example, Inc.' -n 'Remote Plugin Test' -s 'A test plugin demonstrating plugin instances' -k com.example.remoteplugin.test -pu "https://
pluginserver3
.example.com/path/to/plugin.json" -v "
1.0.0
" -st
plugin3_server_thumbprint
-remote
One Plug-in instance per vCenter Server
Single plug-in instance per vCenter Server.
This topology has three instances of PluginA, such that the first plug-in server is registered with VC1, the second is registered with VC2, and the third server is registered with VC3. These plug-in servers are completely equivalent in function: the plug-in manifests that they host and the plug-in specific bits they run are identical. Because each server has a different URL for its manifest file, they are three separate instances of PluginA.
Object views will be loaded from the plug-in instance connected with the vCenter Server instance that the object belongs to. For example, if the plug-in declares a card on the VM summary page, then browsing VMs on VC2 will load the card from the second plug-in server, and browsing VMs on VC3 will load the card from the third plug-in server. Calls to the plug-in back end will be routed to the corresponding plug-in server instance.
Global views, however, will be aggregated in a single global view with an additional instance selector component that allows the user to choose between the global views of the different instances. A sample instance selector is shown below:
Selector for Single Plug-in Instance per vCenter Server
This screenshot shows a selector widget for the single plug-in instance per vCenter Server topology.
The instance selector shown above displays three back-end servers that represent the three instances of PluginA with version 1.0.0. The
Plugin Instance
column displays the IP address or fully qualified domain name of each plug-in instance, and the
vCenter Server
column displays the vCenter Server that each plug-in instance is connected to. Switching between the items in this drop-down will load the global view of the remote plug-in with version "1.0.0" from the specified plug-in instance.
An alternative topology, which could be considered for a data center with lower access volume, might configure a single shared plug-in instance like this:
./extension-registration.sh -action registerPlugin -url https://
vc1
.example.com/sdk -u "Administrator@vsphere.local" -p 'Admin!23' -c 'Example, Inc.' -n 'Remote Plugin Test' -s 'A test plugin demonstrating plugin instances' -k com.example.remoteplugin.test -pu "https://
pluginserver1
.example.com/path/to/plugin.json" -v "
1.0.0
" -st
plugin1_server_thumbprint
-remote
./extension-registration.sh -action registerPlugin -url https://
vc2
.example.com/sdk -u "Administrator@vsphere.local" -p 'Admin!23' -c 'Example, Inc.' -n 'Remote Plugin Test' -s 'A test plugin demonstrating plugin instances' -k com.example.remoteplugin.test -pu "https://
pluginserver1
.example.com/path/to/plugin.json" -v "
1.0.0
" -st
plugin1_server_thumbprint
-remote
./extension-registration.sh -action registerPlugin -url https://
vc3
.example.com/sdk -u "Administrator@vsphere.local" -p 'Admin!23' -c 'Example, Inc.' -n 'Remote Plugin Test' -s 'A test plugin demonstrating plugin instances' -k com.example.remoteplugin.test -pu "https://
pluginserver1
.example.com/path/to/plugin.json" -v "
1.0.0
" -st
plugin1_server_thumbprint
-remote
Singleton Plug-in Instance for Link Group
This diagram shows a singleton plug-in instance shared by several vCenter Server instances.
The plug-in is registered with all linked instances of vCenter Server. All registrations have the same plug-in ID, version, and manifest URL, so this is considered a single instance. All plug-in object specific views will be loaded from this one plug-in server. Because no other versions of the same remote plug-in are present in the environment the global view will contain a single item that represents the global view of the singleton instance, as shown in the following example selector:
Selector for Singleton Plug-in
This screenshot shows a selector widget for the singleton plug-in topology.
With this topology, the plug-in can be upgraded to a newer version for an entire link group by replacing a single process. However, a singleton plug-in works best in a homogenous environment. In an environment that contain sdifferent versions of vCenter Server, the singleton plug-in might need to handle different API versions.
Similarly, if you upgrade an instance of vCenter Server in a singleton plug-in configuration, the plug-in could become incompatible or could fail entirely. For more flexible version support, consider using multiple-instance topologies instead.