E9.2 Elastic design for JDE servers

terryissackanichai

Member
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
 
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...
 
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.
 
Terry,
Could you achieve the scaling out / in of servers for HTML and AIS server?
Thanks
 
Your magic word here is uninterruptedly - something that we all are suffering from for years now 😅
Concerning GSI: This is highly prototype material and they don't have anyone in production using that and are explicitly NOT recommending it either. I talked to them at Quest.

The containerization is an interesting approach and is definetly going into the right direct, but keep in mind we are basically running services from the 2000s on a proprietary tcp stack with very picky jdbc/odbc database connections.
 
Back
Top