webMethods

Of course there are cases where IS Clustering must be used, but in general the use of IS clustering is unnecessary.

• It’s not needed for load balancing.

• It’s not needed for failover.

• It’s not needed for interaction with the Broker.

• It is needed when session management is needed in a LB cluster. But the need for session management is relatively rare in automated business integrations.

• It is needed when multiple IS instances use the same Broker client prefix to connect to a single queue and the trigger has join conditions. This is also a rare case.

Thought I’d throw out this relatively extreme statement to see what sort of responses/discussion it generates.

Rob,

I have never been a fan of the IS software cluster. The fact that is called a cluster implies some functionality that is just not there, namely failover except in the rare case in which you have written a custom Java client that uses the TContext class instead of the Context class.

Load balancing when the workload of IS comes mostly from HTTP/S traffic is a no-brainer using a hardware load balancer or content switch. However, balancing the workload when it arrives in the form of messages retrieved from legacy message oriented middleware systems or JMS queues/topics is a bit more challenging.

What have you found to be the right approach in those situations?

Mark

For legacy MOM facilities, as it is with Broker, there isn’t dynamic load balancing available AFAIK. We’re limited in our choices to essentially statically segregating traffic in some way (e.g. order management via this queue/broker, financials on this other one, etc.) to spread the work. Failover generally provided by OS clustering and shared-mounted-by-active-instance storage.

Perhaps others have experienced or are aware of other approaches?

One approach is to use polling notifications to “listen” for arrival of messages in MQ, MSMQ or JMS queues and then publish a notification document to the Broker.

The trick is deciding on which box will do that, once the message has been published to the Broker the load balancing will happen correctly.

Mark

Ah, I was looking at if from the wrong perspective. What I was describing was LB and failover for the MOM itself, not for the IS instances connecting to it. My bad. There is indeed a way to distribute the work among multiple IS instances when interacting with MOM facilities.

We did this only with MQ Series. It may work similarly with other facilities but I don’t know that for sure.

One can configure multiple IS instances to connect to the same queue/queue manager. Only one of the IS instances will get a message at a time, much like what is done in the interaction with Broker. Thus, one can achieve failover and some degree of load balancing on the IS side when interacting with MQ.

We had 6 IS instances all connected to a single MQ manager. We could take down any of the 6 for any reason and not lose anything. MQ manager, however, was a single point of failure, as at the time there was no facility to cluster that (other than OS cluster and shared storage as mentioned earlier).

YMMV

Rob,

But isn’t webMethods stating the ‘PRT’ needs to be in a cluster to ensure documents are not processed multiple times?

I think I understand what you are saying, you trust the multiple IS instances to play with the shared queue nicely…

But what happens if an IS instance picks up an event, doesn’t ack, crashes… isn’t another IS instance going to pick up that same event? then if/when the first IS restarts, it will process the event creating a duplicate.

Or am I totally missing something?

I like Mark am not happy with the webMethods use of ‘cluster’ as an option for the IS isntances - if anything it should be ‘cluster-like’, and that would still be wrong…

We have an IS ‘cluster’ implemented, and are trying to architect in all the missing features… Breaking the cluster would help resolve some issues, but it raises concerns regarding above…

Regards,
Ray

“…the ‘PRT’ needs to be in a cluster to ensure documents are not processed multiple times?”

I don’t recall seeing anything along those lines in the docs. Is there something you’ve seen that you could point me to?

The scenario you describe “shouldn’t” occur in either an IS cluster or non-clustered environment. This is because the Broker manages how it hands out the events. The Broker has no notion about IS clustering. Doesn’t know about it and doesn’t care. If an IS instance picks up an doc, doesn’t ack and crashes, the Broker sees that the connection is lost. It is then free to hand that doc to another IS instance.

The original instance won’t see that doc again (at least not from the Broker) since it was processed by another instance. When the original instance is restored, it will do nothing with the original doc. For the PRT, since it doesn’t automatically recover activity that was in flight (it instead relies on a document coming from the Broker) the risk of dupes is reduced.

Any type of clustering actually increases the chance of duplicate processing (even the wM clustering guide points this out). In the scenario you describe, the risk of dupes comes when the first instance successfully completes everything except sending the ack to the Broker before crashing. In this case, two instances will appear to have processed the doc. That’s why additional dupe checking is sometimes warranted, depending on the specific integration.

