There are several aspects that prove that Storage Foundation is an enterprise storage management tool that has been used for years on the most critical environments. Recently I had the opportunity to use the NetApp EF550 all flash array with Storage Foundation Cluster File System (CFS). Both products are a perfect fit, as the design of CFS can maximize the all flash array performance.
The topic I want to cover here is the usual gap between storage and server admins, and how Storage Foundation can help fill that gap. Storage admins always do their best to provide the appropriate storage to meet the SLA required by applications. The server admins have to consume that storage. I have found many cases in the field where LUNs are not correctly mapped, which may result in risking data protection and/or performance issues resulting when storage with incorrect characteristics (such as RAID levels) has been provisioned.
The NetApp EF550 array offers a nice tool to create the LUNs. Each LUN is defined by one UDID and a name assigned to the LUN as we can see here.
When using native tools, the mapping between the LUNs and how they are consumed on the server side can be a tough task not devoid of risks. Let’s examine several ways to accomplish this.
The semi-native way
In this example, I was adding 4 additional LUNs to my servers. Each new LUN has 8 paths, which means suddenly 32 new devices appear at the OS level. To add more complexity, there is another spare LUN already mapped to the server, so I have to also discover which are the four new LUNs added.
First, I have to find out which are the new devices added to the system. Going through fdisk output I can see some of the new devices. It is a little messy as I have 8 paths per device and to be honest, I have used Symantec Volume Manager to identify which are the new devices. By comparison, running the ‘vxdisk list’ command is easy to see what devices are new:
So my trick here has been to use Symantec Volume Manager to identify the paths for the new devices. For example I can interrogate one specific disk using ‘vxdisk list <devicename>’
So just with ‘vxdisk list’ I can, in fact, get the UDID number, as well as identify which OS devices correspond to the LUN:
Without Volume Manager, first I should have been able to identify which are the new paths for one specific LUN and probably use some scsi_id commands to find out that information. Clearly, it can be very tricky.
So with that information now I can call my storage admin fellows and ask them about what LUN is …CB3A1, and they may come back with this information:
Now, I finally know that /dev/sdcp is the 500GB LUN named ora_data_7. With Volume Manager, that will be my disk netapp-e0_99
Filling the GAP between storage and server admins
Why don’t we talk all the same language? The advantages of using an enterprise solution like Storage Foundation is that it really simplifies storage management. A component of Storage Foundation, called the Array Support Library (ASL) can discover the extended attributes for those disks and I just need to use ‘vxdisk –e list’ to get those. Instead of doing all the previous work trying to find out the LUNs and map them correctly, I am able to get this information in a single command:
Now I can quickly identify the LUNs I am looking for. Not having this visibility is not only time consuming but also prone to errors. As I stated before, I have seen and heard many times about LUNs not properly mapped, putting business at risk because critical data was placed on storage that could not provide the SLAs required.
Storage Foundation fills the gap, enhances productivity, provides greater visibility and reduces risks. Symantec’s regularly updated ASL’s can provide similar data for most of the industry’s popular storage arrays, just in case you’re not using the NetApp EF550 today. You can find more about this and other extended attributes in the ASL/APM Technotes, available at http://sort.symantec.com
NOTE: This ASL version has not been published yet as it is in the certification process
Carlos.-
Thank you Chad and Dammi for your work to get this done!
