Sunday, August 29, 2010

Execute command from a file on Ontap

Occasionally we want to quickly or periodically run a set of pre defined commands on filers, like when we are making little change in network configuration and want to minimize the network down time or when we are creating a volume and know snap reserve, snap schedule, de-dupe, autosize or anything else which needs to be changed after every volume creation. If you are executing commands from unix terminal then a better way would be to keep all the commands in a text file and would do something like

bash>for $i in vol1
>do
>snap sched $i 0
>snap reserve $i 0
>blah $i
>blah $i
>done

and everything would be done, but imagine how would you do if you are doing through console. Unfortunately Ontap doesn't supports any kind of script not even for loop so we have to run each and every line of command either by typing on console or doing a copy-paste from text file from our desktop.

However there is a better way, use notepad to create set of command as you would execute on console with correct order, copy it off to filer and use 'source' command to execute each and every line from it. I know it's not such a brilliant idea as still you have to copy and paste everything to a file on filer however it's wee better than executing each and every command on console.

Think about you have to re-run /etc/rc so either you can use 'rdfile /etc/rc' to print everything on console and copy all the the line and execute on console or just run 'source /etc/rc' and let it run all the commands for you. You can also use 'source -v /etc/rc' to print the commands on console but not to execute, just to get an idea if there are any junk characters or any unwanted command inside the file, just as a precaution you better be sure that all the commands are valid and correct as if a command fails source doesn't stops there and just goes to next command in list.

Use it and I am sure you will like it next time when you are making some changes on filer which needs ten different commands to be executed.

Saturday, August 28, 2010

How to check unplanned downtime detail for a NetApp filer

Every now and then someone ask us what is uptime of system and we just type 'uptime' on system console to get the detail instantly.


This is really handy command to know when the system was last rebooted and how many operations per protocol it has served since then. Wouldn't our life be little easy if managers get satisfy with this detail? Alas! but that doesn't happen and they ask us to give all the details since we have acquired the system or 1st January and then we go back to our excel sheet or ppt we have created as part of monthly report to pull the data.


How about if we can get same information from system with just a command, wouldn't that be cool. Fortunate enough we have little known command 'availtime' right inside Ontap which just do the exact same function and specifically created after thinking about our bosses.


HOST02*> availtime full
Service statistics as of Sat Aug 28 18:07:33 BST 2010
 System  (UP). First recorded 68824252 secs ago on Mon Jun 23 04:16:41 BST 2008
         Planned   downs 31, downtime 6781737 secs, longest 6771328, Tue Sep  9 15:07:33 BST 2008
         Uptime counting unplanned downtime: 100.00%; counting total downtime:  90.14%
 NFS     (UP). First recorded 68824242 secs ago on Mon Jun 23 04:16:51 BST 2008
         Planned   downs 43, downtime 6849318 secs, longest 6839978, Wed Sep 10 10:11:43 BST 2008
         Uptime counting unplanned downtime: 100.00%; counting total downtime:  90.04%
 CIFS    (UP). First recorded 61969859 secs ago on Wed Sep 10 12:16:34 BST 2008
         Planned   downs 35, downtime 17166 secs, longest 7351, Thu Jul 30 13:52:25 BST 2009
         Uptime counting unplanned downtime: 100.00%; counting total downtime:  99.97%
 HTTP    (UP). First recorded 47876362 secs ago on Fri Feb 20 14:08:11 GMT 2009
         Planned   downs 8, downtime 235 secs, longest 53, Wed Jan 20 14:10:18 GMT 2010
         Unplanned downs 16, downtime 4915 secs, longest 3800, Mon Jul 27 16:01:02 BST 2009
         Uptime counting unplanned downtime:  99.98%; counting total downtime:  99.98%
 FCP     (DOWN). First recorded 68817797 secs ago on Mon Jun 23 06:04:16 BST 2008
         Planned   downs 17, downtime 44988443 secs, longest 38209631, Sat Aug 28 18:07:33 BST 2010
         Unplanned downs 6, downtime 78 secs, longest 21, Fri Feb 20 15:24:44 GMT 2009
         Uptime counting unplanned downtime:  99.99%; counting total downtime:  34.62%
 iSCSI   (DOWN). First recorded 61970687 secs ago on Wed Sep 10 12:02:46 BST 2008
         Planned   downs 21, downtime 38211244 secs, longest 36389556, Sat Aug 28 18:07:33 BST 2010
         Uptime counting unplanned downtime: 100.00%; counting total downtime:  38.33% 



I am not sure why NetApp has kept this command in Advanced mode but once you know this command I bet next time you will not refrain yourself going inside advance mode to see how many unscheduled downtime you had since last reset.


A shorter version of this command is just 'availtime' it also shows the same information as 'availtime full' however it truncates letters from output and denotes  Planned with P and Unplanned with U which is very good if you want to pass it in script. 

HOST04*> availtime
Service statistics as of Sat Aug 28 18:07:33 BST 2010
 System  (UP). First recorded (20667804) on Wed Sep 23 09:35:49 GMT 2009
         P  5, 496, 139, Fri Dec 11 15:58:19 GMT 2009
         U  1, 1605, 1605, Wed Mar 31 17:01:41 GMT 2010
 CIFS    (UP). First recorded (20666589) on Wed Sep 23 09:56:04 GMT 2009
         P  7, 825, 646, Thu Jan 21 19:08:03 GMT 2010
         U  1, 77, 77, Wed Mar 31 16:34:54 GMT 2010
 HTTP    (UP). First recorded (20664731) on Wed Sep 23 10:27:02 GMT 2009
         P  3, 51, 22, Thu Jan 21 19:17:25 GMT 2010
         U  4, 203, 96, Thu Jan 21 19:08:03 GMT 2010
 FCP     (UP). First recorded (20477735) on Fri Sep 25 14:23:38 GMT 2009
         P  3, 126, 92, Thu Jan 21 19:07:57 GMT 2010
         U  4, 108, 76, Wed Mar 31 16:34:53 GMT 2010


In order to reset the output use 'reset' switch and it will zero out all the counters, make sure you have recorded the statistics before you reset the counters as once you reset the counters you will not be able to get details of system uptime since system was built so you may like to do only after you acquire a new system, have done all the configuration and now it's the time for it to serve user requests.