ONTAP

You are currently browsing articles tagged ONTAP.

Data ONTAP Upgrade

To be honest, there are times when using Mac OS X can be difficult.  With the overwhelming installed base of Windows and the attention of the media darling Linux, vendors will often provide instructions on how to do something with Windows or Linux, but not from Mac OS X.  Sometimes the Linux instructions work, but many times they don’t, and the Windows instructions typically involve running some sort of Windows executable that won’t, of course, run on Mac OS X.  What is one to do, then?

This is situation in which I found myself last week while trying to upgrade a Network Appliance storage system (an old F840) in the lab.  I wanted to upgrade the F840 to Data ONTAP 7.1.2.1, the latest GA release in the 7.1.x family (Data ONTAP 7.2.x isn’t supported on the F8xx series).  There are instructions for performing the upgrade from a UNIX/Linux-based system as well as instructions for upgrading the storage system from a Windows-based computer.  OK, but what about a Mac?

Well, Mac OS X is based on FreeBSD, so the UNIX instructions should work, right?  Well, not quite.  Although I mounted the NetApp’s root volume via NFS and attempted to extract the files per the instructions, it kept failing.  OK, what if I mount it via CIFS?  Same result—an error during the file extraction/file copy process and an error when running the “download” command.

Well, I can’t exactly run the Windows executable version of the Data ONTAP upgrade because I don’t run Windows.  The UNIX/Linux instructions don’t work.  Fortunately, there’s a third option—the HTTP server upgrade.  I had an OpenBSD-based web server in the lab, so within just a few minutes I had the Data ONTAP upgrade files on that server and then onto the storage system itself using the “software get” command.  The process worked quite smoothly, and I was finished upgrading the storage system a few minutes later.

I even went back and reviewed the upgrade guide again to see if it explicitly listed specific client operating systems as a prerequisite for upgrading the storage system.  The upgrade guide states that “any available version of UNIX” is required.  So why didn’t Mac OS X work?  Why did I keep getting errors running the Perl install script, yet the HTTP upgrade worked flawlessly?  Don’t get me wrong, I’m glad the upgrade worked.  I just a bit peeved that something that should have worked according to the documentation didn’t.

So, here’s a tip for all of you out there: if you ever need to upgrade a Network Appliance storage system to a newer version of Data ONTAP from a Mac OS X system, be sure to use the HTTP upgrade method.

Tags: , ,

Comparison of WAFL and ZFS

This comparison of ZFS (Zettabyte File System) and WAFL (Write Anywhere File Layout) by Network Appliance (no direct link for WAFL) is an interesting comparison of these two advanced filesystems and their feature set.  Be sure to read the comments for some additional insight on the comparison of the two filesystems and some clarification about supported features.

One distinction raised in the comments that’s worthy to be noted here is that any comparison of this sort also, by its very nature, takes into account the operating system that runs the filesystem.  As a result, any comparison of ZFS vs. WAFL also involves, to a lesser extent, Solaris and Data ONTAP, respectively.  Similarly (and I think this may have been pointed out in the comments as well), the underlying hardware used by these filesystems (and their operating systems) also comes into play as well.

For these reasons, it’s impossible—in my mind, at least—to perform any sort of apples-to-apples comparison of these two technologies.  It’s still an interesting article, though.

Tags: , , , , , ,

While setting up a Network Appliance storage system today for a customer, I ran into a situation that was a bit puzzling for a moment.  I needed to change the IP address on the storage system’s clustered controllers, but in order to do that I needed to edit some files in the /etc directory on the root volume.  Normally, that wouldn’t be a big deal; I’d just mount the root volume (vol0) via CIFS or NFS from my MacBook Pro and go from there.

However, in this particular instance, the customer hadn’t licensed the CIFS and NFS protocols because this storage system would be used strictly as an iSCSI target for a VMware ESX Server deployment.  That meant there would be no mounting the root volume this time.  So how does one go about editing files in the Data ONTAP CLI?

