Is Active-Active Ent/App server feasible in JDE?

technojde

Member
Hi,

I have seen some posts here by other members wherein they have posted some steps re active-active enterprise server/app server. I am not convinced how this solution would work. my concerns are:

1> I believe JDE uses caching of tables/other info in their in-memory caches within all call object kernels. In a true active/active solution, the app request from the jas server to ent server would be agnostic (ie if you placed ACE/F5/virtual server as an interceptor between HTML server and Ent/app server). I'd also think all db requests are specific to a call object kernel so there should be a built in affinity between transaction req and one instance of the app server "cluster". I don't know how one would overcome that.

If DB triggers are used, what happens during upgrades (ie 812-->90)?
 
This has been possible since the inception of JDEdwards OneWorld (now known as EnterpriseOne).

I'm not sure what you mean by "true active-active". Active-active simply means that you have 2 servers running at the same time that can process requests and if one goes down the fail-over is automatic.

Perhaps you want to connect to one server for a request and then on the next request connect to the other server? Well then the answer is "it depends".

There are 3 layers at which you can balance:

1) Web Server
2) Enterprise Server
3) Database Server

Your "true active-active" does exist at the DB level with Oracle RAC but there will be some affinity or "preference" for one of the servers.

At the Enterprise Server level you need to use "IP affinity" to a server and then fail-over if necessary.

Web Servers can be either session or IP affinity but if you want to save yourself a lot of headache go with IP affinity. The costs and complexity of session affinity isn't always worthwhile.



Colin
 
thanks for the response Colin, like you suggested, my query had more to do with Ent svr "agnosticity", ie the web server being able to send requests to either ent server and get back a valid response. If web server 1 initiated a transaction on ent server 1, that would lead to ent server 1 having a user cache which ent server 2 wouldn't have. you could bind by IP I guess so that you always communicate with that ent server but that wouldn't be true server agnosticity since the other ent server can't pick up where the first one left.

Also, the specs in the spec folder would not be identical on the two ent servers. You could have a situation where the dd specs (ddtable) etc are different on 2 ent servers leading to app failures if the other server didn't have the updated specs. I don't think simple duplication would get you around that.

So, in my estimation, true, transparent active active clustering is not possible with JDE since there is no way to guarantee the old style, flat file based specs in the spec folder would be in synch. Even with batch servers, you maybe able to delegate different reports based on env/report type to different servers but one batch server cannot take over for another since the flat file specs will be out of synch. What you'd have is CNC or ACE/F5 based segregation of interactive/batch workload rather than transparent active active clustering

I would be very interested in knowing if you have managed to circumvent spec synching issues and if anyone has faced issues while supporting such clusters.
 
Hmmm..okay not sure where you're going with this or what the business requirement is but most systems operate in this same fashion.

"You go to whatever server you were first sent to unless something fails".

Is there something specific that you're looking for here? What is your business case or issue?

I have tons of customers runing active-active HA with no issues as do other consultants out there.

All of the details about "spec" files that you're speaking of are only really relevant for batch jobs so let me save you the trouble here..........batch jobs do not fail over. I repeat.........batch jobs do not fail over.

If a batch job fails then it fails and you have to resubmit the job after the node failure and it will simply run on the other enterprise server.

In order to have a batch job fail over you would have to do memory to meory replication of the 2 enterprise servers. This is not supported in JDE.

The other components of JDE that are kernel related all fail-ove very well on the Enterprise Servers.

Sure it's not perfect but it works the majority of the time.


Colin
 
Hi guys

Let me weigh in here a little.

The term "Active-active" has two connotations. With two application servers running, one definition has users connecting "round robin" - hence both application servers are used, but one might usually be more utilized than the other. The other term is true "load balancing" - ie, the ability to identify whether one of the application servers is less utilized and to place users on the server.

If your definition of "active-active" is the latter - then you are right, it is not possible to load-balance sessions in that manner.

But, Colins' question is a very valid one - why would you want to do something like that ? To ensure validity within a transaction boundary ? Very, very few high-available solutions can keep transactions operating when a server goes down.

So, once you accept that limitation of JDE, then it is perfectly possible to provide a pretty good high-availability between interactive kernels across multiple application servers. Utilize a load-balancing solution and provide persistence to ensure that, as colin stated, "You go to whatever server you were first sent to unless something fails".

ok - now to weigh into the batch job situation.

It is possible to design an architecture that will ensure batch jobs are "load balanced" - but as colin stated, it is NOT possible to "fail over" already submitted batch jobs. JDE is supposedly coming up with a "virtual queue" system - but I haven't seen it in TR9.1 - and I'll be pushing Oracle next week to explain why their queue redesign hasn't appeared yet.

It IS possible to create a "load balancing" queue solution - which checks to see what server is "available" and then move batch jobs to that specific server. If that server THEN fails, then the job will fail and you'll have to resubmit it. However, my solution CAN provide a certain amount of notification when issues such as that occurs. It requires a small amount of code running on the servers outside of JDE - but it is extremely efficient, and I've been able to architect the solution on all three platform types.

I am presenting a method of using a FREE solution to load-balance the HTML and JDE Application servers at Collaborate in Vegas. Yes - no F5 required and its a LOT easier and a LOT more configurable ! I can't provide details until Collaborate - but look for my session in April ! I'll be distributing a whitepaper to those that attend !
 
Thanks Jon and Colin, from an availability standpoint like you guys said, active - active clustering wherein both nodes can service requests simultaneously, this seems feasible, though with IP affinity. From a failover standpoint, like Jon stated, transactions cannot be failed over and if the appserver fails the transaction rolls back and the user session is terminated since the security kernel on the failed node is inaccessible and we need to start over. From a load balancing perspective, there is no guarantee of a real even split. I guess most customers can and will have to live with that.
 
Actually transaction roll back is great......depending on the transaction.

Batch jobs simply die but BSFN's typically fail-over and at most you have to hit "ok" again.

Jon --> The virtual batch queues didn't make it into 9.1.0.0 GA but should be there shortly (or so I'm told)


Colin
 
[ QUOTE ]
Actually transaction roll back is great......depending on the transaction. Batch jobs simply die but BSFN's typically fail-over and at most you have to hit "ok" again.


[/ QUOTE ]
Very true. The user gets a message telling them the kernel failed and to retry their transaction. Its very unlikely that a user is ever kicked out of the web...
[ QUOTE ]

Jon --> The virtual batch queues didn't make it into 9.1.0.0 GA but should be there shortly (or so I'm told)


[/ QUOTE ]
I'm planning on adding this on my list of things to shout at Oracle about in Broomfield next week - together with the whereabouts of portal for redstack !
 
Hi Jon,

Thanks for a insight about Load Balancing solution. I could not attend this years Collaborate so missed your session. If you can share the Load Balancing white paper that would be really helpful. Thanks.

Mohit Jain
ERP 9.0/9.1 on AS400/Linux
 
Hello Jon, could you share us your white paper about load balancing solution? It appears to be the "easy" way to enable active-active balancing (with the restrictions you said before).

Adan
 
Hi Jon... I'm new in this forum JDEList. I'm finding out information about how to setup two enterprise servers active-active for a same environment (ie PD910). We wan't use a cluster solution but I've heared tha using F5 it is possible implement this scenario.
Jon, Could you share us your white paper about load balancing solution? Do you have informartion about using F5?

Regards

Rodolfo Avila
Masnegocio
México
 
Back
Top