I wanted to take a quick moment to document the awesomeness that is a quick and easy upgrade of Data ONTAP 7-mode with HFS. HFS is a lightweight web server that’s run as an executable and lets you quickly and easily transfer your Data ONTAP images from a Windows machine to the FreeBSD-based NetApp operating system. I can’t take credit for finding this gem of the storage admin. That goes to Mike Mills (@MikeasaService) who found this while we were implementing NetApp systems in a war zone. Thanks, Mike! Of course, if you’re a Mac-man (or gal, but that doesn’t really roll of the tongue as nicely) or a Linux dude, you can easily mount the /etc/software directory using NFS in which case you don’t need a web server. But I digress…on to the steps!
Download Data ONTAP image – from the NetApp Support site (support.netapp.com) and follow the prompts and be sure to download the correct version, in this case, 7-mode
I recently had the opportunity to design and implement NetApp’s entry-level storage solution for a client and I’d like to take this chance to share my approach to the design decisions. One reason for posting this is to help others that may be contemplating similar designs. I know there are a lot of talented and experienced engineers out there that may come across this and I encourage you to comment on this design. I look forward to learning from your experiences and at the same time I hope mine can help others. I should note that the hardware purchased was outside the scope of this design as the decision had already been made, hardware ordered and shipped. Also, common sense says that I’ve changed hostnames and IP addresses to protect the innocent.
The hardware specifications include
|Controller Form Factor||Single enclosure HA; 2 controllers in a 2U chassis|
|Memory||6 GB per controller|
|CPU||Dual Core Intel Xeon C3528 @1.73 GHz, HT enabled|
|Onboard I/O: 6 Gb SAS||2|
|Onboard I/O: 1 GbE||4|
|Mezzanine I/O: 10 GbE||2|
I first had to do this at the direction of NetApp tech support. Ever since, I found myself searching my email for it so I could use it again and again. I finally took the hint and decided to post it here for my reference – but maybe you could use it as well. Oh, and copy it to Evernote, too.
They way I use this, as you might expect, is to start the capture, perform the operation that’s failing, and then stop the capture. So as not to capture too much traffic and therefore have to wade through all of it, I try to perform those steps rather quickly. But then again, if you know a few useful features of Wireshark, you can get around in the capture file pretty easily. So here you are.
filer> pktt start all -d /etc/crash
<perform the operation that fails here>
filer> pktt dump all filer> pktt stop all
Snapshots are enabled by default when a volume is created. They follow the schedule as seen from the CLI command snap sched: 0 2 6@8,12,16,20
and from the System Manager GUI. Note the default Snapshot Reserve is 5% and that the checkbox for Enable scheduled Snapshots is checked by default.
I recently had the opportunity to configure native fibre channel in my test lab at work using Nexus 55xx series switches and Cisco’s UCS. What I’ll do in this post is to share my templatized fibre channel configuration in a somewhat ordered way, at least from the Nexus point of view. This test lab was configured with the attitude that it should show off the capabilities of the hardware and software. Concepts included in this initial configuration include NPIV, NPV, SAN port-channels, F_Port trunking, VSANs, device aliases, and of course, standard FC concepts like zones and zonesets.
Let me first share the end-state as of today, what I’ll call Phase I. I’ll explain what my initial plan was for Phase I and, after learning a bit more, what I plan to do for Phase II. Please feel free to correct me in the comments below – I made a lot of mistakes configuring this and I wouldn’t be surprised if there’re a few more in there.
I was asked by a client yesterday in passing how to check CPU utilization on one of their NetApp filers. I didn’t immediately know where to go and we quickly moved on to something else. So as I was showering this morning, as I do many mornings, I remembered that, of course, you can use sysstat to view performance data. Anyways, this is a real nice way to view instantaneous general performance data. Options for this command are shown below.
deathstar> sysstat ?
usage: sysstat [-c count] [-s] [-u | -x | -m | -f | -i | -b] [interval]
-c count – the number of iterations to execute
-s – print out summary statistics when done
-u – print out utilization format instead
-x – print out all fields (overrides -u)
-m – print out multiprocessor statistics
-f – print out FCP target statistics
-i – print out iSCSI target statistics
-b – print out SAN statistics
interval – the interval between iterations in seconds, default is 15 seconds
I had the opportunity to configure SnapMirror for a client today and it gave me a bit of a headache. I did what I thought was my due diligence: reading the relevant vendor documentation for SnapMirorr for each version of Data ONTAP, 7.3.2 and 8.0.3P3. What I failed to do was read a few lines further than I actually did – I missed a simple piece of syntax that turned a 30 minute WebEx into a 2 hour ordeal. I learned a good lesson about SnapMirror during this engagement, though, and I’d like to share it.
The SnapMirror of these three volumes were actually for a data migration because the source filer is being decommissioned. The general steps required in the engagement today were as follows:
<> Run a cable between what will be the dedicated replication links on each filer
<> Configure each interface with IP settings
<> Ensure SnapMirror is licensed and enabled on each filer
<> Configure /etc/hosts and /etc/snapmirror.allow files on source filer
<> Configure /etc/hosts and /etc/snapmirror.conf files on destination filer
<> Initialize the baseline replicaction