Excellent question.  The answer is the “priv set advanced” command.  Rightly so, NetApp warns you that running “priv set advanced” exposes functionality that can be dangerous; don’t muck around in there or you’re likely to find yourself with a non-functional NetApp storage system.  However, with a bit of caution, the advanced commands are just what we need in this situation.

The advanced command set includes useful commands like “ls” (to list the files in the /etc directory, for example), “rdfile” (think of “cat” or “more” from a Linux/UNIX system), and “wrfile” (for redirecting standard input to a text file).  While there’s no text editor per se, these three tools can get us most of the way there.

So here’s how I used the advanced command set to change the IP addresses of the storage system:

  1. Enabled the advanced command set with “priv set advanced.”
  2. Displayed the current contents of the /etc/hosts file with “rdfile /etc/hosts”.
  3. Created /etc/hosts.new (containing the contents of /etc/hosts with the changes I needed) using “wrfile /etc/hosts.new”.
  4. Verified the contents of /etc/hosts.new using rdfile.
  5. Renamed /etc/hosts to /etc/hosts.setup using “mv”.
  6. Renamed /etc/hosts.new to /etc/hosts using “mv”.
  7. Rebooted the storage system for the change to take effect.

Upon the reboot, the storage system was now using the new IP addresses requested by the customer.  Problem solved!

Tags: ,

Pending Articles

With the holidays and all, a few articles that I’ve been working on for a while have been delayed.  However, to assure you that more original content is on the way, here’s a quick look at some of the articles that I hope to have published here within the next couple of weeks:

  • More information on using Network Appliance Snapshots to recover virtual machines:  I published an article on using Snapshots to recover individual files from VMs, but I also want to look at recovering entire VMs using NetApp’s snapshot functionality.
  • ESX-Active Directory integration:  The last article I published on ESX integration into Active Directory needs to be updated for ESX Server 3.0.x.  I may also roll a brief discussion of esxcfg-auth into this article as well; I’m not sure yet.  I know that I want to talk more about esxcfg-auth, but I’ve not yet decided exactly what form that will take.
  • Data ONTAP-Active Directory integration:  This one is just about done, but there are some technical details that still need work before it will be ready.
  • Using Data ONTAP to enhance VMware quick provisioning functionality:  This article will look at the use of NetApp-specific functionality, like FlexClone, to enhance the quick provisioning functionality of VMware ESX Server and VirtualCenter.  This article is one that I’m really excited about, but it’s also the article that needs the most work before its ready.  (Sorry.)

Other things that I plan to write about at some point in the future, but that aren’t anywhere as close as the ones above (in other words, I haven’t even started on them yet):

  • Updated Linux-AD integration instructions that incorporate the use of Samba (this would be an amalgamation of earlier articles)
  • Updated Solaris-AD integration instructions to account for any possible changes in Solaris 10 11/06 and, if possible, using Samba to assist with the process
  • Using a NetApp storage system instead of a Windows server to provide the NFS storage for automounted home directories (similar to what I described in this article)
  • Using a Solaris server instead of a Windows server to provide the NFS storage for automounted home directories
  • Using a NetApp storage system to provide NFS datastores to VMware ESX Server 3.0.x

If you see something on this list you’d like to see sooner rather than later, please let me know in the comments.  If there are certain things that readers are more interested in seeing, I may be able to shuffle the order of articles around and accommodate the requests.

UPDATE:  A number of the pending articles referenced above have been published:

Enjoy!

Tags: , , , , , , , ,

Network Appliance Snapshots—point-in-time copies of a file system that can be created almost instantaneously and which generally require much smaller amounts of storage to keep—are an integral part of NetApp’s value over other storage systems.  These snapshots make it far easier and quicker to recover from data loss or corruption than a tape backup system.

