VMware Cloud Community
microlytix
Enthusiast
Enthusiast
Jump to solution

Recommemded vSAN storage policy for vCLS on stretched cluster

On a stretched vSAN 7.0.3 cluster (4+4) we're getting Skyline warnings concerning vCLS VMs.

"VM storage policy is not-recommended"

The vCLS VMs are using the "vSAN default storage policy", which is indeed not recommended.

I wonder what would be a good (and sensible) policy for vCLS?

Our "production" policy (site mirroring, FTT1-RAID1) would be a bit too much, because all 3 vCLS offer intrinsic redundancy.

We've got another policy for testing VMs (site mirroring, no data redundancy), which seems more suitable to me.

Don't get me wrong, a RAW datastore footprint of less than 3 GB isn't worth mentioning. 😉

This is more a principle question on how to treat vCLS on stretched clusters.

Do we need any DRS rules to spread them? (vCenter is on a distinct management cluster)

Any recommendations?

 

TIA

Michael

blog: https://www.elasticsky.de/en
Labels (3)
Reply
0 Kudos
1 Solution

Accepted Solutions
depping
Leadership
Leadership
Jump to solution

I would just recommend to replicate them, and don't bother with VM-Host rules. First, I don't know we even support the use of those rules. Second, vCLS VMs can be reprovisioned by EAM, which means the rules wouldn't work after the reprovisioning as it would be a new VM. Just keep it simple.

View solution in original post

Reply
0 Kudos
3 Replies
depping
Leadership
Leadership
Jump to solution

I would just recommend to replicate them, and don't bother with VM-Host rules. First, I don't know we even support the use of those rules. Second, vCLS VMs can be reprovisioned by EAM, which means the rules wouldn't work after the reprovisioning as it would be a new VM. Just keep it simple.

Reply
0 Kudos
microlytix
Enthusiast
Enthusiast
Jump to solution

Thanks Duncan.

I see, thats true. A new VM Object would get a new ID and render an existing DRS rule useless.

So a stretched policy with no local redundancy should do the job.

In the meantime I found the reason why these apps (and other VMs) got the wrong policy.

The vSAN datastore's default policy wasn't set to a stretched policy.

 

Thanks

Michael

blog: https://www.elasticsky.de/en
Reply
0 Kudos
depping
Leadership
Leadership
Jump to solution

yeah we tend to see that a lot, this is why in vSAN 8 we introduced "auto policy management", which provides suggestions to improve the default policy to align with the configured services.

Reply
0 Kudos