Ok, Been a while but I wanted to see if there were any Best practices regarding wM component instances/ratio setups regarding IS< MWS, UM, and Active Transfer:
ex:
1 MWS per 2 IS instances (clustered) etc.
Thanks,
T
Ok, Been a while but I wanted to see if there were any Best practices regarding wM component instances/ratio setups regarding IS< MWS, UM, and Active Transfer:
ex:
1 MWS per 2 IS instances (clustered) etc.
Thanks,
T
Hi,
I have never been using Active Transfer, but I will try to answer for the other components:
Usually you would require at least one instance for messaging (UM in your question) and one instance for MWS and CommandCentral if you plan to use Landscape Management.
For IS this will depend on the number of packages, the number of nodes in the packages and the size of the documents being processed.
It is possible to have different (unclustered) instances of IS (each having its own db schema) when your processing can be decoupled by using publish/subscribe via messaging and a shared doc type.
Certain features cannot be shared across instances, i.e. TaskEngine in MWS.
This one can only work with dedicated IS instances, it is not possible to have one TaskEngine MWS running Tasks processes in different IS instances.
Regards,
Holger
Is this for Prod or some other environment?
One active UM server (realm) will work but it’s always good to have a passive UM server. A persistent file store can be used for the UM data that both servers have access to. This helps avoid single point of failure. If you only have one UM server and it goes down (e.g hardware failure), this will impact your entire solution.
UM active-active setup is also possible but the HA solution depends on your requirements, SLAs, expected uptime, acceptable recovery times, etc…
Hi,
I understand the setup for the UM, but my question was more along the lines of any one Production env:
how many MWS components per IS.
how many Deployers, Active transfer
Also, thank you for taking your time to help.
T
Unfortunately, it doesn’t work like that since there are tons of factors, primarily driven by the need and nature of requirements around existing architecture and processes, business, technology, security, volumes, roadmap and so much more.
This is a whole assessment, design and sizing exercise.
Perhaps you can ask specific design questions and the community can guide with experiences.
KM
Hi,
when using TaskEngine it is 1 MWS per IS, otherwise MWS is capable to monitor several IS instances.
If possible, you can use one dedicated IS instance as Deployer host which knows about the other IS instances.
Due to layer separations there should be one Deployer per each layer, i.e. DEV/TST, QA, PRD.
Deployer builds can be exported from DEV/TST layer and than be imported to the other layers.
For further measurements I agree with Kasi that this requires more detailed analysis.
Regards,
Holger
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.