But how do we go about recovering individual files from a snapshot when those files are stored in a virtual disk (VMDK) file used by a VM?  After all, VMware proponents tout the encapsulation property of virtualization as a benefit: “One file to back up and you get a backup of your entire server!”  Fortunately, there’s a way to continue to reap the benefits of encapsulation while still allowing for the ability to recover individual files from a snapshot of the VM’s virtual disk file.  Here’s how.

The trick here is to take advantage of LUN cloning, a feature on the NetApp storage systems that allows you to take a snapshot—which is a read-only point-in-time copy of the file system—and create a clone, which is a read-write point-in-time copy of the file system.  This clone takes only seconds to create, like the snapshot on which it is based, and requires only enough storage to store the changed blocks, i.e., the “deltas” between the clone and the original.  We can then present that clone back to VMware ESX Server to manipulate in whatever way we see fit.

There are three parts to this process.  First, we configure ESX Server to recognize snapshot LUNs on the SAN (this is a one-time configuration change).  Then, we take the snapshot on the NetApp storage system, create a LUN clone from the snapshot, and present that LUN clone back to the ESX servers.  Finally, we manipulate the LUN clone within ESX in order to retrieve the specific data we need.

Enable Resignaturing on ESX Server

In the ESX SAN Configuration Guide (found here on VMware’s site), there is this blurb about resignaturing:

VMFS volume resignaturing allows you to make a hardware snapshot of a VMFS volume and access that snapshot from an ESX Server system.

This is the functionality that allows us to use LUN clones on the NetApp storage system in ESX Server.  Without this functionality, the LUN clones aren’t properly recognized by ESX Server and can’t be utilized to allow us to perform data recovery.

To enable VMFS volume resignaturing, set the LVM.EnableResignature option to 1 (on).  This option can be set in VirtualCenter using these steps:

  1. Set the ESX Server host for which you want to enable VMFS volume resignaturing.
  2. Go to the Configuration tab for that host, then select Advanced Settings.
  3. Change the LVM.EnableResignature to 1 (on).  The default is off.

After this option is set, you’ll be able to present LUN clones (or other hardware snapshots) to ESX Server and it will recognize them as such.

Now we’re ready to move to the NetApp storage system.

Taking a Snapshot and Making a LUN Clone

By default, snapshots are already enabled and scheduled, so unless you’ve modified the configuration, the NetApp storage system is already taking snapshots of the volumes that hold the LUNs where the VMware VMFS partitions (and thus the VMDK virtual disk files) are stored.

We can view the list of snapshots like this:

filer> snap list vol_name
Volume vol_name
working...

  %/used       %/total  date          name
----------  ----------  ------------  --------
  0% ( 0%)    0% ( 0%)  Dec 30 08:00  hourly.0
  1% ( 0%)    0% ( 0%)  Dec 30 00:00  nightly.0
  1% ( 0%)    0% ( 0%)  Dec 29 20:00  hourly.1
  1% ( 0%)    0% ( 0%)  Dec 29 16:00  hourly.2
  1% ( 0%)    0% ( 0%)  Dec 29 12:00  hourly.3
  2% ( 1%)    0% ( 0%)  Dec 29 08:00  hourly.4
  2% ( 0%)    0% ( 0%)  Dec 29 00:00  nightly.1
  3% ( 0%)    0% ( 0%)  Dec 28 20:00  hourly.5

Now, we can make a LUN clone from one of these snapshots and map it to an igroup (this would normally all be on a single line, but I’ve wrapped it here for readability):

filer> lun clone create /vol/vol_name/lun0_clone -b /vol/vol_name/lun0_vmfs nightly.1
filer> lun map /vol/vol_name/lun0_clone igroup_name 0