I’m okay with the use of the term “cluster.” It provides some facilities–we just have to make sure we understand what those facilities do and don’t do.

Rob,

I have to admit, I have never seen my PRT statement documented anywhere… Your question got me thinking, and I guess somewhere, somehow, I was left with the impression that was a true statement. Guess I will have to follow up with wM to be sure.

Anywho…

Your comments about not clustering IS instances is really starting to interest me.

But one of your comments in your original post needs some clarification: ‘It is needed when multiple IS instances use the same Broker client prefix to connect to a single queue and the trigger has join conditions. This is also a rare case.’

So the key point above is the join condition in the trigger? Otherwise, multiple IS instances can use the same Broker client prefix?

Ray

Correct. Multiple IS instances using the same Broker client prefix can coexist just dandy without using IS clustering. IS clustering becomes necessary if any triggers use a join. This is because the first document of a join is persisted to the repository. The subsequent document(s) in the join may get routed to any of the IS instances that use the same Broker client prefix. The receiving IS instance needs to get access to the prior document(s)–which is stored in the repo so all the IS instances need to use the same repo, which can only be done using IS clustering. (Whew, that was lengthy.)

Hope that clarifies.

I’m mainly interested in the question of failover. In the white paper on high availability provided by webMethods, it does look clear to me that IS clustering alone provides an inadequate solution, since it “does not provide built-in failover for inbound requests from partners without webMethods IS.” This would be all of our partners. Relying on 3rd party failover/load balancing devices alone, however, seems to create the opposite problem: no failover for outbound services. The paper also notes that “services might accidentally get executed more than once for partners using guaranteed delivery” but I’m not sure why that is. So it seems like clustering may be necessary, if not sufficient, for failover. Since I’ve been tasked with developing a failover solution for our IS configuration, I’d be interested in hearing more opinions on this. Thanks,

Tim

IS clustering is very specific about what it provides for failover–it is provided only to clients that implement Context and TContext classes, which are used for “inbound” processing (page 14 of the clustering guide). There is no other direct support provided.

Even in the Context/TContext case, the servers don’t really do anything–it’s up to client to notice that the IS instance it was talking to disappeared and to try again with another instance. This sort of “notice the failure and try again” approach is exactly what generic HTTP/FTP clients can do with an LB cluster, so there really is no need to use Context/TContext–just use HTTP/FTP with some retry logic.

Failover for outbound services can be done in a couple of ways. It depends upon how your processes are initiated, how they function, and what components you’re using.

If your outbound activities are kicked off via a scheduled task, then you get a degree of failover since the scheduler is IS cluster aware. The process must be designed to such that if an IS fails in the middle of processing the next run will either pick up where it left off or more simply, just run the whole process again. Use of TN can help in this regard. The checkpoint/restart services can also help (chapter 6 of the clustering guide).

Hope this helps. With a bit more detail about your processes we may be able to provide additional general guidance.

You need to write clever handling cookies client to load-balance using hardware LB, or just use hardware LB set up with cookie affinity.

• It’s required when you want to use serial triggers. Or in other words, if you don’t use cluster and use multiple IS instances with same client prefix, strange things may happen.

Has anyone come across a software based open-source load balancer?
Wanted to see if there is one out there. That way as wM recommends, use a separate load balancer instead of the one available with IS 6.5.2
Thanks.

Cookies are used for session management. Session management is needed if a given interaction between the client and server requires multiple exchanges. Most often, however, the client and server interaction is “here’s a doc” from the client, “got it” from the server. One exchange where session management is not necessary nor is affinity (stateless service).

For cases where there are multiple interactions in single session, cookies or Context/TContext classes can be used. When using cookies, you’re right that the client must retain the cookie and pass it back otherwise a new (redundant) session will be started on the server.

I’ve seen affinity needed when using https/ssl for the ssl handshake. In this case affinity is based on IP, not cookies.

I hadn’t seen anything along those lines in the docs. The behavior of multiple clients connecting to the same queue and order being retained has been around in Broker well before IS ever became a Broker client. Can you elaborate on the “strange things?”

I think Apache could be used in this role, though I’ve never investigated it in detail (let alone implemented it) so I may be off base.

For others that come across this thread, the wM docs state that the load-balancing feature of IS clustering is deprecated. An external load-balancer is now the “official” thing to be doing.

