Forum Discussion
Wes_98712
Nimbostratus
NimbostratusIIS Host Headers and ECV health monitoring
Interesting situation has come up, we have 2 IIS servers hosting sharepoint team services sites (8 sites in a front-end web farm on both servers hitting the same content database). We have been requested to implement ECV's to check the health of each system. The problem is as follows:
1. Using host headers simple TCP socket checks won't tell us if a site is down.
2. We are not using DNS on the F5 so checking each web site will be difficult, unless we use local /etc/hosts file entries...which we can do.
3. Even with local host entries, applying multiple ECV's on a single server won't work as the ECV will fail but we don't want the node removed from the central LB pool as other sites are working.
Can we use iRules to check the health of the site, based on the server response and pull the node out of service? There are also some authentication issues to consider, as we are using NTLM on Sharepoint to determine whether or not a user has access, so I am not sure if we can pass a username and password through iRules to hit the service.
As you can see this is going to be a very intricate process, any ideas on how to get this to work?
-Wes
- Hi Wes,
I don't think a rule will be necessary. In v9, monitors have some extra granularity that might help you solve this problem.
In v4, a monitor is applied to a node (IP:port combination) and affects all instances of that IP:port combo in any pool.
In v9, monitors are applied to pool members, so you can run different monitors against different instances of the same IP:port combo.
Name resolution doesn't come into play with monitors, since BIG-IP sends the request to the destination IP directly, and virtual hosting actually depends on the HTTP Host: header value, so instead of host file entries, you can just create a different HTTP monitor for each pool, with the appropriate host header value in the HTTP request string, and apply the monitor to the entire pool.
HTH
/deb 
pallocca_73085Hello,
in the above example (with 8 sites running on the clusterd iis servers) i believe I would need:
8x pools
8x custom http monitors (all with different "get/")
Is there a way for me to replace all those opbjects and put the ECV logic for each site into a single iRule? that way I could have a single pool and reference the irule.- I don't think you'll need 8 pools. You can certainly have all of the pool members in one pool, and set up individual monitors for each pool member, as Deb described above. You will likely need 8 custom monitors though, if you really want to monitor each of the 8 sites individually for different content returning from a get. That's to be expected though, I would think.
Colin - pallocca_73085lets say sites A , B, & C are running on server 1 & 2.
In all cases server 1 is primary.
If I want to fail site A to server 2 and keep sites B & C on server 1 I would need a pool/monitor pair for each site. 
hoolioCirrostratus
As Deb was saying, I think you'll need one monitor per web application/virtual host that shares an IP address and port with another web app. If you have multiple vhosts configured on the same IP:port and you want to be able to disable one vhost without affecting another vhost on the same IP:port, you would need to specify the vhost name in the monitor send string.
In other words, if you need to use a Host header to tell IIS which vhost you're making the request to, you would need a new monitor with the host header value specified in the 'send string'.
As far as I'm aware, there isn't a way to implement NTLM authentication using a single HTTP request, so either you'd need to allow another auth type, configure a page which doesn't require auth or use an external monitor that can handle NTLM auth (curl supports NTLM).
Aaron- I would need a pool/monitor pair for each site
This is correct. Separate pools containing the same pool members are critical to the vhost solution. Pool members with same IP:port in different pools will be marked up & down independently by their host-specific monitors. Contrast that to instead applying all host-specific monitors to the same pool member with an "All UP" requirement: In that case, failure of a single host-specific monitor would make the pool member unavialable for load balancing for any vhost.
