Forum Discussion
pool member monitor versus pool monitor
(in configuring a pool using CLI/tmsh) which monitor is used to determine state of a pool if member-specified monitor is different to pool-specified monitor? Are both used or member's monitor is used?
Stretching this, what if none of the member-specified monitors are the same, what should pool-specified monitor be?
R's, Alex
8 Replies
- Joshua_Johnson1
Nimbostratus
Not sure if this behavior has changed now. When I apply node-specific monitor and NOT pool monitor, my pool remains blue. Shouldn't pool be green if each member in node-view shows each member green?
No. Node specific monitors can only mark a pool member down. The posts above are regarding pool member monitors, which are a different object. Using your code, if you had this:
ltm pool prd-pl-vsp_mdm { members { prd-pl-vsp1:any { address 172.26.225.100 priority-group 1 session monitor-enabled monitor Server-Monitor-8443 state up } prd-pl-vsp2:any { address 172.26.225.101 session monitor-enabled monitor Server-Monitor-8443 state up } } min-active-members 1 monitor none }This would work correctly and should bring up the pool.
- rais_149266
Nimbostratus
Not sure if this behavior has changed now. When I apply node-specific monitor and NOT pool monitor, my pool remains blue. Shouldn't pool be green if each member in node-view shows each member green?
Does it mean there is one monitoring going on for each node from node-monitor perspective and another monitoring going on from pool's perspective?
Here are my definitions:
ltm pool prd-pl-vsp_mdm { members { prd-pl-vsp1:any { address 172.26.225.100 priority-group 1 session monitor-enabled state up } prd-pl-vsp2:any { address 172.26.225.101 session monitor-enabled state up } } min-active-members 1 monitor Server-Monitor-8443 } ltm node prd-pl-vsp1 { address 172.26.225.100 monitor Server-Monitor-8443 session monitor-enabled state up } ltm node prd-pl-vsp2 { address 172.26.225.101 monitor Server-Monitor-8443 session monitor-enabled state up }Thanks.
- epaalx
Cirrus
> Does it mean there is one monitoring going on for each node from node-monitor perspective and another monitoring going on from pool's perspective?
Yes.
Although counter-intuitive, even if a node's monitor detects node as unavailable, LTM will continue to monitor the member using monitor defined in the pool - see K7118.
- hoolio
Cirrostratus
Yes, that looks right.
Aaron - epaalx
Cirrus
So, basically pool attribute "monitor all" specifies monitors used when member attribute "monitor" is set to value "default", correct?
And, these pools (below) are equivalent?pool pool1 { monitor none members { 1.1.1.1:80 {monitor1} 1.1.1.2:80 {monitor2} } } pool pool2 { monitor monitor3 members { 1.1.1.1:80 {monitor1} 1.1.1.2:80 {monitor2} } } pool pool3 { monitor monitor2 members { 1.1.1.1:80 {monitor1} 1.1.1.2:80 {} } } - hoolio
Cirrostratus
You can have a monitor assigned to the pool. You can also have monitors assigned directly to a member. If a pool member has a member-specific monitor it will not use any pool monitors.
In the example below, 1.1.1.1:80 will be monitored using only the http_1.1_monitor. All other pool members without a member specific monitor will inherit the monitor(s) associated with the pool. So 1.1.1.2:80 will be monitored by the default http monitor. You can have more than one monitor associated with both the pool and/or the specific pool members.pool my_pool { members { 1.1.1.1:80 { monitor http_1.1_monitor session monitor-enabled } 1.1.1.2:80 { session monitor-enabled } } monitor http }
For both pool monitors and pool member-specific monitors, you can separately specify a minimum number of monitors which need to succeed:pool my_pool { monitor all min 2 of http tcp http_1.1_monitor members { 1.1.1.1:80 { monitor min 1 of http_1.1_monitor gateway_icmp } 1.1.1.2:80 {} 1.1.1.3:80 {} } }
In this second example, 1.1.1.1 will be checked using http_1.1_monitor and gateway_icmp. As the Availability Requirement (min X of ...) is set to 1 1.1.1:80 will be marked up if either the http_1.1_monitor or gateway_icmp monitors succeed.
1.1.1.2:80 and 1.1.1.3:80 will both be checked by the pool monitors http, tcp and http_1.1_monitor. As the Availability Requirement is set for 2 the pool members will be marked up if two or more of the monitors succeed.
So why would you want to do this? Your web servers might require the host header being set with a server-specific value. If that were the case, you could create one custom HTTP monitor for each and assign each to the corresponding pool member instead of on the pool. Other than that, I haven't seen many customers use member-specific monitors.
Aaron - epaalx
Cirrus
it is monitor at pool member level.
Ok, but this doesn't quite make sense - pool-specified monitor determines pool's status, where as member-specific monitor determines member's status - (logically) the latter doesn't imply the former unless there's only one member in a pool.
Answer to my second question would clear it up, if you could volunteer. - nitass
Employee
which monitor is used to determine state of a pool if member-specified monitor is different to pool-specified monitor? it is monitor at pool member level.
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
