I can not find in the manuals any mention of ability to install and run multiple copies of IS on the same host. This could be running two copies of V6.1 from one directory structure, installing a complete copy of IS into two distinct directory structures (and running two instances), and installing a second different version of IS onto a host which already has a running prior version (which will continue to be run). Most of this question arises from a shortage of extra hardware platforms while needing to have IS for test, development, QA, Prod, sandbox etc.
Any guidance available, and how-to available ?
If you’re willing to have two (or more) separate copies of the software on disk, you can do it exactly the same way you’d install one copy, just selecting different directory structures. Of course, they won’t be able to have the same ports, so after you install the first copy, change the primary port from 5555 to something else, then install the second and change the primary port, etc. To make things a bit easier, a numbering convention is convenient (i.e., ports 5500-5509 for the first IS, 5510-5519 for the second, where the 55X0 port is the primary port).
Having a shared directory structure is tricky, but possible. First, ask yourself why you want a shared copy. Disk space is cheap, so it’s really not much of a savings there. While a single copy will share some amount of memory, it won’t be much, since it’s only the JVM itself (and none of the IS code or data) that would get shared. And since memory is relatively cheap, that’s not a big savings. In my opinion, the only reason for wanting a shared directory is to avoid having to update multiple instances (either with webMethods-supplied fixes or your software).
If you’ve concluded that a shared copy is the right choice, the easiest way to do it is to do multiple installs, and then delete the common directories in the second (and subsequent) versions and replace them with symbolic links to the “master” (primary) copy. Sharing some directories, like “config” may seem useful, but can be quite dangerous, since some config files get rewritten whenever an IS exits, so you can end up with strange results (i.e., adding a user in one instance of the IS updates the users.cnf, but then a different IS exits and rewrites the file losing the new user). Directories like “logs” should never be shared. And within the “packages” directory, things get tricky. For example, if you have packages that aren’t being modified and don’t have any listeners based on that package, then the whole directory can be shared. However, if you have listeners for that package (as is the case for WmRoot), most of the directories can be shared, but the “config” directory cannot be shared since that’s where the listeners are defined.
Bottom line is that in general, it’s more of a pain to share instances than to simply have multiple copies.
I agree with jepstein about having separate installations on the same box. We do that too, for our dev and QA environments. I would think that if you were installing a wm software patch or service pack, you would want to verify it in one IS before deploying it to the other(s). We are also an AIX shop and we have the following directory trees for our installations
/webm/61/DV/IntegrationServer our dev IS home
/webm/61/PY/IntegrationServer our prototype (QA) is home
also at the same level as the IS homes are Broker, Developer, TNConsole, etc.
and of course, as jepstein said, you need to use different ports for each installation