Hi,

Here is my environment :

DEV : one server for IS and admin console

Preprod :

• IS Server
• Admin server (monitoring and Deployer)

Production (active/active) :

• IS Server - node1
• IS Server - node2
• Admin server (monitoring and Deployer)

For the 2 nodes of Production we will have a Load Balancer.

I’m considering doing this for deploying the Production packages :

1- I have to preprare and configure all parameters to set PROD-node1 et PROD-node2 like Preprod

2- I have to use the Admin-Deployer-Production and copy all packages from Preprod → Prod-node1.
Is it correct ?

3- for the Prod-node2, do I need to copy manually packaqes from Prod-node1 → Prod-node2
or is there any mecanism of automatic copy between 2 nodes ?

Regards

Hi Cedric,

please have a look at the Deployer Users Guide for how to deploy to clustered IS nodes.

Please make sure that packages are developed to be cluster-aware resp. cluster-safe otherwise you might receive unpredictable behaviour in production.
Means: What is working in a single node environment does not neccessarily work in a clustered environment.

Mainly publish/subscribe triggers need to be checked here.

Regards,
Holger

Thanks a lot Holger.
Could you first tell me how to know (or verify) if my 2 nodes are actually clustered please ?

Regards

Hi Cedric,

in IS Admin UI, under Settings → Clustering it should show if the node is part of a cluster or not.

Depending on wM version you will have to installation specific components for interchanging informations between the nodes.

Some parts are stored in the IS Internal database schema, some parts will be stored in i.e. a Terracotta caching server.
All nodes of a cluster need to connect to the same Broker or UM and have to use the same client prefix.

You will find more informations about this in the IS Clustering Guide.

Regards,
Holger

In Cluster Settings of IS-Node1
Cluster Settings
- General → Clustering Status : Disabled
- Cluster Hosts → No Cluster Hosts

In Cluster Settings of IS-Node2 : same thing

I suppose, this is 2 independant nodes (they just sharing some JDBC pool)

so, do you confirm me that I can safetly deploy the Preprod packages on the node1 and node2 ?
(maybe creating a group in the Deployer)

Regards

Cedric,
There are different ways of configuring the cluster… There is something called ‘stateless IS cluster’ which will only share the same DB schema (ISInternal) & this will be accessed by external clients through a Load Balancer which will distribute the requests to both the nodes and the other type is ‘stateful IS cluster’ which will require Terracotta server to be installed/setup (similar to Orache Coherance) that will share the state information between two nodes… So IS cluster can be of any type based on your needs…

When you say these nodes are in cluster (be it any type), the configuration and packages etc., should be identical in both the nodes. You can use Deployer (a component of webMethods) using which you can deploy the packages from one environment to the other. It could be from pre-prod (source) to the target env (which is of cluster).

Please read the Deployer’s guide and you will have a good understanding.

Regards
Senthil

and to answer your question, yes, you can just create a Deployer group which will have both the prod IS nodes added to it. You can choose the source as pre-prod and deploy to the group (prod nodes)…

HTH
-Senthil

Cedric,

When it comes to Deployer, you will typically create a build from a specific source. Once that build is created, you should deploy that same build everywhere.

In your case, it sounds like you’re using your Development environment as the source (which is fine for the time being but I would encourage you to read up on the Asset Build Environment and repository-based deployments.) This means that you will be using a Deployer instance to point to your Development server and generate a build from there. Once that build is created, you should deploy that same build to Pre-Prod and then to Production.

If you have a single Deployer instance that has access to all environments (i.e. Development, Pre-prod, and Production), then you can have a single Deployer project with a single build but a Deployment Map and Deployment Candidate for each target environment (i.e. pre-prod and prod). This is simplest approach. If, however, your Production environment is on a different network, then you can export the build from Deployer and then import it into a Production Deployer instance.

Percio

Hi Cedric,

I agree with Percio.

Currently we are using “Build Once, Deploy multiple times” scenario runtime based.

