multiple health monitor on a single VIP

[vishnu vardhan1709161421]

Hi, 

I have an application that listens on ports 80,8081 and 8443 and bunch of other ports, is their a way that can configure and health monitor that can probe the all the specific ports with out creating different VIPs for different ports? 
EX: lets say an application is listening on 80 and 1523 and 8443 and 8081 ports if the service on port 1523 is down it should not take the whole VIP down. instead it just have to take the 1523 out of service, As if it is configured as individual VIP that listens on port 1523  

[Sam Jacobs]

A service is defined as an IP and port, so while you would need to create a separate VIP for each service, you can use the same IP as long as they are listening on different ports.  So, in the case above, you would need to create separate VIPs (with separate monitors), but they can all use the same IP address.

[vishnu vardhan1709161421]

I have a server that is listening on around 230 ports in that case I have to create 230 VIP's I know I can write a listening policy my main concern is about the health monitor so can you please suggest me a best way to approach in this kind of issues 

[Sam Jacobs]

Wow … that's a lot of ports, but I'm not aware of any other way.

I would suggest that you use the CLI rather than the GUI to create them.

You can generate them via any scripting language (e.g. PowerShell), or simply copy and paste in Notepad.

[Rhonda Rowland1709152125]

Here's the problem:  

- if you have separate services for each destination IP:Port combo. Then an individual monitor will down the individual service.  This is possibly what you want; use the server for the services that are UP and skip for the ports that are DOWN. 

- However, if you have one service with a listen policy for the necessary ports.  While this would allow you to use one entity for the necessary ports...If you were to bind separate monitors to the service (for each port), then any one monitor failing downs the service (for all ports).  The service IP:multi-ports won't be used for any port; not just the ones that are still up.  So any one backend port failure would down the service as a whole, in this case.

So while the service can represent all the different ports you want to reach in one entity; the monitoring will not go up/down granularly.

 

If you had svc1_80, svc1_88, svc1_XX, and then the equivlent svc2_aa, svc2_bb, svc2_xx  services for each port. It is a lot of work, but each service would be monitored individually. Therefore if port 80 failed on svc1, you would still be able to use it for 88 and other ports.

Now, for this to also work properly from a load balancing tier, you would need to have separarte lb_vsrv for each VIP:80, VIP:88, VIP:XX as well.  

If you had one vserver on all ports, pointing to svc1_80, svc1_88, svc1_XX, then you would be load balancing to 80 then 88, XX and not matching front end port to backend. So you would need seprate lb vservers for each port.

So this config would be simpler with Content Switching up front that sorts traffic to the LB vservers (based on service type:port).  But would require separate services with monitors per port.

 

If you want any one port failure to down the service, so traffic moves to a different service instead regardless of which service failed, then you can use a single service with listen policy for the ports (per backend server) AND a single lb vserver with listen policy for necessary ports.  Then attach all dependent monitors to the service.

 

The LB vserver VIP can be used across multiple vservers as long as each vserver is on a separate port using the same VIP. (Hard to tell if you meant VIP in the original query or SERVICE IP, so just clarifying.)

 

 

[Sam Jacobs]

What Rhonda said. :-)