EMC – Why FAST VP Best Practice is Best Practice

Those of you fortunate enough to have worked with me in a professional capacity will know that I’m highly opinionated. I generally try not to be opinionated on this blog, preferring instead to provide guidance on tangible technical things. On this occasion, however, I’d like to offer my opinion. I overheard someone in the office recently saying that best practices are just best practices, you don’t have to follow them. Generally speaking, they’re right. You don’t have to do what the vendor tells you, particularly if it doesn’t suit your environment, circumstances, whatever. What annoys me, though, is the idea that’s been adopted by a few in my industry that they can just ignore documents that cover best practices because there’s no way the vendor would know what’s appropriate for their environment. At this point I call BS. These types of documents are put out there because the vendor wants you to use their product in the way it was meant to be used. And – get this – they want you to get value from using their product. The idea being that you’ll be happy with the product, and buy from the vendor again.

BP Guides aren’t just for overpaid consultants to wave at know-nothing customers. They’re actually really useful guidelines around which you can base your designs. Crazy notion, right?

So, to my point. EMC recommend, when you’re using FAST VP on the CLARiiON / VNX, to leave 10% free space in your tiers. The reason they recommend this is that they want FAST VP to have sufficient space to move slices between tiers. Otherwise you’ll get errors like this “712d841a Could not complete operation Relocate 0xB00031ED4 allocate slice failed because 0xe12d8709”. And you’ll get lots of them. Which means that FAST is unable to move slices around the pool. In which case why did you by FAST in the first place? For more information on these errors, check out emc274840 and emc286486 on Powerlink.

If you want an easy way to query a pool’s capacity, use the following naviseccli command:

naviseccli -h ipaddress storagepool -list -tiers
Pool Name: SP_DATA_1
Pool ID: 3

Tier Name: FC
Raid Type: r_5
User Capacity (GBs): 33812.06
Consumed Capacity (GBs): 15861.97
Available Capacity (GBs): 17950.10
Percent Subscribed: 46.91%
Data Targeted for Higher Tier (GBs): 0.00
Data Targeted for Lower Tier (GBs): 0.00
Disks (Type):

Bus 6 Enclosure 7 Disk 14 (Fibre Channel)
Bus 6 Enclosure 7 Disk 12 (Fibre Channel)
Bus 6 Enclosure 7 Disk 10 (Fibre Channel)
Bus 3 Enclosure 5 Disk 3 (Fibre Channel)
Bus 3 Enclosure 5 Disk 1 (Fibre Channel)
Bus 4 Enclosure 5 Disk 2 (Fibre Channel)
Bus 4 Enclosure 5 Disk 0 (Fibre Channel)
[snip]
Bus 2 Enclosure 6 Disk 14 (Fibre Channel)
Bus 2 Enclosure 6 Disk 12 (Fibre Channel)
Bus 2 Enclosure 6 Disk 10 (Fibre Channel)
Bus 0 Enclosure 2 Disk 0 (Fibre Channel)
Bus 5 Enclosure 6 Disk 8 (Fibre Channel)
Bus 3 Enclosure 2 Disk 4 (Fibre Channel)
Bus 7 Enclosure 5 Disk 6 (Fibre Channel)

Pool Name: SP_TEST_10
Pool ID: 2
Tier Name: FC
Raid Type: r_10
User Capacity (GBs): 1600.10
Consumed Capacity (GBs): 312.02
Available Capacity (GBs): 1288.08
Percent Subscribed: 19.50%
Data Targeted for Higher Tier (GBs): 0.00
Data Targeted for Lower Tier (GBs): 0.00
Disks (Type):
Bus 1 Enclosure 7 Disk 3 (Fibre Channel)
Bus 1 Enclosure 7 Disk 5 (Fibre Channel)
Bus 1 Enclosure 7 Disk 7 (Fibre Channel)
Bus 1 Enclosure 7 Disk 2 (Fibre Channel)
Bus 1 Enclosure 7 Disk 4 (Fibre Channel)
Bus 1 Enclosure 7 Disk 6 (Fibre Channel)
Bus 1 Enclosure 7 Disk 9 (Fibre Channel)
Bus 1 Enclosure 7 Disk 8 (Fibre Channel)

