Re: WFA 2.0 - aggregate finder based on disk type?

reide · ‎2012-12-03

I'm using WFA 2.0. In the Create Volume command, I'm using an aggregate finder. I was surprised to see that no finder exists to select an aggregate based on disk type (SAS, SATA, FC, SSD). Especially since you do have finders for block-type. I would view this capability as key to delivering tiers of service. Is this something we could add in a later release? Am I missing some way to accomplish this?

I know that resource groups in DFM could be used for this task. However, that is a bad idea and let me explain why. Unlike WFA, DFM doesn't have the ability to easily adhere to standards and best practices. If someone creates a new SATA aggregate on a controller, DFM will automatically discover the new aggregate. However, DFM will not automatically add it to the correct resource group. It doesn't have the intelligence required to make that decision. So you're dependent on a manual process (updating resource group in DFM) to power your workflow automation. I'm not sure that's a good idea.

I also know that proper naming conventions of aggregates could help with this. But imagine implementing WFA into a large existing environment where naming standards are not enforced and the name of the aggregate tells you nothing about it.

I'd much rather have the ability in WFA to find an aggregate based on its disk type (SATA, FC, SAS, etc..) - and perhaps even the exact disk size (450 GB SAS, 600 GB SAS). This eliminates the need to depend on resource groups and that manual process. It would also allow me to deploy WFA into an existing customer environment that is a mess, and start successfully automating workflows. I could also define tiers of storage (Bronze = SATA 1 TB disk, Gold=600 GB SAS, etc..).

Thanks.

Reid

hill · ‎2012-12-03

Hi Reid,

I agree with your assessment. If we have the disk_type then it's not necessary to depend on resource groups or naming conventions. Unfortunately the reason there is no Filter / Finder to select an aggregate based on disk-type is because that information isn't currently being cached for the aggregates. The reason being because it doesn't exist in DFM. Without it being in DFM, it's not possible to cache it into WFA. That's the quick answer.

Would it be helpful to have disk_type for the aggregates? Absolutely. Unfortunately we're just not there yet.

I know this is not what you wanted to hear, but I hope it helps.

Best,

Kevin

tanmoy · ‎2012-12-03

Hello Reid,

As I read your few last statements

"

I'd much rather have the ability in WFA to find an aggregate based on its disk type (SATA, FC, SAS, etc..) - and perhaps even the exact disk size (450 GB SAS, 600 GB SAS). This eliminates the need to depend on resource groups and that manual process. It would also allow me to deploy WFA into an existing customer environment that is a mess, and start successfully automating workflows. I could also define tiers of storage (Bronze = SATA 1 TB disk, Gold=600 GB SAS, etc..)."

So, is storage tiering with disk type and size the only use case you are looking for? Or you want performance based aggregate selection also while creating a volume on that? And were you searching this information for 7-mode OR for clustered-ONTAP?

We have plans to add disk type in aggregate cache table ( one of future releases); and as Kevin said we need to have those details in DFM first.

Thanks

Tanmoy

girirp · ‎2012-12-03

Hi Kevin/Tanmoy,

Here is the full info on disk information available in OnCommand releases

OnCommand 5.0 or Earlier:

1. OnCommand has 'diskType' information for 7-Mode controllers.

2. OnCommand does not discover diskType information for Cluster-Mode. Because C-Mode disks were not discovered in OnCommand 5.0

OnCommand 5.1:

1. OnCommand has 'diskType' information for 7-Mode controllers.

2. OnCommand has 'diskType' information for Cluster-Mode. C-Mode disk were monitored and discovered in OnCommand 5.1

Message was edited by: Giridhara RP

hill · ‎2012-12-04

Hi Giridhara,

There will need to be a more detailed discussion on this. I do know it's possible for OnCommand Unified Manager (there is no OnCommand 5.0/5.1 product since OnCommand is the Portfolio name) to have disk information. However, that is not enough. It needs to be disk information FOR the aggregate. If that is contained in the DFM database great. However, I did troll through both OC UM 5.1 Cluster-Mode & the Operations Manager UI's for detailed aggregate information and drilled down as far as I could... and there was no disk-type information. For what it is worth, the cm_storage schema for aggregates in WFA does try to capture the 'number_of_disks' for an aggregate. Unfortunately, the value in WFA cache is currently '0', since it seems we can't correctly access the number_of_disks in an aggregate from DFM.

