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:// -remote
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
./extension-registration.sh -action
registerPlugin -url https:// -remote
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
./extension-registration.sh -action
registerPlugin -url https:// -remote
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
One 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
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:// -remote
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
./extension-registration.sh -action
registerPlugin -url https:// -remote
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
./extension-registration.sh -action
registerPlugin -url https:// -remote
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
Singleton Plug-in Instance for
Link Group
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
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.