Your company just paid a zillion or so dollars for webMethods licenses. They can’t afford a few more thosand for a decent hardware load balancer?

The Microsoft Network Load Balancing Service may be an option for you as well.

Mark

Yes, and if you’re using hardware LB (and no IS cluster) you must pay attention, to configure it correctly, so requests with cookie from one server will not come to the other. It may be done by configuring affinity on cookies on LB, or just using HTTP/1.1 features - puting many requests in one HTTP connection. For the latter you’ll need a steady flow of requests.

“Strange things” consists of:

• locking the queue for a long time (sometimes queue was locked for hour and two, and then - it with no intervention - it became unlocked and started working)
• low performance
• core-dumps of Broker Server

But in my opinion, serial triggers a rarely (or even - never) needed. It might be a sign of bad design, as it is serialization at very high level - thus radically impacting performance from one side, and from the other - leaves many unsecured ways of breaking the serialization (ex. invoking via SOAP or from Developer)[1]. I always prefer to fine-grained serialization on critical resource (ex. rows in the database) and then - there shouldn’t be any other way to break needed serialization.

[1] - One thing I’ve never checked (as I don’t use serial triggers :-)) - does resubmitting the service from WmMonitor, that was invoked by a serial trigger, break the serialization (as there may be two threads invoking the service).

Thanks for starting a great discussion thread. Personally, I am not happy with how webMethods has implemented clustering.

A few weeks ago, one of the servers (P1) in our production cluster choked. All connections between this server and the RI server were lost. The other server (P2) also was not doing so good. It had only 3 out of the 10 connections left. We decided to restart P1, establish connections with the RI server, add it back into the LB, drain P2, restart P2, establish connections with the RI server and add that back into the LB.

However, after we re-started P1, we were not able to add the connections to the RI server. After several tries, the solution was to remove the clustering between the machines. After we did that, we were able to create the reverse invoke connections between P1 and RI.

Moreover, we were told that we had to restart BOTH the servers in order to re-establish the cluster connections!

Not a very useful cluster!

Rob,
Priceless discussion thread, in my view. You were absolutely right in saying about set of non-clustered IS operating with same client prefix. We recently encountered an issue with PRT documents. In our scenario, When a process execution moves from one logical server to another, status control document and Process Transition document(that comprise the join in the trigger) were picked up by different servers. The model simply hung with the state marked as ‘STARTED’. To me, it looks like we definitely have to enable webMethods clustering and make the servers share the same repository.

Many Thanks for the detailed information given in this thread.

Best Regards
Sivaraj Lenin

Glad the thread has been helpful. That’s what wMUsers is all about!

Thanks for the scoop on the PRT activity. I did not know that there was a join condition for normal PRT activity. This would jive with what Ray Z. was saying about the PRT needing an IS cluster. Have you seen anything in the docs about this? Would love to see that to further my understanding.

Hello Rob,
I searched the documentation regarding PRT internals, there are not many details. The hint I’ve is that when these process internal documents are processed, the PRT inserts an entry into the WMPROCESS table with the physical address of the server. This happens for each step transition to a different logical server.

I’m just wondering whether can we configure the non-clustered Integration Servers to share the same repository (this has to happen without enabling clustering).

Kind Regards
Sivaraj Lenin

Yeah, I knew about publishing and the WMPROCESS table update for the step transitions. What’s unclear is why an IS cluster would be needed in this scenario. It is my understanding, which may be wrong, that the PRT tables can be shared among multiple IS instances without IS clustering. The PRT tables are not part of the repository.

The repository would be used when a trigger has a join condition. I looked through WmPRT package and unfortunately the trigger conditions are not exposed. Based on your observations though, it seems a safe bet that a join is used.

Sharing the repository is pretty much what IS clustering is all about. So if you share the repository, you have an IS cluster.

Hi, I am using JMS Adapter with IS clustering. The requirement here is serial processing should be used strictly. The data flow goes like. Source system calls a web service hosted on IS → web service puts source data as JMS message on the queue → JMS notifier notifies to Broker → Trigger invokes Flow Service → Flow service submits data to RDBMS. Two IS are clustered and one JMS queue is configured. For example, web service has 15 msgs as input. Those 15 msgs are put on JMS Queue. JMS notifier publishes 15 msgs to the Broker. As IS clustering is used, we have trigger subscribing to those document on each IS. so 15 msgs will be divided and sent to both the IS in cluster. In this scenario, how to guarantee that messages will be processed serially as they put on the JMS queue ?

