There are several different ways to upgrade OnTap, but to be honest I ended up discovering my own, and found it to be the most reliable! The key is to get the OnTap software onto the filer. Oddly, the filer doesn’t recognise the Unix format of the download, so you need to download and copy across the Windows version of OnTap. You need to copy the software across into /vol/vol0/etc/software.
To copy it onto the filer you have several options.
CIFS
Simply copy it over from your Windows desktop or server. If you don’t have CIFS licensed, just connect to c$ anyway as you are allowed admin access using CIFS. (\\filer_name\c$\etc\software). Double check the qtree permissions on vol0 and make sure it’s NTFS.
NFS
If you have NFS licensed, then you can use your *nix system to mount vol0. You might need to modify the exports (rw=workstation_ip,root=workstation_ip) so you have permission to copy the files across. Double check the qtree permissions on vol0 and make sure it’s UNIX.
Web Server
If you can put the OnTap executable on a webserver that the filer can access, then the filer can download the files itself. This is actually a really nice way of deploying an upgrade to multiple filers. I usually run a web server on my laptop, so this works quite well, I just keep my apache install with the latest OnTap versions in the root, and point a filer at my laptop.
ndmpcopy
If you have already placed the OnTap executable on another filer, then you can copy it across.
ndmpcopy -sa root:password -da root:password filer01:/vol/vol0/etc/software/ontap.exe filer02:/vol/vol0/etc/software/ontap.exe
ftp
You can enable ftp on the filer, copy the OnTap executable onto the filer, and then copy this into vol0. Obviously you shouldn’t allow ftp to access vol0 directly (for so many reasons), but you can copy it into another volume, then use mv (within priv set advanced), or ndmpcopy to copy it across.
Once the OnTap executable has been placed into /vol/vol0/etc/software you can get the filer to install it. This is a 3 stage process, and 2 of the stages can be done with relatively low disruption.
software install ontap_version_x.exe
This unpacks the Windows self extracting file and places it within vol0. This can be done with no service disruption.
download
This takes the newly extracted files and commits them to the filer, overwriting the boot kernel and other files. Although this can be done with no disruption to any services, you may find the Filer View could break afterwards if this has been upgraded in the new OnTap version.
reboot / cf takeover
Depending on what you are trying to achieve, if this is a stand-alone system, or you have scheduled downtime, you can do a reboot. If you are looking to do a NDU (Non-Disruptive Upgrade), then you would get the partner filer to issue a “cf takeover”. This causes the upgraded filer to reboot, but the services are failed over, so you shouldn’t lose any access. Once the filer has rebooted and is “waiting for giveback”, you can issue “cf giveback” to finish booting into the new OnTap version.
If you do have scheduled downtime, or this is a stand-alone system, then you can issue “software update ontap_version_x.exe” to perform all 3 above steps in one move. This can be really nice if you don’t mind the outage, and you can even point this command at a web-server (“software update http://server_name/ontap_version_x.exe”) and the whole thing becomes quite smooth!
Gotchas
There are, as always, a few things to look out for.
NDU is always a bit of a challenge and you need to check all the pre-reqs and documentation very carefully. If you want all your systems to stay up, you need to do some research. NDU can work great if planned, I’ve done it many times, and the only times I’ve seen it cause problems is when it hasn’t been planned, or there’s an extra system that wasn’t planned for.
Upgrade all dependent systems first. If you have SnapDrive, SMAI, etc, upgrade these first. These are almost always backward compatible, but often not forward compatible. This usually requires more planning than just the OnTap upgrade itself!
Upgrade firmware first! Very important if you want a smooth upgrade. When the filer boots it always checks the firmware folders (“/vol/vol0/etc/disk_fw” and “/vol/vol0/etc/shelf_fw”). If these contain newer versions that what it finds already applied to the system, it will stop the boot and apply these first. Shelf firmware can take 20-30 minutes, so your smooth upgrade has just been delayed by 20 minutes! In NDU, this is catastrophic!!!
If you upgrade disk and shelf firmware, it can generally be done totally NDU (with the exception of SATA, but that is a lot less disruptive than a boot upgrade). So it is well worth taking the time to upgrade this first.
