• Introducing Dark Mode! Switch by clicking on the lightbulb icon next to Search or by clicking on Default style at the bottom left of the page!

E9.2 Elastic design for JDE servers

Dear Team,

I'm new to this community, hence my apologies, if there is something wrong in my way of asking questions. Please help me in getting a better understanding of the below scenario.

1) We are planning to design our JDE servers(Enterprise, JAS, AIS, RTE, BSSV) in OCI to be in an elastic model, where we will be scaling out(Adding new servers, not resources) and scaling in(Removing these servers) based on our workloads. What are the main factors to be considered while we do the scale in or removal of theses additional servers from a working environment?

2) How do we manage the logs generated in each of these servers which we are planned to be deleted at the time of scaling in?

3)Should we take the servers like BIP, Portal, Identity management also in the scope of elasticity? We have purposefully excluded the Database server and deployment server from our scope of elasticity.

A few of our findings while scaling down servers are as below :

Enterprise Server:
  • Should be able to handle the UBE workloads without terminating the Jobs(P/W).
  • Should be able to handle the ongoing transactions of Interactive application from JAS server without any business interruption.
  • Should be able to handle third-party interface logics.
JAS server:
  • Should be able to handle the HTML build requests uninterruptedly
AIS Server:
  • Should be able to handle the JAVA API requests uninterruptedly
  • To handle the loads from Orchestrations and ensure it can successfully interact with E1 servers
RTE Server
  • Should be able to perform Event Generation, Event transfer, Event Deliver without any disruption.



Thanks & Regards,
Terry
 

brother_of_karamazov

Legendary Poster
Dear Team,

I'm new to this community, hence my apologies, if there is something wrong in my way of asking questions. Please help me in getting a better understanding of the below scenario.

1) We are planning to design our JDE servers(Enterprise, JAS, AIS, RTE, BSSV) in OCI to be in an elastic model, where we will be scaling out(Adding new servers, not resources) and scaling in(Removing these servers) based on our workloads. What are the main factors to be considered while we do the scale in or removal of theses additional servers from a working environment?

2) How do we manage the logs generated in each of these servers which we are planned to be deleted at the time of scaling in?

3)Should we take the servers like BIP, Portal, Identity management also in the scope of elasticity? We have purposefully excluded the Database server and deployment server from our scope of elasticity.

A few of our findings while scaling down servers are as below :

Enterprise Server:
  • Should be able to handle the UBE workloads without terminating the Jobs(P/W).
  • Should be able to handle the ongoing transactions of Interactive application from JAS server without any business interruption.
  • Should be able to handle third-party interface logics.
JAS server:
  • Should be able to handle the HTML build requests uninterruptedly
AIS Server:
  • Should be able to handle the JAVA API requests uninterruptedly
  • To handle the loads from Orchestrations and ensure it can successfully interact with E1 servers
RTE Server
  • Should be able to perform Event Generation, Event transfer, Event Deliver without any disruption.



Thanks & Regards,
Terry
Oh that should be fun...
 

JEMILLER

VIP Member
Terry,

There is a lot to unpack here but it has been done to varying degrees going back to the Cisco Content Switch and through to various cloud load balancers and elastic scaling techniques. I'll put together an outline of considerations from my experience with a few attempts at this. In my opinion you will never achieve absolutely zero downtime but you should in theory be able to achieve zero "unplanned" downtime overall with acceptance that sessions will die on failed components when they experience a failure.

Give me a bit and I'll post my thoughts soon.
 
Top