Netapp 8.1.Cluster Mode Overview -

• - Scalable cluster of Netapp filers or vfilers with 3rd party storage managed centrally and working collectively.   NAS scalable to 24 nodes, SAN scalable to 4.
• Support for SAN protocols
• NFS4.1 Support
• PNFS Support
• Asnychronous volume snap mirror for DR

Netapp 8.1 7 Mode

-Upgrades much easier, straight upgrade from 7.3.2+ to 8.1
-SAS and SATA drives can now be used in metrocluster
 

Both Modes

***Ability to do 32 to 64 bit aggregate conversion; rather than copy to new aggregate.  Happens as aggregate grows beyond 16tb aggregate limit automatically.  No performance impact.
***Aggregate size increased for the most part 50% for all systems from 8.0.x to 8.1.  This is inline with 3TB drives released.
-Max volume size is static.
***32 Bit volume snap mirror to 64Bit volume supported. 
***64 bit aggregrates are now default rather than 32.

Biggest Changes in Both Releases Storage Efficency = Deduplication, Cloning and Compression

1. No deduplication license
2.  Dedupe volume limit increased maxium volume size of supported system
3. Deduplication Performance increased, 33% higher
4. Hourly checkpoints checkpoints hourly, incase dedupe is stopped and restarted
5. Block Ratios

DataCompression

1. Compression wasn’t GA in 8.0.X in 8.1 its GA.  When it was originally released it was inline only meaning that it was compressed before going to disk.  Now it is offered both inline and post process scheduling.
2. MetroCluster Support since 8.0.2
3. Current customer usage is 40% breakdown to production vs 60% backup and archive
4. No licenses or volume limits
5. Compression of existing data 7x faster than 8.0.x

***Comparing Dedupe to Compression – Dedupe looks at the 4k blocks and creates pointers to other similar 4k blocks.  Compression looks at 32k block and looks for largest repeating pattern, cyclical process until no more repeating patterns.

Systems Manager

• 8.1 will require system manager 2.0.  System Manager will work back to DataOnTap 7.2
• Browser base supported on Windows and Linux
• ClusterMode Support
• Ability to halt and reboot controllers
• Create and Manage Snapmirror relationships
• Dedupe,compression, and snapshot integration
• File and Lun Cloning

I got this from a friend this morning. Good stuff.  New 3Par Virtualization white paper for inform os 3.1.1 and Recovery Manager updates…http://h20195.www2.hp.com/v2/GetPDF.aspx/4AA3-4023ENW.pdf

Q: Should a Thin Provisioned Virtual Volume (TPVV) be used for ESX datastores?
A: Thin provisioning makes sense as long as you are not going to fill up the volume right away. If the volume is going to be full in a short time, there is no benefit to be gained from thin provisioning. If VMware snapshots are being created and are not being cleaned up, the benefits of thin provisioning will be negated. To the ESX host, it makes no difference if the host sees a thin provisioned LUN or a traditional “thick” provisioned LUN.

Q: Is there any overhead to using Thin Provisioned Virtual Volume (TPVV)?
A: The additional overhead of TPVVs as compared to traditional volumes is negligible.

Q: If using a 2 TB Thin Provisioned Virtual Volume (TPVV), what will vSphere see?
A: vSphere will see a 2 TB LUN available for its use. Without the use of VAAI and/or T10, vSphere cannot determine if a volume is a thin provisioned virtual volume and a traditional virtual volume. With vSphere 4 or vSphere 5.0 on InForm OS 2.3.1 we recommend installing the VAAI plug-in. For vSphere 5.0 and InForm OS 3.1.1 or higher, no plug-in is required.

Q: What size Virtual Volume (VV) should be created?
A: The volume size is not as important to HP 3PAR Storage Systems, as VVs are widely striped across as many drives as possible within the array. If using HP 3PAR Thin Provisioning Software, actual storage capacity is only consumed upon write. However, a 2 TB VV will be able to accommodate many more VMs than a 500 GB VV. ESX 4.1 or later has improved the way it performs metadata locking, meaning that you can now create a VV that is as large as you are comfortable with. For ESX 4.0 and prior, in order to minimize the impact of SCSI reservations and keep the environment well balanced, it is best to create 500 GB volumes (thin provisioned or “thick” provisioned).

Q: How many VMs can be put on a single Virtual Volume (VV)?
A: It depends. There is no one answer that will work for every situation. A number of factors such as server hardware, number of CPUs, amount of memory, type of VMs, applications running in the VMs, etc. will determine how many VMs can be comfortably hosted on a LUN.

Q: What type of path policy (Fixed, MRU, Round Robin) should be used with HP 3PAR Storage Systems?
A: With ESX 3.5, use the default policy (Fixed). With ESX 4.0 and later, change the default policy to the Round Robin path policy. To do this, log in to the service console for each ESX 4.0 host and run the following command line:
esxcli nmp satp setdefaultpsp –satp VMW_SATP_DEFAULT_AA –psp VMW_PSP_RR
For vSphere 5 you can change the path selection algorithm using the Manage Paths dialog box either from the Datastores or Devices view or from the command line on each host:
esxcli storage nmp satp set –satp=VMW_SATP_DEFAULT_AA –default-psp=VMW_PSP_RR

Q: VMware supports thin VMs. Which thin provisioning should be used: VMware, HP 3PAR, or both?
A: VMware thin provisioning only applies to VMs at the VMFS level. It allows one to over-allocate VMs to maximize VMFS usage. If the goal is to reduce storage costs and maximize storage utilization, then use HP 3PAR Thin Provisioning Software to provision large VMFS volumes with minimal upfront storage costs. There are no additional storage savings to be realized by using VMware thin provisioning. VMware thin provisioning does consume some CPU cycles on the ESX host as it is performed at the software layer (as compared to HP 3PAR Thin Provisioning Software, which is performed on the array). It is perfectly fine to place VMware thin VMs on HP 3PAR Thin Provisioning Software volumes so long as you are prepared to manage thin provisioning at both the VMware level and the array level.

Q: Is the UNMAP primitive of VAAI supported across the board?
A: No, UNMAP is not supported prior to vSphere 5.0 with InForm OS 3.1.1.

Q: When do I need to install the VAAI plug-in?
A:

·         VAAI is not supported on HP 3PAR InForm OS 2.3.1 MU1 or earlier.

·         On vSphere 4.1, the VAAI 1.1 plug-in is required.

·         When running vSphere 5.0 with HP 3PAR InForm OS 2.31, the 3PAR VAAI 2.2 plug-in is required.

·         For vSphere 5.0 with HP 3PAR InForm OS 3.1.1 or higher, no plug-in is needed as all of the VAAI primitives are supported natively.