I will contact you offline along with other members of the WFA team to see what we can do to start caching disk_type information for aggregates.

Best,

Kevin

reide · ‎2012-12-04

I do know that OC UM (a.k.a. DFM) has reported this information for 7-mode a long time. I believe it is shown for c-mode as well. From a report standpoint, its shown under "Aggregate Disks". See attached screenshot for an example. I don't know exactly what this looks like from a DFM database table standpoint, so I understand this could be difficult to pull into the WFA cache.

NOTES: The disk size reported in DFM is the Block Checksum (BCS) formatted disk size - not the rightsized disk size which is what aggregates use. Its also not the marketed disk size (i.e. 1 TB, 300 GB, 600 GB). So people using this finder would have to understand that, but its fairly trivial.

NOTE: If WFA used the disk part number (i.e. X268_SGLXY750SSX) and mapped it to a pre-populated table, it could give WFA a wealth of information:

drive manufacturer (i.e. IBM)
disk rotational speed (i.e. 15K, 10K, 7200)
marketed disk size (i.e. 1 TB SATA, 600 GB SAS)
BCS formatted size AND the rightsized size of the disk
disk generation (i.e. gen 2)
etc...

This information is maintained by NetApp in the disk qualification packages and other sources, so it would be readily available for pre-populating a fixed table in the WFA cache.

Just a thought.

Reid

yaronh · ‎2012-12-04

Tanmoy,

Would you think it might be possible to acquire that information in a script based data source?

Ultimately you can run a PoSh script against all your filers once a day or a week, getting that info and caching it.

I started to think about that venue for solution yesterday for other bits of info not in DFM.

What do you think?

Yaron

hill · ‎2012-12-04

Yaron,

I need to also point out that we need to consider this option carefully. We should also recommend pulling information from OnCommand Unified Manager whenever possible since it is already acquiring the main amount of information from the storage systems. When pulling information directly from the storage controllers, there would need to be some very diligent testing here to assess the impact of another acquisition against all of the controllers... at the same time... and maybe even assuming the systems are geographically distributed, and so on. In the not-too-distant past we've run into issues where there were too many "tools" acquiring information from the storage controllers, in the innocent case, we ran out of sockets and there were timeouts. irritating. In some rare cases, the acquisitions brought the storage controllers to their knees, and some of them tipped over. Not good to put it lightly.

But, I do agree with your assessment that it should be very possible to come up with a simple script to grab "bits" of information from the storage controllers. In this instance, I would say that the PoSH script would only grab the aggregate information from the storage controllers. Grab all the aggregate information needed, not just the disk_type information and number_of_disks, since it will be easier for filters if using one WFA schema. If other bits of information would be desired for.... vServers... then that would be another PoSH script and schema... and acquisition cycle. Just my opinion there.

Best,

Kevin

reide · ‎2012-12-04

Absolutely agree that this info should be pulled from DFM and not the controller. As stated in a different reponse, DFM has this information. If you're willing to create a pre-populated table in WFA to server as a lookup-table for disk drive part numbers, WFA could provide a wealth of disk-specific information for finders/filters. I think storage admins designing the workflows would love this feature.

Reid

reide · ‎2012-12-04

tanmoy,

Definitely not the only criteria I'd want for tiering. I'd want aggregate capacity, aggregate performance, block-type, etc... However, knowing exactly what type of disk drive you're provisioning from is very important to storage admins. Most tiering strategies I've seen at customer sizes use the type of disk drive as one of the main definitions of the tier. I just raised the point because I know my storage admins are going to want to select aggregates based on that criteria.

Reid

adaikkap · ‎2012-12-04

If this request is to find aggr with SSD, then that information is coming in the next release of DFM. But there are other ways to get this information based on the disk reports.

Regards

adai