• Nilesh

There can be no parallel processing at any point in the integration.

The source system must be single threaded, calling the web service one at a time and waiting for a positive response before submitting the next.

The IS hosted service publishes the document (I assume you’re just using pub.publish:publish) to the Broker. This service should not create threads in any way and probably isn’t unless you’ve done something explicit.

The Broker will deliver documents in “publisher order” if the triggers are configured as serial. This means only one of the IS instances will get the documents as long as there are more in the queue (see the pub/sub guide for a better description). If the IS that is processing fails, the Broker will notice and give that document and subsequent documents to the other instance.

The IS service invoked via the trigger must not create any threads.

If you follow these, your messages will be processed in order. Note that IS Clustering isn’t needed for any of this to happen. The IS instances simply need to use a the same Broker client prefix to get this failover capability.

Anyone successfully implemented JMS adapter polling notifications on an IS cluster such that both nodes in the cluster can poll a JMS topic using a durable subscriber?

So far, no matter how I configure it, I get a “[BRM.10.2002] JMS: Client ID “” is already in use.” error when I enable the second polling notification.

I was getting this same error before spending a full day configuring an IS software cluster. Now I’m getting the same error with the cluster. What a waste of a day.

Note that a multi-node Websphere Application Server cluster in which each node in the cluster is running multiple message-driver beans can subscribe to the same JMS topic using a durable subscriber when the topic has been configured with SharedState=“true” and the wmjms.properties file is configured with the com.webMethods.jms.clientIDSharing=true property and placed in the WAS classpath.

If this can be done with Websphere, shouldn’t you be able to do the same with IS JMS adapter polling notifiations?

Mark

Page 30 of the JMS Adapter User’s Guide states:

So, this just once again affirms that there is almost no reason whatsoever to consider using an IS cluster.

Still trying to solve this by putting the “clientIDSharing” property in the JMS Adapter classloader’s path. No luck so far.

Mark

I wrote a Flow service to load the com.webMethods.jms.clientIDSharing=true property and made it a startup service.

I then configured the broker settings on each IS to use the same client prefix, confirmed that the JMS topic was set to SharedState=true, enabled the adapter connections and JMS polling notifications and published a test message to the topic.

Only one IS node picked up and processed the JMS message. Mission accomplished. No IS cluster needed (or wanted).

Mark

What about Chapter 1 - page 10 “What is Clustering / reliability”? It says:
“… Clustering makes it possible to deliver ‘exactly once’ execution …”
How should I read this?

Rob, I am interested to know. Is it correct that you would use a third party load balancer (which has the advantage of single IP/hostname for the cluster) and not use IS clustering at all? Assuming one doesn’t need the session/transaction management, but is interested in the “execution only once” of messages.

What about the scheduled services?

It is only needed for scheduled services if you want to schedule the same jobs on multiple IS instances and want the scheduling to be coordinated across servers.

Scheduled jobs and JDBC adapter polling notifications are two cases in which the extra complexity of the IS software cluster might be warranted. I would look for ways to design that need out of my solution if I had any choice whatsoever.

Extra complexity + low to no value added = bad idea.

The (inverse) context of the thread is “when to use IS clustering” to get the features associated with high availability. Scheduled services are not such a feature. One doesn’t introduce clustering to get the ability to run scheduled services. Rather, they are a facility that can be impacted by the introduction of any sort of clustering.

As such, one needs to consider the impact to scheduled tasks when designing a highly available solution. For example, scheduled services are supported by “IS clustering” but if one uses only a load-balancing cluster (and not IS clustering) then an approach must be devised to ensure that services that should be running only on one server at a time do so. One approach is to use an external job scheduler such as AutoSys.

Thanks Rob, I understand your point of view. However, I have the opinion that scheduled jobs should be part of an HA environment. The timing of when particular jobs run is critical for our business. Introducing an external scheduler like AutoSys or even simple Unix crons, not only makes deployment a lot harder, it also introduces another single point of failure.

I haven’t used IS clustering yet, but what is it that makes you guys want to move away from it? Does it introduce lots of complexities/problems? or do I missunderstand you on this?

I think most of this preceeding posts in this thread are focused on the reasons not to use IS clustering. In short, IS clusters add lots of complexity and very little value.

