TL&DR answer: it makes way more sense than long-distance vMotion. However…
Does It Need Stretched VLANs?
VSAN is storage replication technology that runs on top of TCP, so it can run over any L3 network. It does need IP multicast between the VSAN nodes, but not between VSAN nodes and the witness node(s).
Stretched vSphere HA cluster running VSAN thus doesn’t require stretched VLANs (unless, of course, you plan to move VMs willy-nilly across the WAN links – most often a bad idea).
Can You Use It for Disaster Recovery?
VSAN data replication is almost identical (at least conceptually) to
asynchronous synchronous storage replication – every write is immediately queued for mirroring, and acknowledged to the writer only when the other VSAN nodes acknowledge it.
Do keep in mind that VSAN runs on top of vSphere HA cluster, and if you don’t want to move VMs between data centers, you MUST use affinity rules to keep them contained (for more details, read Duncan’s blog post).
As you’d be relying on vSphere HA mechanisms for disaster recovery, you won’t get any of the goodies SRM brings to the table: each VM will be restarted automatically in whatever order, or not (if the remaining part of the cluster doesn’t have enough resources). This might be good enough for small independent workloads, but maybe not for complex application stacks.
Finally, you’ll have to solve network connectivity challenges, unless you plan to deploy stretched VLANs (and even Gartner agrees they’re not a good idea) and stretched firewall clusters (even worse idea).
All things considered, it might be best to write an orchestration solution (it would be even better if VMware would do that) that would:
- Create lost subnets in the new data center;
- Configure any other network services that may be required (unless you’re using virtual appliances);
- Restart VMs in proper startup order.