Changing to PASOE.

ron

Member
OE 11.7.4 on Linux

Our prod DB is on a Linux server. It has four Windows hosts that connect to it that each support a classic AppServer (set to have 5 agents) -- with load-balancers.

Our UAT and TEST e

(This post got truncated! I'll have to re-type it!
 

ron

Member
OE 11.7.4 on Linux (Nutanix)

Our prod DB is on a Linux server. It has four Windows hosts that connect to it that each support a classic AppServer (set to have 5 agents) -- with load-balancers.

Our UAT and TEST environments are set-up similarly.

We plan to move from the existing "classic" AppServers to PASOE (and then to OE12). We also plan to replace all of the Windows hosts with Linux. We understand the procedures needed for this transition.

What we don't know is the best future configuration.

Should we keep the same topology and have every PASOE AppServer on a separate host?

The existing AppServers are in pairs with a load-balancer between each pair. Is that a good idea?

Should we have fewer PASOE hosts and increase the agent count?

Should we put all PASOE instances (4 of them) on a single host? Should we put all the PASOE instances on the same host as the database??

Any comment would be very welcome!

Ron.
 
Last edited:

peterjudge

Member
Should we keep the same topology and have every PASOE AppServer on a separate host?

Given that you're load-balancing, I'd think yes. You're already using networked db connections so there's no consideration of performance impact there.

I'd be curious why the load-balancing is in pairs when there are 4 AppServer brokers. But regardless, if you load-balance across a pair of AppServers, then in PASOE-world have 2 hosts, each with their own PASOE instance. Each instance should have 2 MSAgents configured (one as a warm spare*), and the agents can start with 10 initial ABL sessions (so merging those 4 AppServers into 2 instances). You should also configure the maxConnectionsPerAgent property to be at least 10 (so that all of those ABL sessions can be used concurrently).

If you have "APSV" (ABL or Open clients) you need to configure sticky sessions in the load balancer. If you also serve REST (or SOAP or WEB) requests then it's a little more complex.


* this is useful when you inevitably run into application memory leaks in the application code, and an agent's memory grows and grows and grows ... Since the algorithm for allocating work to the sessions (and agents) is MRU to avoid switching threads or processes, you will typically see the first agent being used first and running into any issues. If this happens you can trim that agent - returning memory to the OS - and the second will pick up the work seamlessly. You can also configure a minimum number of agents, and so then the isntance should automatically start another agent, for the new warm spare.

Should we put all the PASOE instances on the same host as the database??
If you're running networked db's now, i would stick with that. It gives you more opportunity for scaling and load-balancing.

HTH,
-- peter
 
Top