Scheduling jobs in IS rather than a robust, enterprise-class job scheduler is counter-intuitive and, IMHO, usually only done because of lack of interaction between developers building integrations and the operations staff supporting them. Sure, its convenient… for developers anyway, but that’s hardly a sufficient argument.

Most of my clients that were using IS clusters believed they were getting far more value than was actually being delivered (e.g. failover and superior load balancing). Many of the challenges they were having with ensuring a high degree of IS stability stemmed from the added complexity of an IS cluster (or reverse invoke servers).

So, as I always say, “simple is good”. This is especially true when additional complexity doesn’t add value.

Mark

Let me rephrase that a little: scheduled tasks should operate correctly in an HA environment. As I stated earlier, one doesn’t introduce clustering to get the ability to schedule tasks. Rather, one introduces clustering to provide HA features (failover, load-balancing, etc.). One must consider how scheduled tasks, JDBC notifications, flat file polling ports, DB access, etc. will behave in the cluster.

You can certainly use IS clustering to get scheduled tasks to operate as desired (only on one instance at time) in the cluster but that isn’t the only option. In addition to the external scheduler that I mentioned, another approach is to enable the tasks only on one instance. If that instance fails, manually start the tasks on the other instance.

Yet another approach is to implement a “poor man’s” cluster-aware facility (I’ve done this in a couple of places)–Modify your scheduled services to check a config file. In that file is a list of the IS instances, in order or primary to secondary, etc. When the scheduled service runs on a given instance, it loads that file. If the first name in the list matches its own name, it continues. If the first name doesn’t match, then it pings the other IS instance. If the other instance responds, the service stops. If the other instance does not respond, the service checks the next name in the list. When it finds its own name and all instances that are above it in the list have failed to respond, it continues to run.

I’m sure there are other approaches that could be followed.

This is an argument for, not against, using a robust scheduler such as AutoSys. For example, the scheduler within IS does not track what it does. If the IS environment was down at noon, and a service was supposed to run at noon, that service will be missed that day. AutoSys detects past jobs that have been missed and runs them.

The deployment becomes an AutoSys team task, not an IS team task. “A lot harder?” I think you may overstate the case a bit. For the “single point of failure” one needs to implement clustering for AutoSys too.

Don’t get me wrong, committing to a robust environment for AutoSys is not a trivial undertaking. But neither is committing to IS clustering and the repo server.

The first few posts in this thread point out the issues. And Mark summarized it quite nicely. IS clustering has been successfully used–but it comes with a cost and it doesn’t provide nearly the level of functionality that people usually attribute to it.

Folks,
Interesting discussion, going forward I would suggest not wasting your energies with any of these options presented in this thread. By the end of this year wM is throwing out the current clustering using repository and are incorporating the offering from tangosol. If my resources are correct they will be using their coherence product. Here is the link if anybody wants to review the product.
Excerpt from [URL=“In-Memory Data Grid | Oracle”]http://www.tangosol.com/coherence-overview.jsp[/URL]

"Tangosol Coherence enables in-memory data management for clustered J2EE applications and application servers. Coherence makes sharing and managing data in a cluster as simple as on a single server. It accomplishes this by coordinating updates to the data using cluster-wide concurrency control, replicating and distributing data modifications across the cluster using the highest performing clustered protocol available, and delivering notifications of data modifications to any servers that request them. Developers can easily take advantage of Coherence features using the standard Java collections API to access and modify data, and use the standard JavaBean event model to receive data change notifications.

Tangosol Coherence provides coherency of data in a cluster, ensuring data integrity even for cached data. By managing data safely in the application tier, applications can scale much higher without significantly increasing the load on shared enterprise resources, such as database servers. This enables organizations to much more accurately predict the cost of scaling an application up to the enterprise, and provides a higher degree of confidence that the application will continue to perform well as it scales up."

regards,
Adnan

The title of the thread “IS Clustering to be avoided.” If wM throws out the current clustering facilities within IS, then those that follow the original advice of this thread are in good shape! Even so, users of 6.1 and 6.5 will be around for some time, so a discussion of alternatives isn’t a complete waste.

I would submit that the option of using a load-balancing cluster is viable, indeed probably necessary, even when (if) Coherence is integrated within IS.

