How do I automate a timed, maintenance failover and failback within 2-origin load balancer pool?

I have a small web load so one server with Cloudflare’s CDN has been more than enough for our speed and security needs (“primary origin”). I have another server (or origin) that is a reasonable replica of our production server, but it’s a little slower, and it doesn’t have all the features turned on - it’s used as my failover server (“second origin”) with a ratio of 100% to the primary origin and 0% to the second origin during normal operations.

While backing up my primary origin to an offsite storage place in the cloud, it slows to a crawl. This is expected since the amount of data I store is large. A backup takes about 12 hours, so I start it during a time when we’re not expected to get much web traffic. In doing so, I manually fail over to the second origin when I begin the backup, and manually failback when the backup is done. The backup is only done on friday nights.

How do I automate this type of timed failover? I’m hoping there’s a way to do so without scratching the API, but I can’t seem to figure out how to do so. I don’t want to have so many pieces of logic that need to run in order to make it successful, since the more dependencies there are in automating a task the more likely something will break…

I thought about forcing a shutdown event by switching out the keywords that the monitor is looking for on the page that it’s monitoring (and I could do this at the server level). But if I did this, would the session stickiness still work? E.G., if it so happened that someone was browsing our website and was in a session (we have a cart), this would terminate it completely (correct?) Is there a softer way of approaching it?

Thank you kindly!


Cloudflare load balancing doesn’t support time based steering so you can do that manually (your current solution) or automate backup process to signal health check monitor to use the other origin (needs technical knowledge and expertise and depends on your technologies).

It depends how you are storing session data. usually session data are stored in server memory unless you use another solution for session sharing (usually a database).

Thanks @Xaq ! To clarify, I was asking about the TCP session (and not the cookie’d session). For example, lets say I do this:

At 7:00 pm, I force the health check to failover from the primary origin to the secondary. For those people who were mid-session (e.g. mid-browsing) during exactly 7:00 as CF is failing over to the secondary site, what happens? Does the failover event steer them to the new server no matter what (thereby breaking the TCP session during a pageload, etc.)? Or, will it allow that individual user(s) to continue the dialog with the primary origin?

I’m guessing it doesn’t, but thought I’d clarify.

Lastly, is there a way through CF’s API I can do the steering in such a manner? I didn’t want to go that route, but it’d give me more precision (e.g. checking first to see if anyone is logged in and waiting for them to complete things before starting a failover).

Thanks in advance!

HTTP is a connectionless protocol by nature (apart from later changes for performance like keep-alive, server push or websockets) so you won’t notice a TCP session at web level (when the underlying layer is the web-server). If an open socket breaks due to a failover client simply will sends another request to server but even this dooesn’t happen when using CF for preloading resources. When using CF client is connected to CF edge server and with default settings static resources are cached so switching the origins would not affect the client (CF servers from cache). This works for server push but not websocket.
The question is if there are some states related to this client, where you are storing them (like if user is logged in). Usually session info lives in server memory so the backup server has no access to it.

1 Like

Ten-four! That explanation makes a lot of sense. Thank you, @Xaq !

1 Like

This topic was automatically closed after 30 days. New replies are no longer allowed.