TL&DR answer: it makes way more sense than long-distance vMotion. However…
2015-09-17: VSAN is similar to synchronous, not asynchronous replication. Added the explanation from Duncan Epping.
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 storage replication – every write is immediately queued for mirroring, .
Additional explanation by Duncan Epping: VSAN in a stretched configuration is similar to "sync replication". It uses an object based model where IOs are split to each of the components of an object tree. Only when each of the components have received the IO will it be acknowledged to the OS/Application. Note that the IO is split before it is written to a device, so this is the purest form of sync IO if you ask me :)
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.
Many thanks to Duncan Epping for confirming my understanding of VSAN principles and caveats in an extremely short timeframe.