• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

vsphere 5.5 flash read cache?

D

danswartz

2[H]4U
Joined
Feb 25, 2011
Messages
3,715
So I've been reading up on this, and it looks kinda cool. The two things I don't like about it (possibly I just don't 100% understand it):

1. You have to statically assign X flash space to each VM you want to cache reads.

2. Why on Earth the restriction that you can't vmotion a VM with flash cache assigned to a host without flash cache? It's supposed to be just a performance enhancement, no? So why disallow this? I can imagine a use case where someone has two servers in HA and one is a backup only (possibly slower with less RAM?) In that scenario, you'd be better served putting all N SSDs in the production server, rather than putting 1/2 of them in a backup host, no?
 
Correct, you can only vMotion VM's to hosts that also have capacity in a vSphere VFFS. Most production implementations use matching hosts. It's not a good practice to implement mismatched clusters. Example

You have 2 hosts, 10 VM's, 8 SSD's.

You're thinking
1 Host, 10 VM's, 8 SSD's.
1 Host Standby

Really it should be this
1 Host, 5 VM's, 4 SSD's
1 Host, 5 VM's, 4 SSD's

If a failure occurs 5 VM's keep running, 5 of them restart on the remaining host.
 
I'm not a fan of vFRC. First, you have to have your VMs on HW v10. Then you have to statically assign the amount of cache. And as you said you can't vMotion or have HA restart a VM on a host if it can't satisfy the caching requirement. It's like a memory or CPU reservation.

Sure..with two hosts it's easy to make this work. Now do a 16 node cluster with a bunch of VMs you want to accelerate. You have to be careful and not assign too much cache or you could end up in a bad spot. Way too much manual work. They need to move to a "shares" model that works dynamically so you can actually use 100% of your cache in each host all the time.

So for now go look at PernixData. Much better implementation and does write caching.
 
NetJunkie said:
I'm not a fan of vFRC. First, you have to have your VMs on HW v10. Then you have to statically assign the amount of cache. And as you said you can't vMotion or have HA restart a VM on a host if it can't satisfy the caching requirement. It's like a memory or CPU reservation.

Sure..with two hosts it's easy to make this work. Now do a 16 node cluster with a bunch of VMs you want to accelerate. You have to be careful and not assign too much cache or you could end up in a bad spot. Way too much manual work. They need to move to a "shares" model that works dynamically so you can actually use 100% of your cache in each host all the time.

So for now go look at PernixData. Much better implementation and does write caching.
Click to expand...

+1, it's a pain in the ass to use currently. Shares would be much better.
Another +1 on PernixData
 
Okay, so I'm not nuts :) That said, I understand what ov3rc10ck3d is saying, but someone *might* want a lower-end host without as much ram, ssd, etc...
 
danswartz said:
Okay, so I'm not nuts :) That said, I understand what ov3rc10ck3d is saying, but someone *might* want a lower-end host without as much ram, ssd, etc...
Click to expand...

Have to remember. vFRC is only in the Enterprise Plus license level where you get HA and DRS. No real reason to buy a big and a small host and use the smaller as a backup. Buy two the same and let DRS balance load.
 
Well..here's my input. You can beef up a couple of hosts in a cluster that require Flash Cache and use DRS Affinity or Anti-affinity to make sure those vm's that require vFRC stay in hosts only allocated for caching functions but yeah...it's certainly additional mgmt overhead.

Secondly, i've heard this is just the first step in a larger overall scheme. I've heard and it's been said by VMware engineers that this will get better over time, write cache, mirrored to multiple hosts..etc..much like Pernix Data but functionality at the kernel level, no add on software..etc.

What I do like, is the fact that this has Virtual Machine granularity and i'm sure based on that and the forward thinking from VMware is that it will be policy based much like storage and other pieces are and will become.

I think VMware is on the right track here, just not ready for prime time.
 
Oh yeah..it'll get better for sure. Just not great right now. And I know a bit about what's on PernixData's roadmap and it's good.
 
You must log in or register to reply here.
Back
Top