Wes Milliron @WesMilliron - Lessons learned planning and implementing 2 Node vSAN

*About vBrownBag*

Socials:

*About vBrownBag Podcasts*

The vBrownBag crew host podcasts where community members present on topics that will help others in the community. Some podcast series are aimed at helping people achieve certifications.
Other podcasts help community members learn an entirely new subject area. We also cover areas like storage or automation. The podcast has been running weekly since 2010.

*vBrownBag TechTalks*

The vBrownBag crew love IT conferences, the only place where we actually see each other, the awesome people who are our presenters and the community members who follow the podcast. The conferences are also a great place to generate some more community learning content.

More about vBrownBag:

[paultwomey]

Great presentation, glad to see you understand this product (this is unfortunately rare on customer side).
Couple of points though:
Objects are only accessible if you have >50% of components available, potentially there are misconfigured/broken scenarios that can result in exactly 50% of components available, these will not be accessible.
My 2 cents with regard to 1 Witness for multiple clusters is that it is too much of an all eggs in one basket approach - let's say we have 10 1+1+1 clusters all using the same Witness and the Witness fails in some manner, all your data in all of these clusters is essentially FTT=0 until you resolve this issue.
Regarding logging to vsanDatastore, this is not advised as it is unsupported because it can cause issues - not because you would lose logging if you had issues.
As you stated it is not going to use both uplinks when Active/Active, as such it is better just to set it Active/Standby.
Good validation/troubleshooting practice to always specify -s <relevant packet size> and -d when using vmkping
.
Thanks for pointing out the Health UI, all vSAN admins should be aware of this and check on a regular basis - it should be the first port of call when troubleshooting issues as it can save a lot of time.
CLOM default repair timer is not applicable to a 1+1+1 or 2+1 cluster as there is no available location to repair the data if you have lost quorum.
Thanks for giving 1+1+1/2+1 clusters an honest shake - it isn't applicable to all workloads but is ideal for a lot of our customers (retail especially) with hundreds/thousands of branches