eToggle™, the Extreme Networks^® iPhone™ Application for Conference Rooms, allows you to easily enable and disable ports on your Extreme Networks Ethernet switches, making public conference rooms more secure. You can set a personal identification number (PIN) to prevent unauthorized access to the application.

One of the features in the new version of Data ONTAP 8.0 is the ability to use 64 bit aggregates, prior to this all aggregates were 32 bit.  The main reason to use a 64bit aggregate is to break the 16TB aggregate limit found in 32 aggregates.

ONTAP 7.3 helped with this in that it changed the way the 16TB was calculated, it no longer counted the parity drives in the 16TB which gave you an extra ~20% usable space in your aggregates (actual savings varied based on disk size).  As mentioned before, to expand beyond the 16TB a 64 bit addressing scheme needed to be used, the following shows the limit of either aggregate type:

32 bit aggregates are calculated by 2^32 * 4KB = ~16TB
64 bit aggregates are calculated by 2^64 * 4KB = ~67,108,864 (67 million petabytes)
Note: There are limits to the maximum sizes of 64 bit aggregates which are based on controller model

Those limits are currently:

A few things to note with that are that the maximum file/LUN size is still 16TB and that the maximum volume sizes for dedupe volumes remains the same.

When sizing your system keep in mind that the root aggregate must be 32 bit, it is also important to note that you cannot currently convert a 32 bit aggregate into a 64 bit aggregate (or vice versa).  The next major release of ONTAP 8 will have the ability to convert 32 bit to 64 bit non-disruptively however.

Along the same lines, you cannot perform block level transfers between aggregate types – Volume SnapMirror(VSM) between 32 bit and 64 bit aggregates will not work.  (Qtree SnapMirror(QSM) however will work as it is file based, as will NDMP)

The default type for creating new aggregates is 32 bit, for 64 bit you need to specify a -B 64 if using CLI or select the checkbox if using FilerView.  After upgrading to ONTAP 8.0 7-mode all existing aggregates will remain 32 bit (as mentioned before you cannot non-disruptively convert them yet to 64 bit)

Originally posted at: http://mtellin.com/2010/01/06/netapp-64-bit-aggregates-in-ontap-8-0/

Obviously you need to be aware that enabling compression will add additional load onto your system but keep in mind you can use FlexShare to set lower priority to system level (e.g. SnapMirror) operations.  Another thing to keep in mind is that FlexShare is assigned per volume, so it doesn’t have to assign ALL of your SnapMirror transfers a low priority.

Enabling compression is as easy as modifying the /etc/snapmirror.conf file, you can enable compression on existing SnapMirror relationships.  The changes you need to make are as follows:

At the top of snapmirror.conf you need to establish a connection name and assign the source and destination filers to it.  For my example this will be:

sm1=multi(940-1,940-2)

<connection name>=multi(<sourcefiler>,<destinationfiler>)

Now you need to modify the existing line for the SnapMirror schedule, my example looks like this:

sm1:test_vol 940-2:test_vol_recv compression=enable – 10 * * *

Example:

For my example I was setting this up on a FAS940, I ran ‘sysstat –s 1’ before running the snapmirror and it averaged about 1% CPU usage

Source NetApp:

Destination NetApp:

After kicking off the initial snapmirror transfer I re-ran the same command and it returned an average CPU usage of 72% on the destination and 100% on the source.

Source NetApp:

Destination NetApp:

So again if you have a busy system, you will need to decide if the decreased WAN traffic outweighs the added load on your system.  I kicked off a ’snapmirror initialize’ and then monitored the transfer with ’snapmirror status -l’ and saw that I was getting a steady 8.0:1 compression ratio on my transfer.

Originally posted at http://mtellin.com/2009/11/23/using-compression-with-snapmirror-transfers-in-ontap-7-3-2/

A user community of EXOS Scripts!  Check it out!

NetApp released v1.0 of their VSC for VMware vSphere, VSC is a plugin for vCenter which allows anyone connecting with the VI Client to access it.  What is nice about the tool is it allows you to see an overview of your storage environment and ensure things are configured inline with NetApp’s recommended best practices and, if they aren’t, allows you to set the recommended values.

Click on the pictures for a larger view, you can see it adds a new tab called NetApp when the ESX server is selected.  In my environment we are using all NFS for storage to the ESX boxes, so in the next screen I show the ‘Storage Details – NAS’ option:

What is nice about this view is I can quickly see I need to make a couple changes on the NetApp, the ucode settings should be set to on and the atime update should be set to on as well.

As mentioned before, there are also ESX specific settings that should be set to follow best practices, by right clicking on the ESX hosts listed in the NetApp tab (see 1st picture) there is an option to ‘Set Recommended Values’

Finally you can also set guest timeout settings, under the Tools option there is a download link for the .iso for Windows and Linux guests.  For some reason in my environment I couldn’t download the ISO from this page – if you have the same issue you can find it in the Program Files\NetApp\Virtual Storage Console\webapps\public folder.

Once you load the ISO in the VM, double clicking on the CD drive will ask you if you want to add the info in the windows_gos_timeout.reg file to the registry.

While I only have NFS mounted storage, you can also use the VSC to check things like:

• Storage adapter timeout settings
• Multipathing settings
• Collecting diag info from fibre channel switches (or ESX hosts/NetApp controllers)

Also remember to check NetApp TR-3749 for best practices with NetApp and VMware vSphere.

https://now.netapp.com/Knowledgebase/solutionarea.asp?id=kb47221

FCoE combines two leading technologies, the Fibre Channel protocol and an enhanced 10 Gigabit Ethernet physical transport, to provide you with more options for SAN connectivity and networking. To simplify administration and protect your SAN investments, FCoE allows you to use the same tools and techniques you use today managing your FC network and storage. The FCoE network infrastructure offers connectivity to either native NetApp FCoE systems and/or NetApp Fibre Channel storage systems. This allows you to migrate to a unified Ethernet infrastructure while preserving investments you already made in FC storage. FCoE is a logical progression of NetApp’s unified storage approach to offering concurrent support for Fibre Channel, iSCSI, and NAS data access in its enterprise systems. It provides an evolutionary path for Fibre Channel SAN customers to migrate to Ethernet over time.

As an active participant in the development and marketing of the Fibre Channel over Ethernet standard, NetApp is the first to offer storage systems with native support for FCoE. We deliver fully tested and qualified solutions with leading partners in a robust and growing ecosystem.

To learn more about how our FCoE solutions can help you consolidate I/O and reduce costs, read Top Reasons to Choose NetApp for FCoE SAN Solution and Fabric Convergence with FCoE and Lossless Ethernet or view our NetApp play-by-play demonstrating the benefits of I/O convergence with FCoE.

orginal article: http://www.netapp.com/us/products/protocols/fcoe/

In case you missed it, NetApp announced v2 of SMVI at VMworld this year.  Some of the new features are:

• AutoSupport Integration
• Backup Enhancements & GUI Re-design
• Snapshot Naming Changes
• Scripting
• Restore Enhancements
• Single File Restore
• Self-Service Restore
• Limited Self-Service Restore
• Administrator-Assisted Restore
• Restore Agent