The LUN clone has now been created and presented back to the igroup named igroup_name as LUN ID 0.  A rescan of the storage adapters in ESX Server (iSCSI was being used in this case) will now show the LUN clone as “snap-00000001-lun0_vmfs” (the number will change depending upon how many snapshot LUNs have been presented to the server farm).  Now that we have access to the VMFS, we can do any number of things:

  • We can create a new VM with the same configuration as the original VM and boot it up to recover data from the VM in that manner (be cautious of networking issues, such as duplicate IP addresses).  You’ll just need to select the existing VMDK (or VMDKs, if there are more than one) on the snapshot VMFS LUN instead of creating a new virtual disk file when creating the VM.
  • We can attach the VMDK(s) to an existing VM running the same operating system (or an operating system that will read the file system used inside the VMDKs in question) and then browse the file system to retrieve data stored inside the VM.
  • We could shut down the original VM and boot up the clone VM instead.  This might be helpful if you needed to recover data but also needed network connectivity, or if the two VMs couldn’t be running at the same time.  (In theory, this might work for Microsoft Exchange, if you aren’t using SnapManager for Exchange.)

As you can see, this allows us to take full advantage of encapsulating the server in the VMDK file(s) but also allows us to retrieve individual files or groups of files from a snapshot of the VMDK file(s).

In future articles, I’ll touch on restoring entire VMs using NetApp snapshots, as well as talk about getting consistent snapshots of the VMs.

Other Information

This process was performed on a Network Appliance FAS810 running Data ONTAP 7.1.1.1 and servers running VMware ESX Server (both 3.0.0 and 3.0.1) with the software iSCSI initiator.  VMs running Windows Server 2003 R2 were used for testing.

Tags: , , , , , , ,

By default, the SSH configuration on VMware ESX Server only supports AES encryption types (specifically, AES-256 and AES-128).  If you need SSH connectivity from ESX Server to a Network Appliance storage system running Data ONTAP, you’ll need to modify this to support 3DES.

This kind of connectivity would be necessary if you were interested in running scripts on ESX Server that connected to the NetApp storage system via SSH to run commands (for example, to initiate a snapshot via the command line).  This arrangement is described in this document from NetApp.

To modify the ciphers supported by ESX Server, edit the /etc/ssh/ssh_config file and change this line:

Ciphers aes256-cbc,aes128-cbc

Instead, it should look like this:

Ciphers aes256-cbc,aes128-cbc,3des-cbc

This will enable SSH connections from ESX Server to find a compatible cipher with the SSH daemon running in Data ONTAP.  Note that we change the SSH configuration on ESX Server because, as far as I know, the ciphers supported by the SSH daemon in Data ONTAP are not configurable by the user.

Note that you’ll also need to enable SSH traffic through the ESX firewall:

esxcfg-firewall -e sshClient

And, of course, you’ll need to configure and enable SSH access on the Network Appliance storage system itself using the “secureadmin” command in Data ONTAP:

secureadmin setup ssh
secureadmin enable ssh2

Once SSH is reconfigured on ESX Server and configured/enabled in Data ONTAP, then using SSH to run commands remotely from ESX Server to the NetApp storage system should work without any problems.  For complete automation, you’ll also want to setup SSH shared keys as well, but I’ll save those details for a future article.

Tags: , , , , , ,

Network Appliance storage systems are becoming more and more visible in VMware deployments due to their iSCSI support and the synergies that are gained when combining VMware’s functionality with the functionality of Network Appliance’s Data ONTAP operating system.  I’ll touch on those synergies in a future article, but in the meantime here’s how to configure a NetApp storage system to present iSCSI storage to one or more servers running ESX Server.

Configuring the NetApp Storage System

Configuring the NetApp storage system is really pretty simple.  (OK, so maybe it’s only simple if you know what you are doing and have done it before.)  It basically boils down to four steps:

  1. Create the flexible volumes (FlexVols) that will store the LUNs for ESX Server.
  2. Create the LUNs that ESX will use to establish a VMFS datastore.
  3. Create the initiator group(s) (igroups) that will enable connectivity from the ESX server(s) to the NetApp storage system.
  4. Map the LUNs to the appropriate igroup.  This enables visibility of the LUNs to connected systems based on igroup.

