Forum Discussion
LTM Policy based External VServer. New need: use it also as proxy for PostgreSQL DB
Hi!
I got some new challenge for my F5.
I have F5 Act/Stb cluster running in Azure, 16.1.3 Big-IP software version.
F5 has been divided into 1 external VServer that has LTM policies defined.
Based on HTTP Host in request, it decides to which Internal VServer the request should be routed to.
It was simple and efficient until I got a task to make F5 a proxy for PostgreSQL DB.
Before that I've had new request with HTTP Host: xyz.acme.com, so I added new DNS record pointing to my Big-IP and putting new LTM rule that was forwarding the request to desired new Internal VServer.
But now it's a VServer for PostgreSQL connections.
A drawing below and a question: How can I create LTM rule that identifies it's SQL connect to PostreSQLand my F5 will route it to desired Internal VServer?
I get that for http protocols, but you cannot read an http header on a PostgreSQL connection. Is there an option for NO HTTP host? If so, try that.. although, you'll forward every garbage packet, too.
I understand adherance to design, as well, but maybe that's the design for http. You can resolve your issue right now by creating a new "external VS" that listens on the appropriate port and selects the primary DB box. If you're concerned about things like persistence, maybe enable universal persistence, if needed.
- AubreyKingF5Moderator
Why not make a 5432 virtual? Same IP address.. different port. New VS with no http resources eaten up.
- shadow82Cirrus
Doable, but breaks the scheme.
Currently we have there 1 External VServer and 41 Internal VServers.External VServer gets the request, checks HTTP Host URL and redirects traffic to Internal VServer X
(small example below):I'd like to keep this way without making exceptions if possible. I need to have it scalable
I don't know if next week there could be another - new - PostreSQL DB proxy necessary
- AubreyKingF5Moderator
I get that for http protocols, but you cannot read an http header on a PostgreSQL connection. Is there an option for NO HTTP host? If so, try that.. although, you'll forward every garbage packet, too.
I understand adherance to design, as well, but maybe that's the design for http. You can resolve your issue right now by creating a new "external VS" that listens on the appropriate port and selects the primary DB box. If you're concerned about things like persistence, maybe enable universal persistence, if needed.
Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com