And if you want to get the status of FAST VP operations on your pools, use the following command:

naviseccli -h ipaddress autotiering -info -opstatus
Storage Pool Name: SP_DATA_1
Storage Pool ID: 3
Relocation Start Time: N/A
Relocation Stop Time: N/A
Relocation Status: Inactive
Relocation Type: N/A
Relocation Rate: N/A
Data to Move Up (GBs): 0.00
Data to Move Down (GBs): 0.00
Data Movement Completed (GBs): N/A
Estimated Time to Complete: N/A
Schedule Duration Remaining: N/A

Storage Pool Name: SP_TEST_10
Storage Pool ID: 2
Relocation Start Time: N/A
Relocation Stop Time: N/A
Relocation Status: Inactive
Relocation Type: N/A
Relocation Rate: N/A
Data to Move Up (GBs): 0.00
Data to Move Down (GBs): 0.00
Data Movement Completed (GBs): N/A
Estimated Time to Complete: N/A
Schedule Duration Remaining: N/A

And next time you’re looking at a pool with tiers that are full, think about what you can do to alleviate the issue, and think about why you’ve automatically ignored the best practices guide.

EMC – Other VNX Configuration Guidelines that may be useful

Firstly, apologies for the recent lack of posts. I’ve been on holidays and then started a new job and it’s all been not very related to this blog. Secondly, while it was tempting to call this blog part 5 in the VNX7500 series – these configuration guidelines work well for most all of the VNX range of arrays, not just the 7500. Thirdly, forgive me if I’ve said some of this stuff before. And finally, yes, I know I promised I’d upload some sample designs and talk about them, and I promise I will. Soon. Or soonish. So, in no particular order, here’s a list of things that you should keep in mind when designing solutions around the VNX.

Note that Pool-based LUNs, EFD-based LUNs, FAST VP LUNs, and FAST Cached LUNs do not benefit from file system defragmentation in the way traditional LUNs do. This might require a bit of education on the part of the system administrators – because you know they loves them some defragmentation action.

When configuring FAST Cache on an array, it is important to locate the primary and secondary drives of the RAID 1 pair on different Back End ports. The order the drives are added into FAST Cache is the order in which they are bound. So pay attention when you do this. The disabling of  FAST Caching of Private LUNs is recommended (these include the WIL, Clone private LUNs and Reserved LUN Pool LUNs). However, you shouldn’t disable FAST Cache for MetaLUN components.

If you’re using EFDs for “Tier 0”, you’ll get good performance with up to 12 EFDs per Back End port. But if you’re on the hunt for the highest throughput, it is recommended that this number be kept to about 5.

It is recommended that you use RAID 6 with NL-SAS drives of 1TB or greater. This has some interesting implications for FAST VP hetergenous Pool configurations and the use of 15 vs 25-disk DAEs. I’m hoping to put together a brief article on ways around that in the next week or so.

When architecting for optimal response time, limit throughput to about 70% of the following values: 

 

 

 

 

It is considered prudent to plan for 2/3 of IOPS for normal use – this will give you some margin for burst and degraded mode operation.

When it comes to fancy RAID Group configurations – EMC recommend that a single DAE should be the default method for RAID Group provisioning. If you use vertical provisioning make sure that: for RAID 5, at least 2 drives per port are in the same DAE; for RAID 6, 3 drives in are the same DAE; and for RAID 1/0, both drives of a mirrored pair are on separate Back End ports. It should be noted that parity RAID Groups of 10 drives or more can benefit from binding across 2 Back End ports – this reduces rebuild times when you pop a disk.

Finally, it should be noted that you can’t use Vault drives in a FAST VP pool. I still prefer to not use them for anything.