VM /ETC

Archive for the ‘netapp’ Category

For my project, 5 TB of raw disk space on a NetApp FAS3020 resulted in roughly 2.5 TB of usable NFS volumes. Sacrificing half the storage as overhead (for both ESX and NetApp) might seem like a big hit to take at first, but when you consider what you are able to do in the remaining useable space it can change your opinion. In my recent experience, after combining the features of Flexclones, VirtualCenter (VC) templates, deduplication, and NFS the remaining 2.5 TB enabled a virtual desktop infrastructure (VDI) storage solution for over 80 virtual machines (VMs). Your results may vary, but the concepts discussed in this post provide for a scalable and flexible design.

Although this post discusses NetApp, I imagine any NFS filer with similar features could be used in this same fashion. I’m curious for feedback on not only this solution, but the pros and cons of other vendor’s features in a similar scenario.

Here’s a logical diagram illustrating a NFS volume strategy followed by some high level details of each volume. Read the rest of this entry »

The problem surfaced from a ESX 3.5 U2 host fiber connected (FC) to a NetApp filer. An AutoSupport email was generated (NetApp’s filer “phone home” feature) with the following information:

This AutoSupport indicates that there is a configuration issue in the FCP partner path.

Information:
============

[hostname: scsitarget.partnerPath.misconfigured:error]: FCP Partner Path Misconfigured.
[hostname: scsitarget.partnerPath.misconfigured:error]: FCP Partner Path Misconfigured – Host I/O access through a non-primary and non-optimal path was detected.

The AutoSupport email even explained what causes the misconfigured path.

This message occurs when the system detects that host I/O access to logical units (LUNs) is not through a primary path. NetApp clustered storage controllers allow access to LUNs through primary, optimized paths, and secondary, non-optimized paths.  Secondary(non-primary) paths provide access to LUNs through the partner storage controller’s FCP target ports. Under normal operating conditions, a host should not perform I/O to LUNs using a non-primary path. Access through a non-primary path should only occur when a host’s MPIO software detects a failure of all primary paths.

The mystery for me was “what caused a failure of the primary path?“. Believe it or not, Read the rest of this entry »

This will be another live blog session. Look for updates to this post every 15 minutes. I’m curious if any new best practices or insights will be mentioned that compliment the new vNetworking and vStorage pieces of the VMware VDC-OS.

Well, starting the session with the same disclaimer about the forward looking statements confirms my hopes! On the other hand, the forward statements could be new NetApp technologies. Either case would be cool!

A disclaimer before you read my notes: I have limited storage administration experience. Take my notes for what they are and understand the source (me). Help me out if I state something wrong.

This talk will be primarily on the NFS storage protocol. “NFS might be the best kept secret for virtualization”. To support this claim the speaker is talking about areas to consider when comparing storage protocols. Performance, Ease of Management, and High Availability are the main categories to consider. Read the rest of this entry »

This post is a supporting post to the discussion earlier this week sparked by Scott Lowe’s tip on avoiding ESX snapshots when using SAN device snapshots. NetApp’s SnapManager for Virtual Infrastructure (SMVI) is discussed as a solution for streamlining the coordination of snapshots between ESX and the SAN. Luckily, Nick Triantos from NetApp joined the discussion on Scott’s blog with some “under the hood” information: Read the rest of this entry »

Avoiding storage array snapshot pitfalls in a VMware environment is an article and tip published by Scott Lowe for Searchvmware.com. Scott discusses the design challenges and implications of combining the snapshot abilities of VMware ESX with the SAN based snapshot features of storage devices. The tip points out that incorrect configuration of VMware ESX with the storage device could lead to inconsistent and unusable images when trying to recover VMs.

“Because these snapshots are not, by default, integrated in any way with VMware ESX Server, we have to perform a few extra steps to ensure consistently reliable and usable storage array snapshots.”

Read all of Scott’s tip at the link to the article above.

My “2 cents” on this is that trying to configure the combination of the two snapshots manually might not Read the rest of this entry »

When planning P2V migrations there is always a handful of servers that have huge disk requirements. A network file share could be as large as several terabytes. User Home Directories can also cause large, cumbersome servers that present unique challenges when migrating to virtual infrastructure. Given that VMware VI3 has a 2 TB VMFS volume limitation as well as a 2 TB .vmdk limitation, there is a better option. Consolidate your shares to a Read the rest of this entry »

Another “ton of bricks” moment happened to me when I was talking about SAN replication with NetApp yesterday in the Solutions Exchange. Using your WAN, NetApp’s products can replicate block level data between each other, or they can replicate the data from your existing SAN.

So, this means that I can buy a single NetApp product and put it at my DR site and start replicating my VI for fail-over. I don’t even need to worry about building the ESX infrastructure right away. Although, the ability to test my DR fail-over requires I have ESX servers at my secondary site.

I asked for general pricing for a small office SAN. I guestimated about 3TB of data would be needed. Although they wouldn’t give me a firm quote I was told pricing should be somewhere in the $10k – $15K range.