Forum Discussion
AltocumulusIs rebooting to a new software installed on a partition the same as running touch /service/mcpd/forceload and reboot?
Hi, everyone!
Would like to know if the procedure -rebooting to a new software installed on a partition, loads the configuration from the text configuration file instead of the binary file? In other words, does it have the same effect as running touch /service/mcpd/forceload and reboot ?
Thanks!
jaikumar_f5Noctilucent
Not sure if I got your question correctly. But I'll explain few points,
Every volume would have its own image file and its corresponding configuration files in it.
Whenever you switch your volumes and boot in it. The images and its text configuration files gets loaded in the memory too. Its like a load sys config action performed.
If you plan to install a new image on a separate volume and if your intention is to copy the running the configurations of previous volume to new one, there is an option to install a certain configuration from other boot location. Similarly the db value also could be changed if you plan to do via CLI.
Coming to touch /service/mcpd/forceload, this usually we perform when the bigip is having mcpd stuck or in a hung state. MCPD is the master daemon. Its like the box is dead as much.
Though you perform load sys config, if the mcpd is stuck. Its still not going to load the text configurations into your running memory.
Which is why we do a forceload. For which we have to touch the mcpd and its followed by a reboot.
So that this flushes everything and reloads the text configurations into the memory.
aries22Hi , thank you for the quick response and for the explanation!
The reason I'm asking is, we had an issue where priority group activation is not working as expected and F5 Support suggested to do a forceload.
Now, we'll also be having an upgrade of the devices so I was thinking if doing a forceload is still necessary after the upgrade or not.
- jaikumar_f5
May we know what went wrong with your PG setting. How many high PG went down and what you expected and it didn't happen !!!
Can you mask the pool members and share your pool details.
#tmsh list ltm pool <pool-name>
Also share your existing version,
#cat /VERSION
Also what is the version F5 support engineer recommended to upgrade to.
- aries22
Well, even though priority group is set and pool member 1 should be the only one receiving traffic, packet capture shows that connections are still load balanced to the two pool members.
Existing version is 12.1.3.7. We're upgrading to v14.1.0.6 but the recommendation to upgrade did not come from F5 support to fix the PG issue. We're gonna uograde to fix vulnerabilities and customer wanted to minimize downtime so they asked us if we're going to perform the mcpd forceload right after bootup to new version.
Below is the current configuration where we disabled TAPP2P:23101 to avoid having connections sent to it,
ltm pool /Common/T_23101_pool { load-balancing-mode least-connections-node members { /Common/TAPP1P:23101 { address X.X.X.A%2 priority-group 10 } /Common/TAPP2P:23101 { address X.X.X.B%2 priority-group 5 session user-disabled state user-down } } min-active-members 1 monitor /Common/TCP23101 service-down-action reset }
- jaikumar_f5
Well, as per the current setup, it should always send to PG10 member.
Can you try the below once and see it outcomes.
Your loadbalancing method is on the node, the Member vs Node do play a major role in load balancing decision and there have been previous bugs where a single member gets selected alone and serves for traffic (ignoring other pool members in the cluster).
When you put least-connections-member its totally w.r.t to the existing pool. least-connections-node is throughout the box. To avoid confusion, you can just revert if to default RR load balancing.
Also by any chance you have persistence in the VS.
- aries22
Hi, , we don't have persistence set on the VS. We also reverted to default round robin load balancing method but still experienced the same issue.