You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

What is HTTP Health Checking for?

  • HTTP Health Checking is a Layer 7 health check method, it makes a special HTTP request to the origin server, checking for a well defined healthy result, typically for HTTP response code.
  • Why is L7 health checking required?
    • maintenance requirement: nowadays, most sites have more than one origin server for load balancing and service redundancy. As servers are expected to have maintenance down-times, there needs to be a good way to pull down some server off the service in a way that is easy to manage/change.
    • service broken: there is chance that when the L4 port is open you can still not get any HTTP request handled.
    • back-end service broken: when your origin server using a LAMP like system and when your MySQL is down, you will probably get bad result.

What has been done in TS?

  • L4 health checking:
    • when failed in connection/reading/writing, it will trigger up the L4 fail function
    • the failed host will be put into the ring to retry, after the failure timeouts
  • L4 health status stored in HostDB
  • HostDB information sharing in the cluster, when enabled

What do we need to do implement for L7 checking?

  • in the beginning we'll start off by using HTTP services, excluding raw-link services like HTTPS.
  • We'll merge it into the server-session manager
  • L7 status will be stored in HostDB info struct
  • We must reuse server session as much as possible.
  • We'll create a a dedicated config-file, with a config mapped to the origin hostname
  • L7 health checking should be triggered by user a request on the the origin hostname
  • Like with L4 health-checks, it should should be possible to store a hashed L7 status in the cluster ENV, and share it in the cluster.
  • No labels