• 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.

Two questions regarding VNX2

t_ski

t_ski

Supreme [H]ardness
Joined
Jun 13, 2006
Messages
7,510
I have a VNX5400 that originally was set up with a single 2-tier pool made of flash and SAS. We just added a bunch of flash, SAS and NL-SAS to the array, and now I have two questions.

1. If we add capacity (NL-SAS) drives to the existing pool, will it rebalance the LUNs across the tiers, or do I need to completely destroy the pool and start over? I'm getting conflicting info between my support tech and here: https://www.emc.com/collateral/software/white-papers/h10938-vnx-best-practices-wp.pdf

2. We have Platte River code (here) installed on this array, which gives the ability to do block level dedupe. Are any of you using this, and what is the good, bad and ugly about it?
 
Thanks. The tech was stating we would have to do some kind of migration in order to rebalance the array. I'll give him the benefit of the doubt and suggest he might have had old data. The Best Practices guide I linked stated that we would need to turn on FAST VP first, but I don't see a setting for it anywhere on the pool.
 
On FLARE 31 and older a Storage Pool would not rebalance when drives were added. FLARE 32 and newer does.
 
Thanks. We've been on 32 for all the arrays for a while (mostly VNX5300's and one 5500).

Just out of curiosity, how closely do you follow the guidelines for tiering in the guide link above? It recommends 10% flash, 20% SAS and 70% NL-SAS to start with, depending on usage, load, I/O, etc. It looks like we have about 2% flash on this array, and I'm wondering if the EMC partner we use just pulled numbers out of their hat or if they undersold us because they figured my boss wouldn't buy it if they figured in 10% flash.

If anyone has any thoughts on the deduplication question above, I'm interested :)
 
yes you can turn on dedupe but the problem with it is it's going to be across the entire storage pool and all the LUNs for that storage pool have to be owned by the same storage processor.

So your setup is much like mine, we put all our luns into one big pool and not multiple pools so if we wanted to use dedupe we would have to move all our luns to one storage processor and not be able to split the load.
 
I'm still carving out the new storage (hemming and hawing back and forth trying to decide how to break it up), so I have the ability to lay different pools across different SPs. I'm now looking at how to break 118TB into smaller pools, and whether that should be larger pools or smaller, and what size the LUNs should be.

Since you two seem to have some experience with these, I'll throw this in as well. Given the following:

• Servers are a mix of Windows (2003-2012 R2) with a few Linux based appliances
• Server storage ranges from 40GB-850GB
• Storage is tiered with 200GB Flash VP, 1.2TB SAS and 3TB NL-SAS drives (Raid 5, 5 and 6 respectively)
• ESXi 5.1u3 using VMFS5
• LUNs will be in a storage cluster, with SDRS and SIOC enabled
• Total pool size will be at least 26TB, but could go as large as 47TB

What would you recommend the LUN size be? Should it be smaller (around 2TB) or larger (around 4TB)? Is there any benefit to going with a smaller pool size versus a larger one (as in the last bullet point above)?
 
Even though I deployed one of the first VNX's in North America my recommendation would be to get a different storage array so you don't have to think about any of this, but I'm biased since I'm wearing an orange shirt. :)

That being said, the tiering size recommendations are just that -- recommendations. EMC has found for most mixed workloads the 10/20/70 mix provides the best bang for the buck. That's not to say if you create a 20/20/60 or 50/50/0 tiered pool that's a bad thing, only that it will perform differently than a 10/20/70 tiered pool (be that a good or bad thing).

Not knowing your IO requirements, I can't really say what the best mix would be but I will say that you should identify if you have any specific workload requirements that would not play nice in a mixed storage IO environment, such as a high write IO database that would not play nice on RAID 5 or content that requires large amounts of sustained sequential IO. Weed out the problem children first, architect pools or RAID groups specifically for them, then put everything else into one big ass tiered Storage Pool with FAST Cache in front of it. I would also not recommend turning on block deduplication. It will pin all LUNs in that pool to a single SP and you'll create a nightmare for yourself unless you want to create numerous, smaller storage pools (which defeats the purpose of storage pools in the first place).

