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 "[email protected]" -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 "[email protected]" -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 "[email protected]" -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

Single plug-in instance per vCenter Server. — Figure 1. 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 portlet on the VM summary page, then browsing VMs on VC2 will load the portlet from the second plug-in server, and browsing VMs on VC3 will load the portlet 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:

This screenshot shows a selector widget for the single plug-in instance per vCenter Server topology. — Figure 2. 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://vc2.example.com/sdk -u "[email protected]" -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 "[email protected]" -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

This diagram shows a singleton plug-in instance shared by several vCenter Server instances. — Figure 3. 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:

This screenshot shows a selector widget for the singleton plug-in topology. — Figure 4. 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 o 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.