Ask the Expert: Introducing ScaleIO 2.0

Hi Wangzz,

1. 1. Yes to all of the above, the drives (number of drives, drive type), the network (number of ports per node and other network limits, e.g. switches etc), number of SDSs (number of nodes), Raid controller types, caching solutions etc
2. 2. The answer depends on the drive type. With HDD drives, usually the limit will be the drive in which case the more drives you have the more performance you will see. It does not usually matter how they are distributed across the SDSs, but it is best practice to keep things simple and equal, so have the same number of drives per node.
   with SSD/Flash drives you can get into a situation where the limit will be the SDS and not the Flash, in which case you want to make sure you distribute the drives evenly between the SDSs.
3. 3. You can play tricks and present to ScaleIO part of drives as one drive, but I would try to avoid these games. You will not gain any performance benefit, but instead you make life complex when you need to replace a “drive”. Just keep things simple and everything will work better.

Best,

Dan

yes i will be happy to discuss that, can you provide an email address or something like that?

it's really important, i really want to put the focus on scaleIo for our customer with dedicated events, demonstartion ... but i need some info about replication

regards

just one thing you talk about caching and people want tiering, i agree that depending of the caching algorithm it can be nearly the same thing but you still have some difference.

For example i think that you use only lru for rfcache and not something as complex as ARC

Hi,

CacheCade is based on "Hot spots", meaning the data will start on HDD and only move to the SSD if a chuck is hot. this is the same principle as VMAX/VNX FAST. RF cache is indeed based on LRU.

the bottom line is that you get the same functionality no matter what you call it.

Dan

Hum you have a big difference between caching and auto-tiering, the ssd use as tier 1 is usable space in case of auto-tiering, ssd use for caching is not usable space.

The other difference is in case of caching it will accelerate read or write but not both at the same time, i mean with auto-tiering you will read data and when it becomes hot the data will moove to the ssd so if you make a modification on the data you will make the modification on ssd. With caching the data is not moove but it's a copy of the data, so if i read data it will be copied to the ssd tier but if i have to make a modification at the end i will have to write on disk.

If we had the auto-tiering algorithm (at least 3 read) and how the data are moved to lower tier ... i would say that auto-tiering is more like an mru cache than a lru one.

So for me we can't say that caching and auto-tiering are the same thing. And that would be grate to have a better caching mechanism like arc than just an lru one

Hi,

CacheCade does exactly what you are asking for. once you issue some minimal number of IOs (Reads or Writes) to a specific chunk, that section will be promoted to SSD and additional IOs to the same chunk will be managed on the SSD only.

for example you can try an extreme test, run a 100% write test on a small address space that fits in the SSD and continue to re-write on it for a while. you will see that initially all the IOs will go to HDD, but slowly the data will move to the SSD and at some point all the IOs will be serviced from the SSD and the HDD will be completely idle.

the same will of course apply to Reads and a mixed read/write workload. this is the feature you are asking for.

Dan

thanks to scaleio for all those precision.

Like i said to our partner manager the day scaleIO have integrate replication mechanism we will push it everywhere in switzerland

Questions & Information raised here by Subject Matter Experts very helping to EMC community. Thanks everyone !

Sowmya,

I feel it should on VMware's HCL page

http://www.vmware.com/go/hcl

I should be able to pick Storage/SAN then pick EMC.

It should be listed like Clarion, VMAX, VNX, VNXE, VPLEX, XtremeIO.