Forum Discussion
Feature Request: Node aliases or ability to add columns in Pool Member properties
Hello,
We use a local caching server between our lb3900 nodes and our appservers. This means that, in the Management web gui, every node in the Pool Members view shows the same hostname (the caching server's), which makes maintenance very tedious. If we could either a.) add the Description field to the Pool Members table (where we would add the app server name associated with the particular caching server's port) or b.) allow Pool Members to have an 'alias' of some kind for their hostname field, then that would solve this problem.
The ugliest solution would be to allow adding multiple nodes with the same address to the Node List, though that would necessitate disabling host level monitoring, otherwise the pings would be multiplied by X number of nodes, I imagine, unless you disable the host-level monitoring altogether.
-Andrew
5 Replies
- Kevin_Stewart
Employee
What LTM version are you running? Any version of 11.x has the ability to add arbitrary names and descriptions to pools and pool members.
- Martopoulos_162
Nimbostratus
I'm using 11.5.1. Do you know where that option is? The closest thing I see is on the Add Member Node screen. If you choose the "New Address" option instead of a node from the "Node List" option, you can, indeed, choose whatever name you want. However, if the address is the same as an existing node (as it would have to be since they're all added using the caching server's address), then you get an error like the following:
0107003a:3: Pool member node (/Common/test) and existing node (/Common/CachingServerNodeNameHere) cannot use the same IP Address (10.0.X.X).
- Kevin_Stewart
Employee
I do see what you mean. So maybe a silly question, but why use a separate pool for each VIP when they all contain the same IP address?
- Martopoulos_162
Nimbostratus
If I'm understanding your question correctly, the reason is that the caching server uses a different port for each appserver and application, e.g. port X goes to app1's instance of AppA, port Y goes to app1's instance of AppB, etc.
- afedden_1985
Cirrus
Couldn't you use the single pool with the member using service port 0 for the port. The VIP will have the send the correct port with the client request when it hits the server. The member IP/port combination would look like this 10.22.75.162:0 we use this method when we use the same pool for serveral VIPs. You just need to use a common monitor that works for your situation.
Help guide the future of your DevCentral Community!
What tools do you use to collaborate? (1min - anonymous)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
