Machines high availability

,
1

So the machines docs mention that:

Machines VMs are tied to hardware, even if they don’t have a Volume. If the hardware goes down, the instance goes down.

If I want to run a v2 app with HA what setup should I use?

If I create two machines in the same region I really can’t know if these are running in the same hardware or not.

Should I create two machines in different regions? Will the routing layer try machine A first and if it’s down try machine B?

Also, if one of the machines is too busy, is there a way to send a response from machine A so Fly will instead send the request to machine B?

2

It’s not explicitly documented but the platform defaults to spreading machines across hosts within a region and at some point we’ll expose more control over desired placement.

I believe the best way to handle this is setting the proper concurrency on the machine’s service.

2 Likes
3

Say I put concurrency to 1 and have 2 machines. What happens if a third concurrent request comes in?

1 Like
4

It “queues” and retries for a while and then stops retrying and closes the conn / returns an http error code.

1 Like
5

Thanks.

Fly Proxy will not retry for raw TCP / UDP conns, will it?

6

If this is an http service I believe there is a way. Machine A can include the Fly-Reject header in the response (it can have any value) and fly will try a different machine instead.

2 Likes
7

No, TCP connections are one and done. We’ve experimented with retry like features, but not figured that out yet.

UDP is fire and forget, those packets don’t even hit the userland proxy right now.

2 Likes
8

Can’t find any reference in the docs for that Fly-Reject header :thinking:

Anyway, I think a better approach would be to have another app doing the fly control and triggering machines on and off.