If you plan to use file protocols, EMC is very, very particular on how you carve LUNs out of a Storage Pool for use as CIFS or NFS, so be sure you have their support on creating those LUNs per best practices. But do not use NFS from the VNX for your datastores! :p Pain and misery will very likely befall you. :)

If you're going to use Storage cluster and SDRS in VMware, be sure you disable fully automated migrations based on storage metrics. This will confuse the hell out of FAST VP and those automated Storage VMotions will throw off its calculations on what data is hot or not.

As for LUN size, I prefer to stay small enough so I'm putting less than 20 VMs on a datastore, only to reduce the size of my failure domains.
 
Hey guys,

I'm assisting on an install for a Dell SC4020 within the next two weeks.

Child of Wonder This unit is built on Compellent and EqualLogic DNA. I'm thinking that the SDRS rule applies to my install as well.

Any other suggestions that may be applicable to both of us.

15/65/30 split SSD/10K/7.2kNLSAS
 
Block dedup on vnx2 is still immature and not worth it.
 
Child of Wonder, thanks for the info and tips. This VNX5400 is block only (not unified), so no file. We have file on other arrays but only actually use it on two, and that works fine in their application. And as for the I/O requirements, the special use LUNs with different I/O requirements would be taken out of the mix and will receive either their own dedicated pool or LUNs. I did have metrics turned on for SDRS, so I have turned that off based on your recommendation. I'll keep the LUN size in mind as well ;)

Langly, what's your experience with dedupe, and why do you feel it's not worth it?
 
t_ski said:
Child of Wonder, thanks for the info and tips. This VNX5400 is block only (not unified), so no file. We have file on other arrays but only actually use it on two, and that works fine in their application. And as for the I/O requirements, the special use LUNs with different I/O requirements would be taken out of the mix and will receive either their own dedicated pool or LUNs. I did have metrics turned on for SDRS, so I have turned that off based on your recommendation. I'll keep the LUN size in mind as well ;)

Langly, what's your experience with dedupe, and why do you feel it's not worth it?
Click to expand...

Every code release on VNX2 since block dedup was introduced has had some sort of impactful bug in regards to dedup containers. Some of these have led to major DU or DL situations noted in ETAs from EMC which I don't want to risk.

Most of my customers I've had want to turn it on when they have over 30% write IO to the pool itself. If your pool/luns have greater than 30% write IO percentage then your performance is going to tank with dedup enabled.

Block dedup is really good for archival type systems with small amounts of change to the data itself. I really haven't seen it really shine in any other type of situation. It still just needs time to mature and get the code settled in my eyes, I don't feel like having my customers beta test a feature and risk the data.
 
Thanks, that's the kind of detail I was looking for. I will probably stay away from it for now. My main interest was something our technical/sales guy* said about using it in a VDI environment, where all the VMs are spun up from templates or from VMware View. He thought that these would dedupe on a high level and force that common data into the flash for best performance.


*He's not the sales rep, but he's a technical advisor to the sales guy. He's the one that likes to take us out to lunch and talk 90 miles an hour about buzzwords and cool things he hears from the marketing people. :rolleyes: My coworker wants to go for the free food, but I get roped in due to the tight integration with VMware, which is one of my main support roles.
 
Don't use a VNX for VDI. It won't perform well unless your VDI footprint is tiny and you use a large number of spindles just for VDI. Get an all-flash array like Pure, Tintris new AFA, or even XtremIO. Obviously I'd recommend Pure. :)
 
We have a VNX5300 right now that uses a lot of 300GB SAS drives and some flash, along with some 2TB NL-SAS. It works pretty well for us, but we have one year left on it. We will be replacing it next fiscal year, and where we go depends on a lot more than I can put here for now.
 
You must log in or register to reply here.
Back
Top