Once these four steps are done, we are ready to move on to configuring ESX Server to utilize the NetApp-provided storage.

Create the Flexible Volume(s)

As needed, you’ll need to create flexible volumes (FlexVols) in which to store the LUNs.  The command would look something like this:

vol create fv_serverluns -s volume <aggregate name> 100g

This creates a 100GB FlexVol named “fv_serverluns” with a volume space guarantee (meaning that the 100GB is preallocated to the volume and unavailable for use by other volumes in the same aggregate).

Since the volume will serve as the container for the LUN(s), you’ll need to create the appropriate FlexVols before creating the LUNs.  Remember that the beautiful thing about FlexVols is that they can be dynamically resized.

Create the LUNs

Now we’ll create the LUNs that will be exposed to the servers for their use.  Use the following command to create a LUN:

lun create -s 10g -t vmware <full path to LUN>

For full path to LUN, specify the name of the containing volume and the name of the LUN you’d like to create.  For example, to create a LUN called “citrix_lun” on our volume named “fv_serverluns”, the path would be:

/vol/fv_serverluns/citrix_lun

Repeat this command for each LUN that needs to be created.  Be mindful of the fractional reserve and snapshot reserve when allocating space in a volume to LUNs.

Create the Initiator Group (igroup)

In order to make the LUNs visible to connected hosts, we must create an initiator group (igroup).  In the iSCSI world, the igroup will contain the iSCSI node names of the initiators that will be connecting to the storage system.

To create an iSCSI igroup, use the following commands:

igroup create -i -t vmware <igroup name>
igroup add <igroup name> <iSCSI node name of ESX host>
(Repeat for each ESX host that will connect to these LUNs)
iscsi security add -i <iSCSI node name> -s CHAP -p <password> -n <username>
(Repeat for each ESX host, or set default security)

Once the igroup has been created and security set, then you can map the LUNs to the igroup to make them visible to the hosts.

Map the LUNs

Mapping the LUNs merely makes a connection between the LUN and an associated igroup, which is (in turn) associated with a group of iSCSI initiators.

To map the LUNs, use the following commands:

lun map <full path to LUN> <igroup name> <LUN ID>

For example, if you had a LUN named lun_server1 in the flexible volume fv_serverluns, then the full path to the LUN would be something like “/vol/fv_serverluns/lun_server1”.  To connect that LUN to an igroup name “iscsi”, you would use this command:

lun map /vol/fv_serverluns/lun_server1 iscsi 0

That would map the LUN as LUN ID 0 to that initiator group.  Of course, you must use a unique LUN ID for each LUN that you map to an initiator group.  That is, LUN IDs must be unique within an initiator group, but not between initiator groups.

That’s it.  The rest of the work is up to ESX Server.

Configuring the ESX Server(s)

Configuring the ESX Server(s) to see and use the new iSCSI storage being presented by the NetApp storage system can be broken down into 3 steps:

  1. Enabling the software iSCSI initiator.
  2. Configuring the iSCSI initiator for security and discovery and then discovering new LUNs.
  3. Creating VMFS datastores on the new LUNs.

These three steps assume that you’ve already created a VMKernel port group for iSCSI and a matching Service Console port group on the same subnet.  If you haven’t already done that, go ahead and do that now.

Let’s take a quick look at these steps in a bit more detail.

Enabling the Software iSCSI Initiator

VMware ESX Server comes with a software iSCSI initiator that can be enabled and configured.  To enable this software initiator, you can either use VirtualCenter or a command-line interface.

In VirtualCenter, enabling the software iSCSI initiator involves selecting a host from the inventory, going to the Configuration tab, selecting Storage Adapters, choosing the software iSCSI initiator (vmhba40), clicking on Properties, and then enabling software iSCSI.  (Note: The dialog box for configuring software iSCSI doesn’t dynamically update to show changes.  You have to close the dialog box and re-open it to see your changes take effect.)

From the command-line (perhaps via an SSH session to the ESX server), you can simply type