The description is interesting. I wonder how wM wiill leverage it? After all, IS is not an “application server.” Its focus is different than the applications one typically finds implemented within WS, WLS, JBoss, etc.

If we look at the clustering features currently provided:

• Session data management (when mulitple interactions with IS for a single transaction is needed)

• To support join conditions for Broker subscriptions

• Coordinated scheduled tasks–a task is only ever active on 1 server

• Coordinated ART notifications–a notifier is only ever active on 1 server

Each of these would presumably be retrofitted. I assume, too, that additional facilities would be modified to support clustered operation.

TN has the notion of a “TN cluster” which doesn’t require IS clustering. TN instances share a common DB for the run-time data, and can directly communicate to tell each other “refresh your meta-data cache.” This would seem to fit in with what Coherent does–assuming wM updates TN for this!

I assume there will still be a persistence facility of some sort. It would seem to be a prerequisite for a robust solution.

Rob u miss interpreted “going forward” and “wasting your energies”. Both are mutually exclusive :). If you can live with current IS clustering there is no point reinventing a wheel…

I’m confused. Can you elaborate on your clarification?

We are implementing here a HA architecture.

For that we defined several IS with Microsoft NLB and without IS cluster.

But we have other integrations that are trigered by:

• Schedule Tasks
• Adapter Notification
• Broker Triggers

how can I make this things continue to work if one IS crashes without IS Cluster ?

I read that for Broker Triggers I can do that defining the same broker prefix in two IS.

But what do you suggest for

• Schedule Tasks
• Adapter Notification
  ?

Thanks

João Caseiro

I guess I missed this back when it was posted.

It is indeed correct that I’ve implemented solutions using a third party load balancer without using IS clustering.

IS clustering doesn’t “make possible” exactly once execution. It certainly eases some of the issues–like scheduled tasks that should be run on just one server at a time, or adapter notifications that need to be processed just once–but it isn’t a requirement.

Much of the clustering guide overstates the capabilities. Well, actually it really just has descriptions that are easily misinterpreted. For example, the load balancing feature, which has now been deprecated, has as a footnote “oh by the way, load balancing works only for http.”

IS clustering is scheduled to have an update soon, rumor has it. I look forward to seeing what changes will be available.

For scheduled tasks:

• Use an external scheduler
• Build a “poor-man’s” facility to make sure just one server runs a given task at a time. A DB table logical lock (the presence/absense/status of a record), a file-based semaphore, or any other type of “I’m running, you don’t need to” approaches can work.

For notifications:

• JDBC adapter notifications are really just scheduled tasks (a thread polls for activity). So do your own polling. Use one of the mechanisms above to ensure just one server is processing. This is exactly what the IS cluster does–so you’ll want to decide which to use (wM-supplied or your own custom facility) if notifications are a big part of your environment.

Okay, now the the big question, how can I get the same behavior (i.e. two IS servers w/client prefix matching) to subscribe and only one getting the document) using JMS Triggers?? JMS does not use the Client prefix configuration in the Broker settings.

Both IS 1 & 2 are processing the JMS triggers twice for each server. not like the local trigger behavior

(I’m using 7.1.1)

The JMS Adapter’s MessageListener notifications are not supported in a clustered environment. A new feature was planned to bring JMS capability into IS triggers. pls check with PD if its available in 7.1.1.

Mark, Rob - What has your experience been with IS712 and its utilization of Tangosol and Coherence? Do you still feel that the potential issues caused by using IS’s clustering far outweigh the benefits? Or have you found that wM has fixed the bugginess / querki-ness with previous IS-based clustering?

I haven’t had the opportunity to use IS clustering with the new facilities. From the docs it seems that the underlying technology has changed but the basic features provided are the same. I think it still holds true that one needs to understand what is provided by IS clustering and what is not.

Used clustering with tangosol for 7.1.1 and 7.1.2 upto six nodes, works as designed, make sure u have all the core fixes installed.

We are currently looking into implementing High Availability for IS 7.1.2 and wanted to know if Clustering is a better option then say Active Passive through some sort of mirroring replication at the OS level.

The idea is to be up 24-7 with as little down time as possible. We don’t really need more processing power but if clustering makes high availability easy it would be a choice.

IS does not officially support active/passive.

A load-balanced cluster would provide what you’re looking for. A 3rd party load-balancer in front of 2 or more identically configured IS instances will allow for planned and unplanned outages of any single IS instance. You’ll need to make sure your integrations function properly in such an environment.

