Command Central and Platform Manager

, , ,
1

Hello everyone,

I’ve just begun using webMethods 9.5.1 and I have a few questions about Command Central and Platform Manager.

I have installed an IS, Broker, and MWS on a machine, and each one of these products is installed in its own installation directory (/eai/webMethods/is, /eai/webMethods/bm and /eai/webMethods/mws).
During each installation, I chose to install the corresponding Platform Manager Plug-in, which caused a new Plaform Manager runtime to be installed each time, once per installation directory.

Then I installed Command Central, and I added the 3 installations to my environment.

According to the documentation, it is possible to have only a single instance of Platform Manager managing several products via different plug-ins (or may be I misread the documentation?).

I was wondering if it was possible to do this even when each product is installed in its own directory or if you have to use one global installation directory for every product?

If it’s possible, how would you go about configuring one Platform Manager to talk to each Plug-in?

2

I have the similar issue while preparing our new wM 9.5 environments.

I have choosen the following split for the installations:

  • Broker, DB-Configurator, Command Cenrtral
  • MWS, AssetBuildEnvironment, TaskEngine
  • IntegrationServer, ART, ProcessEngine, RulesEngine, TradingNetworks, Deployer
  • Optimize

The last 2 will be installed up to 5 times to scope the load across the application by separating independent parts from each other.

Optimize forces a new Platform Manager Runtime for each installation, buut it does not choose any plugins.
the other installations are currently prepared without Platform Manager.

My question is, which isntallation needs a Platform Manager Runtime, and if so, with which plugins.

Please advise.

3

OK, my bad, it’s explicitly written in 9-5-SP1_Command_Central_Help.pdf that :

"
In a host machine, you might have multiple Software AG product installations. For each
Software AG product installation, you need a separate Platform Manager to manage the
installed products. For example, if you have these installation directories in a host
machine:
C:\SoftwareAG_production
C:\SoftwareAG_test
The Platform Manager that belongs to the C:\SoftwareAG_production installation
manages the products installed under the C:\SoftwareAG_production installation, and
the Platform Manager that belongs to the C:\SoftwareAG_test installation manages the
products installed under the C:\SoftwareAG_test.
Important! To manage Software AG products using Platform Manager, you must install
Platform Manager and the Platform Manager plug-in for the product you want to
manage in the same installation directory.
"

So I have my answer : it’s not possible to do what I was hoping to do.

This makes it a bit costly to use CommandCentral since it will require the installation of one Platform Manager runtime per component, and with the resource requirements of one Platform Manager instance (256 Mo of RAM and 1 CPU according to SAG documentation), we will have to crank up our machines’ specs to support that.

I don’t think we will follow these stritcly, at least for the CPU, because I don’t think it really means that Platform Manager requires one whole CPU all to itself to run. I would be very interested by sizing information, if anyone that has already used this product can share some?

@Holger:

I think each product that you want to administer through CommandCentral needs its own Platform Manager Plug-in, but I’ve only tested with IS, Broker and MWS, so I don’t know for sure about the others.

Concerning the Platform Manager runtime, you need one for each installation directory, so I’d say you will need one instance for each one of the installations in your list. And for the 2 installations that will be replicated several times, you will have to install a Platform Manager runtime on each replica.

If anybody with more experience in this matter can confirm or invalidate what I say, that would be great.

More generally, any feedback from people with practical experience on these products would be highly appreciated. :slight_smile:

Thank you all.

4

Let me clarify few things:

  1. Platform Manager (SPM) manages a single installation directory.

  2. If your particular product installation directory has products that have no SPM plugins available then there is (almost) no value in installing SPM in that installation directory. For example, there is no SPM plugin for Optimize (yet) and if Optimize is the only product in the install directory then you can skip SPM installation there

  3. SPM does not need entire CPU to function. Its idle workload is just monitoring which runs every 30 seconds (configurable to a lower internal if needed) so the CPU load is very low. You can ignore CPU requirements.

  4. SPM memory requirements greatly depend on the plugins/components installed. Unfortunately the major memory hog - WSS/NERV is not optional in 9.5 SP1, but it is optional in 9.6 release. You should fine tune your max memory depending on the plugins installed and the load on SPM.
    9.6 SPM out of the box comes with 128 MB max memory but it can function with a lower memory without NERV/WSS which is optional in 9.6. Test your scenarios. If you don’t get out of memory you can allocate less memory to SPM (to a reasonable amount. It needs 64 MB at least).

I want to ask you one question:

