Forum Discussion
Adding pool member (with same IP different ports) to multiple pools
What is the easiest way of adding pool member with same IP different ports to multiple pools?
Current setup example:
VS_100 = IP: 172.20.1.21, Port: 100
Pool_100 is with pool members:
App_01:100 = 172.30.1.16 port 100, priority group: 80
App_02:100 = 172.30.1.18 port 100, priority group: 40
Same setup goes for VS_110, VS_120, VS_130, VS_140, etc.
Now I need to add a pool member with the below format to each of the pools --> new IP but same port, and lower priority
New_App_03:100 = 172.30.1.20 port 100, priority group: 20
Any thoughts on the best way to add this? Either via CLI or GUI? Any F5 KB articles? Thank you!
- kristine_vAltostratus
Hi guys!
Thank you for the responses!
The plan that we've came up with so far is:
1. creation of new node
on tmsh, create ltm node <node name> address <IP address>
2. add new pool member to existing pools (keeping it in force offline first)
on tmsh, modify ltm pool <pool name> { members add { <new pool member name>:<port> { priority-group <number> session user-disabled state user-down } } }
3. Sync the devices
for testing, the plan is to enable the new pool member and disable the existing pool members. We assumed that this will test if the newly created node can accommodate all the connections.- Leslie_HubertusRet. Employee
Hey kristine_v - sounds like a solid plan. Can you please let us know if it worked after you're able to go through everything? If it does, I can then mark your plan as the Accepted Solution so other users with the same challenge can easily find the answer.
kristine_v You shoud be able to do the following in the CLI and then just change the pool name for each pool that you want to make the change to but you only have the create the node once.
create ltm node New_App_03 address 172.30.1.20 modify ltm pool Pool_100 { members add { New_App_03:100 { priority-group 20 } } }
- kristine_vAltostratus
Hi, Paulius! Thank you for the info!
Since this is in Production setup, should I set the new pool member’s state as forced offline (disabled) for it to not receive new connections?
modify ltm pool POOL_100 { members add { New_App_03:100 { priority-group 20 } { session user-disabled state user-down } } }
modify ltm pool POOL_110 { members add { New_App_03:110 { priority-group 20 } { session user-disabled state user-down } } }
modify ltm pool POOL_120 { members add { New_App_03:120 { priority-group 20 } { session user-disabled state user-down } } }
modify ltm pool POOL_130 { members add { New_App_03:130 { priority-group 20 } { session user-disabled state user-down } } }
modify ltm pool POOL_140 { members add { New_App_03:140 { priority-group 20 } { session user-disabled state user-down } } }
…
If I want to test the new pool member as the only member to receive connections, should I disable on the node level only?
Example:
modify ltm node 172.30.1.16 session user-disabled
modify ltm node 172.30.1.18 session user-disabled
modify ltm pool POOL_100 members modify { New_App_03:100 { session user-enabled state user-up } }
modify ltm pool POOL_110 members modify { New_App_03:110 { session user-enabled state user-up } }
modify ltm pool POOL_120 members modify { New_App_03:120 { session user-enabled state user-up } }
…
kristine_v The answer to you adding the new pool member in a disabled state is completely up to you and dependent on testing and policies. Typically before a server is added into rotation it is tested to ensure that it is already in a working state. In my previous experience the above was the case and we simply added the server to rotation and then performed load balancing testing during a set window where a possible outage or degraded service could occur. If you feel that placing the pool member is what is best for your environmen then I would go that route.
In regards to testing the server by itself in the pool, what you have does seem like the most logical option assuming that the other two nodes can be disabled for everything they are configured under on the F5. Disabling a pool member at the node level will remove it from rotation for every piece of configuration so make sure that that is the desired result. Once you have completed your testing ensure that old nodes are enabled so they can start accepting traffic. When going this route you should have the following steps.
1. Disable old nodes
2. Enable new pool member
3. Test with single node
4. Enable old nodes
5. Test with all pool members active and ensure that the testers have managed to use all pool members in rotation for each poolOn a side note, I would ensure that your load balancing method is set to one that uses the node level since you have a node that is in use across multiple pools so that you ensure traffic is evenly distributed across all your nodes. Previously I have used least connections (node) without issues but again the least connections part is up to you and your policies and what works best for the environment.
Hi kristine_v ,
you can add it using GUI without any impact or service intrruption.
I do not know what is the PGA conditions " less than 1 , 2 ... " but I see that you’ll give it a lower priority score so I think you’re going to make a redundancy on pool member level.
Anyway , you can configure it with the same way that you configured "App_01:100 and App_02:100"
but I Curious with your setup , why do you want to attach same pool " which contains 3 members " to all of these Virtual servers ( VS_110 , VS_120 .... ) as I see that you will get the same result when browsing any of them ?
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