So clustering is probably not the answer? Does IS do package replication without being clustered?

We use open source load balancing right now so integrating that wouldn’t be that hard.

Package replication does not rely on IS clustering. Critical to success is that each IS instance in the load-balanced cluster should have the same configuration and the same set of packages.

If you use a load-balanced cluster, you may need one or more features provided by IS clustering. The key is to understand what IS clustering provides and whether or not any of your integrations need any of those features.

Thanks. This is all about High Availability…

We are currently planning on exploring package replication with an external load balancer.

The plan as it stands is to have two identical IS machines running and replicate packages between the machines (hopefully automatically through IS). Only one will get traffic (act as primary). In the event of a failure (IS or Hardware) we will reroute traffic to the second server. This should keep us within our SLA (we are still negotiating timeframes).

We only use IS and Trading Networks for document processing so we should be ok.

Any other thoughts?

I’m not sure why the load balancer would come into play with package replication. Packages need to get to all IS instances in the group.

Having a primary and secondary IS seems okay but I’m not sure of the benefit of letting one sit idle. I would just plan to have them both active.

Keep in mind that TN has its own notion of clustering too.

For IS, you’ll need to consider scheduled tasks and how those should be managed in the cluster.

Are you using Broker?

The secondary IS would be for emergency if the primary went down. Our transaction volume is low but we need very good up time. The idea is to have a secondary ready to become primary in less than a minute.

At this point we would not use IS clustering at all as I am looking for a really simple solution to High Availability. (Sorry this discussion probably doesnt belong in your Cluster thread… )

Did not know that yet. I will try to track down the docs on this.

I read up on the scheduled tasks and I am pretty sure they can be controlled per node.

No Broker…

TN doesn’t call it clustering, but it is basically both IS instances sharing the same TN DB and being configured to notify each other when TN items change (profiles, doc types, etc.). Just wanted to mention that in case the lack of “TN cluster” in the docs causes confusion.

“I read up on the scheduled tasks and I am pretty sure they can be controlled per node.”

Yes. Indeed, the tasks on one node have no idea that another node even exists. So you’ll need to decide if the tasks on the secondary node can be enabled or not. Some of your integrations may be such that only one at a time can be running.

I will be testing some solutions this week and will let you know how it goes. (and probably have more questions)

“the tasks on one node have no idea that another node even exists. So you’ll need to decide if the tasks on the secondary node can be enabled or not. Some of your integrations may be such that only one at a time can be running”…

If the scheduler if you set the “Any cluster node” then each of IS nodes (that are in cluster) know it running on the one of the node and not chance of duplicate thread running as far I seen the behavior on 712 case and no issues noticed with the “Any” setting:

May be my understanding the above comment might be wrong…sorry just in case:

HTH,
RMG

Reamon,

I’m interested on this topic. Currently, we have a ver simplistic architecture. We have two clustered Integration Servers. If I don’t clustered the two IS, then how can I be sure that the scheduled tasks will not overlap? Basically, I don’t want the second IS process the same file if the first IS hasn’t completed yet.

From an earlier post in the thread…

Yet another approach is to implement a “poor man’s” cluster-aware facility (I’ve done this in a couple of places)–Modify your scheduled services to check a config file. In that file is a list of the IS instances, in order or primary to secondary, etc. When the scheduled service runs on a given instance, it loads that file. If the first name in the list matches its own name, it continues. If the first name doesn’t match, then it pings the other IS instance. If the other instance responds, the service stops. If the other instance does not respond, the service checks the next name in the list. When it finds its own name and all instances that are above it in the list have failed to respond, it continues to run.

When the other instance in the list responds and instance that ran scheduled service stops execution, how would it let know other instance to run the job that responded?

Thanks Reamon. That’s an interesting way of doing it. Why do you think this approach is better than just using the IS software cluster?

If the IS clustering functions provide facilities you need then it is definitely the way to go. The facilities provided are covered at the start of this thread–and 8.x may have a new feature or 2 that I’m not aware of.

I wouldn’t introduce an IS cluster just for the scheduler though. As the thread notes, there is administrative overhead associated with it yet it doesn’t provide the level of functionality one typically associates with “cluster.” The main point of this thread is “be aware of what IS clustering does and does not do.”