No. Fly Volumes are attached NVME storage; they're anchored to the physical host they're created on.
Under the hood, we can migrate a volume from one physical to another (the way we do this is pretty interesting and we'd write it up, except that to date the process has played an outsized role in the work sample testing we use for all of our technical roles). I don't think we've surfaced that, much, yet, but we will this year.
We back Fly Volumes up to off-network block storage at regular intervals (more announcements coming shortly here too).
But a really basic thing to understand about Fly Volumes is that they're not SAN storage, and they're not intrinsically reliable the way, say, S3 is. They appear in Fly Machines as simple ext4 filesystems, and if you need reliability/durability/replication, you need to provide it at the application layer. That's how Fly Postgres works: clusters of read replicas, all of which can take over and assume write leader role if they need to. This makes sense because with Fly Postgres the only purpose to which the underlying volume is put is running a Postgres database, which already provides durability/replication.
This is, for instance, why we print a big red warning on the console if you ask us to create a single-node Postgres cluster.
I think we're going to roll out stuff in the next couple quarters that will offer new options on the reliability/perf spectrum. But I don't think they'll involve us running SAN drives --- servers that just expose block devices over iSCSI or whatever.
Under the hood, we can migrate a volume from one physical to another (the way we do this is pretty interesting and we'd write it up, except that to date the process has played an outsized role in the work sample testing we use for all of our technical roles). I don't think we've surfaced that, much, yet, but we will this year.
We back Fly Volumes up to off-network block storage at regular intervals (more announcements coming shortly here too).
But a really basic thing to understand about Fly Volumes is that they're not SAN storage, and they're not intrinsically reliable the way, say, S3 is. They appear in Fly Machines as simple ext4 filesystems, and if you need reliability/durability/replication, you need to provide it at the application layer. That's how Fly Postgres works: clusters of read replicas, all of which can take over and assume write leader role if they need to. This makes sense because with Fly Postgres the only purpose to which the underlying volume is put is running a Postgres database, which already provides durability/replication.
This is, for instance, why we print a big red warning on the console if you ask us to create a single-node Postgres cluster.
I think we're going to roll out stuff in the next couple quarters that will offer new options on the reliability/perf spectrum. But I don't think they'll involve us running SAN drives --- servers that just expose block devices over iSCSI or whatever.