esxcfg-swiscsi -e

and that will enable software iSCSI.  And while we’re here at the command line, let’s also enable outbound iSCSI traffic through the ESX firewall with this command:

esxcfg-firewall -e swISCSIClient

Now we’re ready to move on to configuring the initiator.

Configuring the iSCSI Initiator

Once software iSCSI has been enabled, you’ll need to configure it for security (authentication) and discovery.  I haven’t found a way to do this via the command-line (yet), so all this takes place in VirtualCenter (through the VI Client).

  • From the Configuration tab of a host running ESX Server in VirtualCenter, click on the “Storage Adapters” link, then click on the software iSCSI initiator (vmhba40) and select Properties.
  • On the Authentication tab, configure CHAP authentication and specify the same username and password you entered on the NetApp storage system earlier (when you were configuring the igroup).
  • On the Discovery tab, add the IP address of the NetApp storage system as a dynamic discovery target.  You can close the dialog box after this change is completed.
  • Back in the VI Client, click to Rescan vmhba40 and discover new storage devices and new VMFS partitions.  When the rescan is complete, you should see the new LUNs that were mapped from the NetApp storage system show up.

If the LUNs don’t show up, then go back and troubleshoot the configuration—check IP addresses, verify connectivity, re-type usernames and passwords, look for typos in initiator node names or igroups, etc.  Forgetting to enable the iSCSI traffic through the ESX firewall is another common mistake, so verify that with “esxcfg-firewall -q”.

Creating New VMFS Datastores

Assuming your LUNs showed up correctly, then adding a new VMFS datastore is as simple as flipping over to the Storage section of the Configuration tab in VirtualCenter and clicking “Add Storage…”.  A nice wizard will walk you through selecting the LUN and creating a new VMFS datastore.

One quick note:  you may find it most helpful to configure only one host first, then create all your VMFS datastores from that one host.  Later, as you configure the additional hosts, the rescan will automatically find both the new LUNs and the VMFS datastores that reside on those LUNs, minimizing the number of times you have to perform a rescan.

That’s it.  As I mentioned earlier, in a future article I plan to touch on some of the advantages of using a NetApp storage system with VMware, as well as provide some technical details on how to take advantage of some NetApp-specific functionality with VMware.

Tags: , , , , , , ,

In preparation for some NetApp training that I’ll be attending next month, I downloaded the NetApp ONTAP Simulator.  The ONTAP Simulator runs on top of Linux (a few different distributions are supported) and allows you to simulate a NetApp Filer.  This is pretty cool for a couple of reasons, not the least of which is that it allows you to perform testing of NAS and iSCSI operations without having an actual Filer.  Unfortunately, I had some problems getting the ONTAP Simulator working in a virtual machine on VMware ESX Server.

To setup the ONTAP Simulator, I created a Linux virtual machine on ESX Server 2.5.3 and installed Red Hat Linux 9.0.  Red Hat 9.0 is a supported distribution for the ONTAP Simulator as well as a fully supported guest OS on ESX Server, and so I didn’t expect any issues.  However, after installing and configuring the simulator, I couldn’t get any network connectivity whatsoever.  I had full connectivity to the guest OS, but not to the simulator.

Finally, after digging around in the documentation for the simulator, I came across a statement indicating that the network interface that was being used by the simulator had to be in promiscuous mode.  That rang a bell:  ESX Server, by default, doesn’t allow NICs in guest operating systems to be in promiscuous mode.

The fix is this:

echo PromiscuousAllowed yes > /proc/vmware/net/vmnic0/config

Replace “vmnic0” in this command with whatever virtual switch or NIC team the virtual machine in question is using.  Once I did this (from the Service Console on the ESX Server) and rebooted the virtual machine running the ONTAP Simulator, it worked like a champ.

(Note:  You must be a current NetApp customer or partner in order to use the ONTAP Simulator.)

Tags: , , , , , , , , ,

Newer entries »