Database and Apppserver port range set-up

Yes.  You should define discreet port ranges for each broker, whether database or AppServer.  Do not use default ranges and do not overlap ranges.  Also stay away from low ports (<1025), high ports (dynamic range: >32767), and anything defined in the services file.

This approach takes a little more work up front but it pays dividends in firewall configuration and application troubleshooting.

We are using overlapping ranges for years now. Example: Database and DataServer port range 3000-5000. We have never manually altered this (!). Are you sure you must not overlap? Does OpenEdge nog automatically determine free ports because all components belong to for example the same AdminService?

And if yes, what kind of problems can occur when overlapping port ranges?

I didn't say that you *must not* overlap port ranges.  That would imply that it doesn't work.  It does.  And obviously it is the simplest way to deploy if you want to avoid strictly unnecessary work.  But I would call overlapping port ranges a worst practice.  It is something that you *should not* do, IMHO.

How much of a problem it might pose depends on your situation.  I have internal servers that each run dozens of DBs, each with 4GL and SQL brokers.  There are some AppServer and WebSpeed brokers as well.  Some of my clients' machines are similar, though on a smaller scale.  

A range of 2001 ports seems large, and it is.  If you have two or three brokers on a given box then probably it won't be a problem, as long as it *stays* at two or three.  But things tend not to stay the same forever.  As you add more and more brokers you are dividing that large range into smaller and smaller chunks.  Those chunks can be made smaller still if port numbers within them are already defined in the services file as the brokers will skip those ones when giving ports to servers.  This is particularly problematic on Linux boxes where the services file is full of unnecessary garbage after installation.

The real problem is when you run into an error because a broker can't spawn a server.  Everything might work just fine right up until that point but there is really no gauge you can look at to see how close you are to that point of failure.  You may be okay when adding one more broker to the box, but if you do that enough there will come a time when you won't be okay and you will have errors.  When the problem happens, then you ask why didn't the server spawn?  Are the startup parameters wrong?  Are all the ports in use?  Where are they being used?  I've been down that road more than once and it's a pain.  Moreover it's a preventable pain.  Others may disagree but I prefer to plan not to have errors than to not plan and have them eventually.

Nice answer Rob .. it's so often the 20:20 hindsight that proves the case.

The -minport -maxport parameters to restrict port ranges used by Brokers were introduced way back in v8.2 to assist in tightening security with Firewalls etc. They're also there for the ubrokers. Like any of the startup parameters, it doesn't mean you have to use them and we put defaults in place when you don't.

As Rob highlighted, having distinct port ranges helps the admin, if there's a problem making connections to a specific database, you immediately know which port range to target. If you take this one step further and define distinct sets for your secondary login brokers, even better. It also makes VST reporting easier, if you're using that .. it's up to you.

Another consequence, is that there's nothing stopping a client from connecting DIRECTLY to the port a (spawned) remote server is listening on. (ie not the Login broker's port, the server's port in the minport maxport range).

So on a badthings happen sort of day consider the following:

Typically test databases are restored with the same name as production.

Production database is started with -S 3000.

Test database is started with -S 3010.

Both use the default -minport 3000 -maxport 5000 range.

Test database has since been shut down or dbdowned.

The production database now has a remote server spawned listening on port 3010.

If the test database were to be started at this juncture, it would fail with: The port 3010 is already in use. (12036)

But it isn't.

A developer/tester doesn't notice that the test database is down, or their session crashed and typically just re-runs their connection to 'do stuff' again: CONNECT -db dbname -S 3010

They are now connected to the production database.

Now if that person runs (say) a performance benchmark on a massive delete code enhancement,

it would impact the production database instead of the test database which would be a really bad thing .. avoided by having distinct minport maxport ranges ;)

m2c

I'm very thankful for your answers/information!

We also use AppServer brokers in stateless mode. Because of this STATELESS mode the port range for the agent (for example 2002-2202) doesn't need to be configured in the firewall because the client machines don't need to reach it (again, this is because of the stateless mode). But if I read the information above, can this nevertheless cause problems if you use many Appserver brokers in STATELESS mode with same port ranges for the agents?

Yes. Take a look at this post by way of example with the AppServer ports:

Appserver problems: agent/broker communication issue or fault in OpenEdge 11 64bit

community.progress.com/.../8877.aspx

It's not specific to 64-bit btw ...

At the end of the day it's entirely up to you, you don't have to, but need to be aware of the consequences in not doing so.

Thank you rcluer.

The article you linked to mentions a state-reset AppServer. We use stateless (and so the port range 2002-2202 is not used for client connections). So I still wonder If we have to set non-overlapping port ranges for stateless AppServers...

The srvrMinPort and srvrMaxPort options apply to all AppServer types and applies to the Agent connections, not the AppServer's clients.   Because ports are an OS resource, all processes compete for using them and the first process, of any product, to allocate it wins.   If you run multiple AppServers with many Agent processes it may be necessary to define different port ranges, especially if that range coincides with other OpenEdge or non-OpenEdge processes.

Hope this helps

But this Article (knowledgebase.progress.com/.../P111654) says:

srvrMinPort and srvrMaxPort do not matter if the AppServer operating mode are Stateless, or State-Free.

That does not 'match' with your answer...?