What is main reason why you install products of the same release version into separate installation directories? This complicates fix management, especially for products that have fixes that need to be in sync across difference install dirs.
What is wrong with having all products of the same version be under one install root?
Some products like Broker and MWS/TE already support multiple instances, exactly for the purpose of optimizing management of these products where requirements call for horizontal scalability.
Integration Server comes with multiple instance management support in 9.6 so you can have multiple IS’s under the same install root as well.

In your example below, ignoring Optimize (since it is not managed by CC yet), all other products can be installed in one install root and have multiple instances created if needed (for IS you’ll need 9.6). This way you only have one SPM to manage all these products, including multiple instances, and it does not need much resources to run (0.1 CPU and 128 MB)

Will that work or are there issues that this setup?

Thanks
Sergei

1 Like
5

Thank you very much for these clarifications.

Regarding your question, I can’t speak for Holger, but in my case, the division into several installation directories goes back to the project’s beginning some ten years ago, and was never called into question since.
Since there’s no one from that time left on the team, I’d have to do some documentation archaeology in order to dig up the original reasons for this choice, but the technical and business constraints were probably very different then from what they are now, so it might be a good opportunity to reconsider it.

The way Platform Manager works certainly goes into the pros of a common installation directory.

6

I too say thanks to your explanations.

For me too it is also quite historical that we have choosen this approach.

But it has somethig to do with our HA-Configuration as well as that some instances/environments should be able to maintain different Fix-Levels. Additionally we have Security restrictions which forces us to intall separate MWS instances on a different box using firewall clearances.

Unfortunately I cannot wait for 9.6 at the moment but have to go with 9.5.

If there is no value of having a SPM with an Optimize Installation I wonder why Installer forces me to install one together with Optimize/Analytic Engine. You cannot omit the installation of SPM in this case. Otherwise the installer deselects Optimize as well.

The other installations, where having a SPM would be useful, can be done without it.
:?:

7

You don’t have to wait for 9.6 release (though it will be available in a few weeks, mid April). You can start with 9.5

If your requirements call out for different patch levels then you do have to use different root installation. Multi-instance support assumes/requires that all instances share the same patch level.

A similar legitimate reason for different installation roots is for different release versions, e.g. for side-by-side upgrade for example.

Those two, difference releases and difference patch levels, are the only reasons I could think of to justify separate installation roots.

As far as Optimize dependency on SPM in 9.5, this looks like a defect in the Optimize installer.
In the initial 9.0 release all CC-adopting products had hard dependency on SPM but in 9.5 we relaxed this an introduced SPM plugins and soft dependency to allow installation of core products with or without SPM/Plugins and vice versa: SPM with Plugins without products.

8

I am currently planning the new environment for a side-by-side migration from wM 7.1.x.

From the Upgrade webinar I know that there will be no direct upgrade path to 9.6 in this case.

On the other hand our planning is already beyond the Point-of-no-Return to wait for 9.6.
I am aware that this release will be available soon.

Meanwhile I have MWS, Broker, Command Central and their Platform managers running, but I cannot see or add the Components in MWS-CommandCentral UI.
Any Ideas on this?

9

Command Central UI inside MWS is just an iframe which has a number of problems and that’s why we dropped its support in 9.6 completely. There is no good reason to use it.

Please open Command Central Web UI directly via its link, by default http://host:8090/cce/web

Have you registered those MWS/Broker installations where SPM is running within Command Central?
If not, the go to Installations tab and use [+] icon to register a new installation by specifying SPM host:port for it
If you already have done it, open this Installation details > Products and verify that you have Broker and MWS Platform Manager Plug-ins installed. If not, please install those plugins and then refresh Instances table on the Installation Details page

10

I tried to register the installations from MWS-UI but this is not working.

I just did as you suggested and use the Command Central UI directly.
I was able to register at least Broker and MWS. The IntegrationServers are not ready yet.

I would like to see that Optimize can be managed by CCE too.
Unfortunately, Optimize needs to be installed that many times as you have Process Engines which should be observed, as the “Install Once, Configure many” is not yet implemented.
Additionally I have one Optimize Environment with both parts (Infrastructure and Process) while the others only consist of Optimize for Process. The Infrastructure Parts is handled by the single InfrastructureC.

11

At this point I just can say that Optimize integration with Command Central is on the road map. There might be some initial integration in the next October 2014 release.

12

How is it in 9.7 ? i.e is there a one-to-one SPM for every installation directory ?

13

Yes, it is still SPM per managed installation directory.
We have no plans to change that since most core products we support (IS, MWS and UM) allow multiple instances per installation which eliminates the need to have multiple installation directories of the same suite release version.