Load balancing AND failover, with an added twist?

Follow
JD Weiner

We're working on a load-balancing/DR architecture, and I'm trying to figure out the best way to implement it.  Basically, we want to have "Origin-East" and "Origin-West", each with a health check.  So far so simple.  But here's where it gets more complicated.

  1. Is it possible to tell Fastly to send requests to the lowest-latency or geographically-nearest backend?  Or is this something better handled at the DNS or routing levels? If we have to just do straight 50/50 that's OK, though.
  2. Each backend should really be a failover set itself, where for example requests would go to Origin-East-A unless it was unhealthy, and only then would requests go to Origin-East-B.  If both East backends become unhealthy, then everything would start to go to the West backends.

Is this reasonable?  Any suggestions on how best to implement this, or better ways to do things?

0

Comments

5 comments

Sort by Date Votes
  • Ryan C

    Hi JD,

    Currently, we don't have comparative data on backends that would allow preferences for low-latency or geographic selection. That would be better handled at the DNS level.

    As to failover for backends, you can set up your own "chain" of failovers based on Health Checks. For example:

    set req.backend = A;
    if (!req.backend.healthy) {
       set req.backend = B;
       if (!req.backend.healthy) {
          set req.backend = C;
       }
    }

    A fails to B, and B to C. You could make the chain as long as needed. With the right conditions, you could set up different chains for East and West.

    If A & B are in the West with C & D in the East, when the West chain could be A > B > C > D and the reverse for East.

    Ryan

    0
    Comment actions Permalink
  • JD Weiner

    Thanks, Ryan, that helps us narrow down our choices.  Is backend health evaluated separately by each cluster?  I'm thinking of the case where, say, Fastly's San Jose POP can't reach our West origin, so it should fail over to the East origin, but if the Seattle POP can still reach the West origin, it should continue using it.

    0
    Comment actions Permalink
  • JD Weiner

    Thought of one other question: is there any way to see the health of a backend other than req.backend.healthy?  That only applies to the currently selected backend; is there any way to check the health of an arbitrary backend?

    0
    Comment actions Permalink
  • Ryan C

    Yes, the health of a backend is evaluated by each of the POPs. So you could have SEA and SJC have different evaluations of a backend's health. 

    Alas, req.backend.healthy is currently the only way to check the health of any backends which does limit you to the currently selected backend. There is no list of backends and their health that you check. 

     

    0
    Comment actions Permalink
  • JD Weiner

    I did think of one way to work around that last point: set req.backend to A, save the value of req.backend.healthy to another variable; set req.backend to B, save the value of req.backend.healthy to another variable; rinse and repeat.

     

    Kind of a hacky workaround, but I guess you could do it!

    0
    Comment actions Permalink

Please sign in to leave a comment.

New post