As our QA (Pre-Prod) and Prod environments do not have access to our internal environments (nor vice versa), we export the build from internal deployer and promote them to QA & Prod for import with some notes about preconditions and risks during deployment (i.e. import database tables, create users & acls).
Sometimes a deployment consists of different parts (deployer builds), then the right order is also stated in the notes when these depend on each to get dependencies resolved in the right way.

Regards,
Holger

Hi,

Senthilkumar G, to reply to your question. Our technical document says :

The 2 “cluster” of IS are “stateless”, and each instance works in a independent way. Currently, there is “no” Terracotta distributed cache installed for our environment.

The 2 IS share the same DB Schema called : IntegrationServer

The 2 IS share the same DB Archive Schema called : Archive

Each IS uses his own ISINTERNAL schema called (ISInternal1 for IS1, and ISInternal2 for IS2)

Regards

Thanks for all your replies.

Regards

Cedric,

Your statements are contradictory…

The first three statements are good but the 4th one is not right if the first 3 stmts are right & vice versa. If ISInternal schema is different for both Integration servers, then these are not stateless IS cluster. They are just two independent Integration Servers.

-Senthil

Thanks Senthil,

I’m going to look closely this, because I’m afraid… but probably our 2 nodes are just independant. These are not cluster stateless.

They just share the same DB for the functions :

• ISCoreAudit, DocHistory et Xref (schema : IntegrationServer)
• Archiving (schema : Archive)
• BPM (schema : BPM)

Such a configuration would be correct for you ?

Regards

Hi,

An expert from French support replied me (traducted from french) :

“the IS instances must share the same access to the Database audit service, to have a centralized monitoring vison of monitoring for your 2 nodes”.
However the alias ISInternal has to be share only in a Terracotta Cluster context"

and I confirm that currently, there is “no” Terracotta distributed cache installed for our environment.

So our environment just has 2 independant IS nodes, but no cluster stateless, isn’t it ?

Regards

Hi Cedric,

what about Triggers and Schedulers?

Are the Schedulers supposed to run on both IS parallel?

Which Messaging Provider (i.e. for BPM) are you using?
Broker or UM?

Regards,
Holger

Today we uses no messaging systems… we’ve created in webMethods 2 kinds of simple web service descriptors:

• those wich make read only access to external databases
• those wich consume external existant web services (the last ones makes the write access to store data in our external databases)

We do not use any messaging system for the moment.

We do not use any Triggers or Schedulers. Where do you want me I take a look in my IS Admin, just to be sure ?

We currently do not use BPM, but for the next years, we probably will use UM for messaging.

Regards

Hi Cedric,

Schedulers can be accessed by the appropriate link in the navigation panel.

Triggers can be found under Settings → Messaging → Messaging Trigger Management or JMS Trigger Management.

Regards,
Holger

Thanks Holger.

To complete my previous reply, I forgot to say that all DB schemas used by IS1 et IS2 I’ve described above, are “all” on the same DB server (same Oracle server).

Maybe this information is crucial ? :?

Regards

Cedric,

above is Correct…

above is NOT correct. Stateless and Stateful cluster - both should have IS Internal shared. If it is not, they are two independent Integration servers. To give you a very simple example, if you have a scheduler in independent IS setup, the scheduler will be visible and will run only in the node where it is created. whereas, if IS Internal is shared, scheduler will be visible in the other node, and the other node will not execute when your first node executes it.

that’s fine…

correct… 2 independent IS; they are not called as stateless as ISInternal is not shared

Not really. Its about the schema and not the Oracle server. Two different schema in a single db server is same as two db server with one schema each. They are independent of each other, and none of the db objects are shared between two different schema/user.

HTH
Senthil

Thanks Senthil for these precisions.
Ok so, my 2 nodes are not staleless and really independent.

I’m going to deploy my group of IS, I will tell you if I meet any problem or issue.

Regards