- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Andreas,
Thanks for the links, indeed it was Frank and Duncan's blogs which lead me to ask my question, as I may need to rethink/delay our implementation until we've moved to vSphere7, which should only be a few months away.
To answer your question, our storage is on IBM v7000 Hyperswapped storage, which is a synchronously replicated stretched cluster storage solution. The host connections are active/active-passive, so they can see all paths as active, but if the storage system witnesses too many writes to the non-preferred copy, then it will flip the replication direction over to the other site. This has a time delay penalty associated, so we need to avoid it by pinning VM's to hosts based at the site with the primary copies. Its a mega pain, and limits the design, but it does work well.
I could solve the problem by configuring a cluster with only site-local compute - but having a stretched cluster and cross-site storage allows easy site fault tolerance without SRM complexity (or cost). It's just this confusion over respools that's troubling me.
Hopefully the attached picture will explain it better.
As you can see, the allocation percentage of the main respool - "Live-DC1" - will exceed the physical cores and ram for that site because of the imbalance. In fact, the allocation would need to be exactly 50:50 for this not to be the case for any stretched cluster where vm's are pinned to a site.
So a general understanding of how resource pools cater for stretched clusters would be really useful.