Unsolved
This post is more than 5 years old
18 Posts
0
1456
Theorical question: put everything on an Isilon cloudpool target
Hello,
I've got no experience with Cloudpools, but I've got a lot of questions about it.
I've read the Cloudpool whitepaper "ISILON CLOUDPOOLS AND ELASTIC CLOUD STORAGE" (https://www.emc.com/collateral/white-papers/h14775-isilon-cloud-pools-and-ecs-solution-guide.pdf) which explains quite well the different read/write phase and cache mechanisms (and associated knobs) involved.
Now, let's imagine something (crazy ?) like two Isilon clusters : one (cluster_S) with a cloudpool policy saying "move everything under /ifs/data/your_data_root to cloudpool and the other (cluster_T) that will be the cloudpool target.
Every writes happens on cluster_S, the smartpool job is triggered once a day for example and move everything on the cluster_T. The local cache ("local data cache" in the whitepaper) allows to use files as is they were on cluster_S.
Of course, you have to consider the time necessary to move data block from cluster_T to cluster_S and if cluster_T is able to ingest as much data as cluster_S is. But as a thought experiment, will it work well enough or is it something completely stupid ? I have absolutely no idea of the protocols (http ?) involved here and the associated overhead that could make this setup flawed right from the start.
Could we imagine a Gen6 F800 cluster_S in front of a bunch of A2xxx acting as a cloudpool target for example ?
I really like the "cache" architecture: it is more dynamic than a fast and a slow tiers inside the same Isilon cluster associated to placement policies that you need to calibrate and reevaluate continuously to prevent spillover.
Ideally, I would like to achieve that without relying on Cloudpool and dedicate some network user facing fast nodes to something like a global L3 cache to behave like an Avere system =)
Jean-Baptiste
AdamFox
254 Posts
1
July 25th, 2017 07:00
Would it work? Yeah, it probably would. Here are some concerns I have about it:
First and foremost, you have to be REALLY careful how you size cluster_S on a couple of fronts. It could be really easy to fill up cluster_S and once that happens, all writes to cluster_S would stop until that situation is resolved. I see 2 forces working against you to fill your cluster. The first is the ingest of data vs the time it takes to archive it out to cluster_T. Depending on your workflow, this could get out of whack, especially if an unexpected amount of write activity happened out of the blue. The 2nd is the caching itself. The cache isn't a set area of a certain amount of space. The "cached" data is stored with the file. So if you read a bunch of data and it pulls it from cluster_T, it will live on the disk of cluster_S until the cache expires. Well, if a bunch of data is read, again, unexpectantly, you could be using much more space than you anticipated and you could fill your cluster. Same with updates to archived files. Unlike traditional SmartPools where you have the option to spill-over to the another tier if the tier you are supposed to use fills up, there is no spill-over with CloudPools.
Second, always remember that when archiving to another Isilon, you probably want 3 clusters in this config. Your primary that would have stubs of archived files, a CP target, and as SyncIQ copy of your CP target. When archiving to an object store like ECS, the multi-site redundancy is easily built-in so you should have redundant copies of your data. Isilon is a file server first so replication is something you have to configure and it has an RPO since it's async. Plus, you still have to protect your stubs since the data once written to the Isilon is still in object format so it is not easily accessible without a stub on an Isilon. It's not like SyncIQ where the data is written out on the destination like the source and you can just mount up the destination. It's written in 1MB chunks with filenames that are hashes in directories that are also hashes so there is no obvious way to map those hashes back to path names. If you compress and/or encrypt the objects, recovery is near impossible without the stubs.
To keep this short, CloudPools was built to be a cold archive solution for datasets where access is the exception, not the rule. If you try to use it as a cloud gateway, you could get into trouble. I'm not saying it won't work, but you are, essentially, fighting the design, IMHO.
jbdenis
18 Posts
0
July 25th, 2017 08:00
"I'm not saying it won't work, but you are, essentially, fighting the design, IMHO."
I think this perfectly sums up the problem and why I won't explore this more. But the technical implications are still interesting.
I've got some remarks.
I think the sizing problem is exactly the same as with multiple tiers with associated smartpool policies. What if a given policy fills up a tier and you don't have spillover activated (anyway, who wants 100% usage of a pool ? I've been there once and I don't want to live that again) ?
With a classic fast / slow tier policy (not based on path), you're also fighting against the ingest of data on the fast tier vs the time is takes tom move it on the slow tier. Not in the same proportion as in my scenario, but the problem is still there.
The cache mechanisms implications are indeed not trivial. I underestimate them in my little thought experiment. I'm glad you pointed them out.
Do you know what happens when there is not space left for cache purpose ? Will stub files still work as expected in a degraded mode ? In a classic cloudpools usage (where access is the exception), since the cached data is taken into account for quotas, I guess this (no space left for cache) could happens on a regular basis.
I agree with your remarks about the need of 3 clusters. I already had that in mind.
Thank you for your answer AdamFox.
sjones51
252 Posts
0
July 26th, 2017 11:00
HI jbdenis,
I don't have a whole lot to add to the discussion that Adam didn't already do a good job covering, but thought this might be useful.
In the OneFS 8.1 CloudPools Administration Guide there is a section on limitations and expected behaviors that seems relevant to this thread.
https://support.emc.com/docu84274
As of the time of this post, page 52 has the information.