What is the best practice for deploying multiple CLM Repositories on WAS ND?
Is the Best Practice to install one instance of WAS ND for each organization we support, or should we be joining multiple repositories under one WAS?
One issue we have is the different organizations move to new releases at different times during the year and we need to have the flexibility to only bring down the individual repositories and not affect the others during the upgrade.
The examples I find in the documentation do a good job at showing the topology for one deployment of the tools, but I can't find anything on multiple deployments.
Thanks,
Accepted answer
The concerns i have about a cell this large are:
1. If there is a catostrophic event or an admin fat fingers the Dmgr config, it could affect the entire cell
2. How will the Dmgr perform with this many nodes.
3 other answers
Comments
Thanks Abraham,
So if we were to install each CLM App on their own VM instance we would have 1 Node and 1 AppServer defined for each App right?
Would it make sense to use Node Groups to group the CLM Apps by organization? So Org A would have a Node Group with 3 Nodes (JTS,CCM,RQM) and each of those Nodes has 1 application server for the App installed on that Node? Then if we need to upgrade CLM for one Org we can just bring down the Nodes in that Node Group.
We've never had an organization require Websphere to be upgraded for their own purposes, it's usually an IBM-directed upgrade due to security.
Not sure which documentation you were looking at but I found this article that you might find useful.
https://jazz.net/library/article/1123
Comments
Karl,
Thanks for the reply. I have used that article for an initial test setup, but that article only describes one instance of each CLM application.
An an example:
I support 2 organizations that both have over 500 users. Each team uses JTS, CCM, RQM.
Do I use 1 Deployment Manager and create 6 Application Servers (JTS, CCM, RQM server for each org)? I understand how to do that.
The question is what happens when one of the Orgs wants to upgrade from 4.0.2 to 4.0.4. Can I just bring down their 3 Application Servers and upgrade, leaving the other org's JTS,CCM,RQ app servers up and running still? Or do I have to bring both Orgs down to upgrade only 1 of them?
Your response above sounds like we could upgrade one Orgs applications without affecting the other. But since we support 12 - 15 different Orgs we're trying to understand how many Deployment Managers we need..basically the pro and con of all App Servers under one Deployment Manager or multiple.
A node group is a non technical aspect of webSphere which allows administrators to document how the nodes are to be used. For each of the organizations create a unique Node Group and assign each webSphere node to the appropriate node group so to make other admins aware of the organizational configuration of the nodes
For the organizational topology being discussed, i would suggest having each WebSphere node running on seperate hardware to ensure that each CLM environment is isolated from the other .
The above suggestion is not required, you can have all the server instances running in the same WebSphere node. Since each server instance runs on its own jvm, making modifications to one application will not affect the others, but from a admin perspective this could get confusing.
Comments
Thanks Abraham,
We are on the same page and this comment you made is what I was thinking we would do:
"For the organizational topology being discussed, i would suggest having each WebSphere node running on seperate hardware to ensure that each CLM environment is isolated from the other . "
We would have about 15 different CLM Projects, with about 4 apps in each. So around 60 different Nodes if following above and each app being installed on separate hardware.
Is it advisable to federate this many with one dmgr? What happens if the dmgr goes down? Do all the Nodes go down also? We would setup failover before going into production of course, but just curious.