Is there a URL that can be used as a health monitor/heartbeat from an F5 to determine up status of an ICG process?
You mean for the UMS? Well, atm. you could check the IMI for existence which might give a few infos on how the service is running:
127.0.0.1:8443/umsapi/v3/serverstatus
It isn’t exactly what you are looking for but I would check that.
Here may be an option with the F5:
1. IGEL does not currently support F5 LB of ICGs
2. Create one-to-one mapping of F5 to ICG with application layer persistence
3. Passive monitoring occurs as part of a client request. This kind of monitoring checks the health of a pool member based on a specified number of connection attempts or data request attempts that occur within a specified time period.
NOTE: This is not a supported IGEL configuration. Test in your lab / sandbox… Don’t test this in production.
Our intent was to implement GLB with 2 sites. Each site having pass thru VIP configuration to a single ICG offering geographic resiliency. Typically a webservice can offer a basic URL that replies with a message like OK or uptime etc. that the VIP can look for before allowing an inbound connection to pass thru. A simple ping to the host doesn’t prove the Web app is really running.
TL; DR: True load-balancing not supported today for ICGs, DNS Round-Robin only via a single DNS entry to multiple ICG DNS entries, we’re working on this as we speak to support more load balancing mechanisms.
So quickly as I understand it:
• Beyond support from IGEL (well documented in this thread), ICGs can only use DNS round-robin for geographic resiliency.
• E.g. ICG-01 in Hong Kong, but ICG-02 in London, with auth. DNS entries for each the UMS pushes to the clients via a single DNS round robin entry (let’s call it just ‘ICG’)
• And this is where the load balancing, as it stands today, is done, the client side via the DNS round robin address (ICG).
• Each client has a complete entry of ALL ICGs with the same root certificate (ICG-01 and ICG -02 in this case.
• So, again, to our example, ICG will be looked up on the client side and point to ICG-01 in Hong Kong or ICG-02 in London load balanced via DNS round robin
Now, I can say we’re looking to support more load balancers and load balancing services to accommodate a public endpoint posture without fully exposing the ICG.
In this model, yes, a serviceable path would be needed to determine the ‘health’ of the ICG (like (YOUR LB URL):PORT//usg/server-status) for a 200 response that is 100% deterministic of the application health.
More than happy to discuss further, but know it’s being worked on.
Also, even with a load balancer in the mix, to Ron’s point, until there are some fundamental code changes, it will have to be pass-through, one-to-one LB-to-an-ICG.
The main issue is that will the current setup, a client setup via ICG is unaware of any kind of external load-balancing so the connectivity to connect, manage, and update a client would be hit and miss as the client doesn’t know the path back to the management plane (i.e. the Websocket session connection).
It would think “hey, I established a websocket on ICG” but the UMS would be like “client, I am talking to you over ICG-01, but you aren’t potentially there”, and the client would be all “BUT I AM ON ICG” 🙂 – see what I mean?
This is further deluded the more ICGs you put in the mix (in the example above, 50/50 chance, with say 20 ICGs, you have a 1/20 chance of a websocket path
Sorry, I did this also for myself to come back to as it’s been swimming around in my head 🙂
Continue reading and comment on the thread ‘Is there a URL that can be used as a health monitor/heartbeat from an F5 to determine up status of an ICG process?’. Not a member? Join Here!
Learn more, search the IGEL Knowledge Base
Ask a question or comment on the above message thread?
Join or log in to the IGEL Community to ask us anything and meet other IGEL customers, partners, and EUC enthusiasts.Submit a question, or Join Today!