Storage

You are currently browsing articles tagged Storage.

Fate, Free Will, Virtualization, and Storage

Tuesday, November 1, 2011 in Storage, Virtualization by slowe | 11 comments

You might wonder what fate and free will have to do with virtualization and storage. The title of this post is a reference to the debate of Fate vs. Free Will, which in turn is a reference to Stephen Foskett’s recent post VMware as Oedipus: How Server Virtualization will Change Storage Forever. I won’t provide all the details here (go read the post), but the basic idea behind the post is that VMware’s drive to add storage features to the virtualization stack puts it on a collision course with EMC, a leading storage vendor. The twist here is the fact that EMC has a majority ownership in VMware, thereby earning EMC the term “parent company” and creating the Oedipal conflict to which Stephen alludes in his post.

First, let me sum up Stephen’s points:

  1. VMware is causing users not to purchase storage arrays.
  2. VMware integration is “leveling” the playing field.

Let’s take a look at each of these points.

A Decrease in Shared Storage?

Stephen makes this statement in his article (emphasis his):

VMware is rapidly innovating in this area. Integrating and developing snapshot, replication, thin provisioning, and other features in VMFS enables everyone to have advanced storage functionality, regardless of which storage device they use. In this way, VMware is already causing many users to forego an enterprise storage array purchase.

Perhaps it’s the specific term “enterprise storage array,” but I have a hard time believing that the adoption of VMware is causing users to forgo array purchases. Think about it: to even use many of the advanced features of vSphere like vSphere HA, vSphere DRS, or vSphere FT, shared storage is a prerequisite. Users literally cannot use these features without shared storage, and—today, at least—shared storage in almost all cases means an array.

If, however, the statement is intended to say that VMware users are buying less feature-rich arrays because of the features being added into vSphere—features like snapshots, replication, and thin provisioning—then I suppose I can see that. This is why array vendors are (or should be) driving innovation in other areas, such as dynamic auto-tiering, more robust snapshotting functionality, higher availability, and higher levels of performance.

Additionally, this is an opportunity for both virtualization experts and storage experts to help customers understand the differences between the features provided by the hypervisor and features provided at the storage layer. While these features share names, they can be very different! Here are a couple specific examples:

  • VMware’s snapshots are fundamentally and dramatically different from the snapshot features offered by many storage vendors. Not only are they different in how they work, they are also different in their uses and usage patterns. Storage administrators use array-based snapshots for different purposes and in different ways than vSphere administrators use snapshots.
  • vSphere’s replication functionality is a nice “check box” item, but lacks many of the features that array-based replication offers. For example, there’s no compression, no deduplication or WAN optimization, and no idea of consistency groups.

As you can see, while it’s true that VMware is offering features that are similar in name and purpose, these features often are not true competitors to the features that storage array vendors offer, EMC included. Looking ahead, I anticipate that will continue to be the case, and storage vendors will continue to have ample opportunities to offer functionality above and beyond what the hypervisor can or will offer.

Homogenization of Storage?

The second point of the article is the assertion that “ever tighter integration serves to anonymize and homogenize enterprise storage devices.” I don’t agree here, for a couple of reasons:

  1. This statement assumes that all integration is the same, which is not the case. One vendor’s level and type of integration with VMware can be very different than another vendor’s level and type of integration. A vCenter plug-in is not the end of the story. What about integration with your replication solution? What about integration with your snapshot functionality? What about the quality of your VAAI implementation? One vendor’s implementation of VAAI might behave quite differently than another vendor’s implementation. What about your support of VMware’s multipathing APIs? I could go on and on, but you get the idea.
  2. This statement excludes the value of innovation in other areas, implying that VMware integration is the sole factor that levels the playing field. As I’ve stated on many occasions, every storage solutions has its advantages and disadvantages. The way that EMC does things gives it an advantage over NetApp in some areas; at the same time, the way that NetApp does things gives it an advantage over EMC in other areas. If all arrays were the same and were measured only on their VMware integration, then I could see this statement. That’s not the case. And even if it were, then as I’ve just shown you, VMware integration can take many forms and many levels. Despite ever increasing levels of integration, vendors still have plenty of opportunities to differentiate themselves from other vendors through price, performance, data protection, scalability, reliability, and availability.

Conclusion

I don’t disagree that VMware will change the nature of enterprise storage; in fact, I would argue that it already has changed enterprise storage. But to say that VMware will completely anonymize and homogenize enterprise storage is, in my humble opinion, a bit of a reach. There are still plenty of areas in which storage vendors can innovate and differentiate, both in addition to as well as in spite of VMware’s own storage-related ambitions.

Disclaimer: It’s probably well-known anyway, but it’s important to state that I do work for a storage vendor (EMC), although—as my site-wide disclaimer indicates—content here is not sponsored by, reviewed by, or even approved by my employer.

Tags: , , ,

Updated Stretched Cluster Presentation

Monday, October 3, 2011 in Networking, Storage, Virtualization by slowe | 5 comments

Last week I had the opportunity to speak to the Toronto VMUG and present an updated version of my talk on considerations for building stretched vSphere clusters. Stretched clusters are a topic I’ve touched on several times, first in Denver in June 2010, again this past May in Charlotte, and finally in Toronto last week. Last week’s presentation, embedded below, includes new and updated content for vSphere 5.

As usual, feel free to speak up with any comments, suggestions, clarifications, or corrections. Thanks, and I hope you find this useful!

Tags: , , , ,

Technology Short Take #15

Monday, October 3, 2011 in Networking, Storage, Virtualization by slowe | 4 comments

Welcome to Technology Short Take #15, the latest in my irregular series of posts on various articles and links on networking, servers, storage, and virtualization—everything a growing data center engineer needs!

Networking

My thoughts this time around are pretty heavily focused on VXLAN, which continues to get lots of attention. I talked about posting a dissection of VXLAN, but I have failed miserably; fortunately, other people smarter than me have stepped up to the plate. Here are a few VXLAN-related posts and articles I’ve found over the last couple of weeks:

  • There is a three-part series over at Coding Relic that does a great job of explaining VXLAN, the components of VXLAN, and how it works. Here are the links to the series: part 1, part 2, and part 3. One note of clarification: in part 3 of the series, Denny talks about a VTEP gateway. Right now, the VTEP gateway is the server itself; anytime a packet on a VXLAN-enabled network leaves the physical server to go to a different physical server, it will be VXLAN-encapsulated. It won’t be decapsulated until it hits the destination VTEP (the ESXi server hosting the destination VM). If (when?) VXLAN awareness hits physical switches, then the possibility of a VTEP gateway existing outside the server exists. Personally, it kind of makes sense—to me, at least—to build VTEP gateway functionality into vShield Edge.
  • Some people aren’t quite so enamored with VXLAN; one such individual is Greg Ferro. I respect Greg a great deal, so it was interesting to me to read his article on why VXLAN is “full of fail”. Some of his comments are only slightly related to VXLAN (the rant over IEEE vs. IETF, for example), but Greg’s comment about VMware building a new standard instead of “leveraging the value of networking infrastructure” echoes some of my own thoughts. I understand that VXLAN accomplishes things that existing standards apparently do not, but was a new standard really necessary?
  • Omar Sultan of Cisco took the time to compile some questions and answers about VXLAN. One thing that is made more clear—for me, at least—in Omar’s post is the fact that VXLAN doesn’t address connectivity to the vApps from the “outside” world. While VXLAN provides a logical isolated network segment that can span multiple Layer 3 networks and allow applications to communicate with each other, VXLAN doesn’t address the Layer 3 addressing that must exist outside the VXLAN tunnel. In fact, in my discussions with some of the IETF draft authors at VMworld, they indicated that VXLAN would require a NAT device or a DNS update in order to address changes in externally-accessible applications. This, by the way, is why you’ll still need technologies like OTV and LISP (or their equivalents); see this post for more information on how VXLAN, OTV, and LISP are complementary. If I’m wrong, please feel free to correct me.
  • In case you’re still unclear about the key problem that VXLAN attempts to address, this quote from Ivan Pepelnjak might help (the full article is here):

    VXLAN tries to solve a very specific IaaS infrastructure problem: replace VLANs with something that might scale better. In a massive multi-tenant data center having thousands of customers, each one asking for multiple isolated IP subnets, you quickly run out of VLANs.

  • Finally, you might find this PDF helpful. Ignore the first 13 slides or so; they’re marketing fluff, to be honest. However, the remainder of the slides have some useful information on VXLAN and how it’s expected to be implemented.

Servers

I didn’t really stumble across anything strictly server hardware-related; either I’m just not plugged into the right resources (anyone want to make some recommendations?) or it was just a quiet period. I’ll assume it was the former.

Storage

Virtualization

  • Did you see this post about new network simulation functionality in VMware Workstation 8?
  • Here’s a good walk-through on setting up vMotion across multiple network interfaces.
  • VMware vSphere Design co-author Maish Saidel-Keesing has a post here on how to approximate the functionality of netstat on ESXi.
  • William Lam has a “how to” on installing the VMware VSA with running VMs.
  • Fellow vSpecialist Andre Leibovici did a write-up on a proof of concept that the vSpecialists did for a customer involving Vblock, VPLEX, and VDI. This was a pretty cool use case, in my opinion, and worth having a look if you need to design a highly available environment.
  • Thinking about playing with vShield 5? That’s a good idea, but check here to learn from the mistakes of others first. You’ll thank me later.
  • The question of defragmenting guest OS disks has come up again and again; here’s the latest take from Cormac Hogan of VMware. He makes some great points, but I suspect that this question is still far from settled.

It’s time to wrap up now; I hope that you found something useful. As always, thanks for reading! Feel free to share your views or thoughts in the comments below.

Tags: , , , , , , , , ,

Exclusion or Not?

Tuesday, September 20, 2011 in Storage, Virtualization by slowe | 11 comments

A couple days ago I read Stephen Foskett’s article “Alas, VMware, Whither HDS?”, and I felt like I really needed to respond to this growing belief—stated in Stephen’s article and in the sources to his article—that VMware is, for whatever reason, somehow excluding certain storage vendors from future virtualization-storage integration development. From my perspective, this is just bogus.

As far as I can tell, Stephen’s post—which is just one of several I’ve seen on this subject—is based on two sources: my session blog of VSP3205 and an article by The Register. I wrote the session blog, I sat in the session, and I listened to the presenters. Never once did one of the presenters indicate that the five technology partners that participated in this particular demonstration were the only technology partners with whom they would work moving forward, and my session blog certainly doesn’t state—or even imply—that VMware will only work with a limited subset of storage vendors. In fact, the thought that other storage vendors would be excluded never even crossed my mind until the appearance of The Register’s post. That invalidates my VSP3205 session blog as a credible source for the assertion that VMware would be working with only certain storage companies for this initiative.

The article at The Register cites my session blog and a post by Wikibon analyst David Floyer as a source. I’ve already shown how my blog doesn’t support the claim that some vendors will be excluded, but what about the other source? The Wikibon article states this:

Wikibon understands that VMware plans to work with the normal storage partners (Dell, EMC, Hewlett Packard, IBM, and NetApp) to provide APIs to help these traditional storage vendors add value, for example by optimizing the placement of storage on the disks.

This statement, however, is not an indication that VMware will work only with the listed storage vendors. (Floyer does not, by the way, cite any sources for that statement.)

Considering all this information, the only place that is implying VMware will limit the storage vendors with whom they will work is Chris Mellor at The Register. However, even Chris’ article quotes a VMware spokesperson who says:

“Note that we’re still in early days on this and none of the partners above have yet committed to support the APIs – and while it is our intent to make the APIs open, currently that is not the case given that what was demo’d during this VMworld session is still preview technology.”

In other words, just because HDS or any other vendor didn’t participate (which might indicate that the vendor chose not to participate) does not mean that they are somehow excluded from future inclusion in the development of this proposed new storage architecture. In fact, participation—or lack thereof—at this stage really means nothing, in my opinion. If this proposed storage architecture gets its feet under it and starts to run, then I’m confident VMware will allow any willing storage vendor to participate. In fact, it would be detrimental to VMware to not allow any willing storage partner to participate.

However, it gets more attention if you proclaim that a particular storage vendor was excluded; hence, the title (and subtitle) that The Register used. I have a feeling the reality is probably quite different than the picture painted in some of these articles.

Tags: , , , , , , ,

Determining an Optimal Design

Monday, September 19, 2011 in Storage, Virtualization by slowe | 7 comments

I had an interesting e-mail conversation last week with fellow EMC vSpecialist Clint Kitson. Now, if you’ve never met Clint, he’s a super-sharp fellow, no questions about it. I love conversations with super-sharp folks as they invariably lead to new thoughts and new ideas, and this conversation was no different. The topic of the conversation, in generalized terms, was this: when crafting designs for customers, what defines an “optimal design”?

Allow me to share a few details from our conversation, and perhaps that question will make a bit more sense. Clint and I were discussing storage array designs and the various types of utilization that exist within a storage array. In this particular case, we were discussing a scenario in which an array—any type of array, not just an EMC array—could be configured in one of two ways:

  1. You could configure the array with fewer drives than the storage controllers are actually capable of driving. Thus, there is a certain amount of storage controller capacity left unused, even if all the drives are fully utilized.
  2. You could configure the array with more drives than the storage controllers are capable of driving. Thus, even if the storage controllers are fully utilized, there are some unused drive resources (IOPS and capacity, but mostly IOPS) left unused.

In either configuration, there is a resource (either storage controller capacity or drive capacity in IOPS) that is not fully utilized. So what’s the optimal design in this sort of scenario? Either way, something is going to be under-utilized.

If you think about it, this same question could be asked of a VMware vSphere design. In almost every vSphere design, there is at least one resource that is not fully utilized. So what is an optimal design? Which resource should be left under-utilized? How does an architect—be it a storage architect creating storage array configurations or a virtualization architect creating virtualized infrastructure designs—determine which resources should be left under-utilized in order to create an optimal design?

If you attended my VMworld session (VSP1926), you probably already know what I think the answer is: functional requirements. Which approach best satisfies the customer’s functional requirements? In the example that Clint and I were discussing, which approach will best meet the customer’s needs and requirements?

“But Scott,” you say, “either approach could satisfy the functional requirements.”

That might be true (it’s hard to say here since we were discussing this in a very abstract sort of way), but I’m almost certain that in every one of these situations one approach is more cost-effective than the others, and every project I’ve ever seen has a financial functional requirement (more commonly referred to as a “budget”). Can you still say all approaches meet the functional requirements equally?

This is a bit of an academic discussion, but an interesting one (in my mind, at least). What do you think? Share your thoughts, rants, and ideas in the comments below.

Tags: , , ,

The End of the Infrastructure Engineer?

Wednesday, September 14, 2011 in Networking, Storage, Virtualization by slowe | 50 comments

Is the age of the infrastructure engineer over? While I was at VMworld 2011, I listened to a speaker talk about how people like me—people who are conversant in virtualization, networking, storage, servers, and data center hardware—are going to have to evolve/migrate into the application development space in order to survive in the “new cloud world” (my phrase, not the speaker’s). This speaker isn’t the only one, either. This started me thinking. Are infrastructure engineers really a relic of the past, like punch cards?

I think we can all agree that the heavily-specialized infrastructure teams of the past—the networking team, the server team, the storage team—are no longer sufficient in the brave new world of converged infrastructure that blends networking, virtualization, and storage all together. I’d agree, in general terms, that IT infrastructure folks need to broaden beyond their core strengths into adjacent technologies in order to remain relevant. Storage engineers need to learn some networking and some virtualization. Virtualization engineers absolutely need to know storage, and networking is becoming a necessity as well. Networking engineers need to embrace virtualization and understand the impact of storage on their networks. Whether or not the silos ever come down fully or whether we’ll just “install sliding partitions,” as one colleague of mine said, isn’t yet clear. It is clear, though, that some blurring of the lines between these teams is a given.

Is it a given, though, that infrastructure engineers have to move up the stack into the application layer(s)? From an awareness perspective—meaning becoming more aware of the applications running on their infrastructure—I’d agree. Application development, though? That one I’m not so sure about. Yes, it will be/is helpful to understand what goes into application development and the infrastructure dependencies that are the result of the development choices. Again, that’s awareness, and yes—infrastructure engineers need enhanced awareness of adjacent technologies and the relationships with their core technology strengths. Awareness, though, is fundamentally different than being well-versed in application development.

Maybe I’m just being naive or ignorant, but regardless of how many layers of abstraction are inserted into the stack—and virtualization, in its simplest form, is another layer of abstraction—someone still has to manage the infrastructure. OK, so you’ve built a “private cloud” and you have highly virtualized infrastructure, pooled resources, self-service provisioning, etc. Someone still has to manage it. Someone still has to ensure that there is sufficient capacity, and that someone needs to understand the core technologies that make the private cloud tick. If we’re all moving “up the stack,” who’s left behind to manage the infrastructure?

This is why I’m not yet convinced that the age of the infrastructure engineer is over. Even if you have virtualized your servers, virtualized your network, and virtualized your storage, management of this infrastructure is still necessary. People who understand this infrastructure—both virtual and physical—are still necessary. Engineers who know the relationships among the virtualization layers and the various technologies are still necessary. Yes, the infrastructure engineer will change, grow, and evolve, but I think that the death of the infrastructure engineer is greatly exaggerated. We can’t all move up the stack into application development; someone has to stay behind and make sure everything runs the way it’s expected to run.

What do you think? Speak up and share your thoughts in the comments.

Tags: , ,

Technology Short Take #14

Monday, September 12, 2011 in Networking, Storage, Virtualization by slowe | No comments

Welcome to Technology Short Take #14, another collection of links and tidbits of information I’ve gathered over the last few weeks. Let’s dive right in!

Networking

Much of my focus in the networking space recently has been around virtualization-centric initiatives, so the items on this list might seem a bit skewed in that direction. Sorry!

  • I’ve been doing some reading on 802.1Qbg (Edge Virtual Bridging). I still have a long way to go, but I think that I’m starting to better understand this draft and the problem(s) it’s attempting to address. As usual when I’m dealing with networking-related technologies, especially data center-focused networking technologies, I’m finding some of Ivan Pepelnjak’s articles useful. For example, he wrote an article on how EVB should ease VLAN configuration pains; this article is helpful in translating the terms the IEEE uses (like “virtual station interface” and “EVB station”) into terms virtualization-friendly folks like me can understand (like “vNIC” and “Hypervisor supporting EVB”, respectively). Ivan also provides a rough comparison of 802.1Qbh/FEX and 802.1Qbg, which I also found helpful in better understanding both technologies. There is still much that I want/need to understand, such as how 802.1Qbg affects or is affected by VXLAN, the recent darling of the cloud networking space.
  • Speaking of VXLAN, a number of articles have emerged since the announcement of VXLAN last week at VMworld 2011 in Las Vegas. Jon Oltsik of Network World called it “Cloud Network Segmentation at Layer 2.5″, which is catchy but doesn’t really delve into the details of VXLAN and how it plays into/with related data center protocols. Of course, there’s also the obligatory VMware post on the technology, talking about how great it is—naturally—but failing to again provide substantive information on the relationships between VXLAN and other, related data center technologies. If anything, Allwyn’s post made VXLAN seem even more proprietary and linked to vCloud Director and vShield Edge than I’d understood it to be. Fortunately, Ivan weighed in on the proposed new standard and also provided some information on the relationship between VXLAN, OTV, and LISP. I’m still digging into VXLAN myself and I plan to post an article within the next week or so (I’ve been a bit busy with moving halfway across the United States).
  • Ivan also has a post with more details on the Brocade VCS fabric load-balancing behaviors that’s worth having a look.

Servers

  • This article on AES-NI in the newer Intel CPUs is a great look at the benefits of adding symmetric encryption support at the CPU level. Almost makes me want to go out and buy a new MacBook Pro so that I could use File Vault 2 with hardware encryption support…

Storage

  • One cool find recently is this series of “hands-on” posts by Henri Hamalainen (aka @henriwithani) on the EMC VNXe 3300. I had the pleasure of meeting Henri in person at VMworld this year, and he mentioned that he’d started a series of posts on the VNXe 3300. His posts are here: part 1, part 2, part 3, part 4, part 5, and part 6. (Part 7 hasn’t yet been written.)
  • There’s been quite a hubbub going on in the FCoE space, with so many articles flashing back and forth from various contributors I’m still having a hard time deciphering all of it. From what I can tell, it all started with an article by a VP at Juniper about FCoE over TRILL. That sparked Ivan Pepelnjak to coin some new terms: “dense-mode FCoE” (in which FCFs exist at every hop) and “sparse-mode FCoE” (in which LAN switches may forward FCoE frames without any FCoE awareness). That, in turn, sparked an article by Tony Bourke in which he creates more new modes of operation: single hop FCoE (SHFCoE), dense-mode FCoE (DMFCoE), and sparse-mode FCoE (SMFCoE). A fantastic (and very informative) discussion ensued in the comments to that article and the follow-up article. Ivan also responded to Tony’s post as well with a post on FCoE network elements classification. I’m not sure that all the contributors ever came to a consensus, but you’ll learn a lot about FCoE and related technologies just following along, that’s for sure.
  • By the way, this transcript of questions and answers from a live FCoE webcast has some great information buried in it as well.
  • This is an older article, but Stephen Foskett does a good job with discussing FCoE vs. iSCSI. Like so many other IT-related decisions, it’s not an “either-or” discussion—it’s about finding the right tool to do the job.
  • This article provides one suggestion for handling zoning with multiple storage arrays, and provides some good information on EMC CLARiiON/VNX arrays in the process.

Virtualization

  • The idea of stretched clusters and interconnecting data centers continues to be an idea many people are interested in exploring. Rawley Burbridge, of IBM, discusses how this might be done using IBM SVC and VMware vSphere in this three-part series (part 1, part 2, and part 3).
  • Kendrick Coleman, in conjunction with a collection of folks from both VMware and VCE, recently published an article on design considerations for vCloud Director on a Vblock. I haven’t yet read the full document, primarily because it appears to require a Facebook login in order to download. (I don’t use Facebook.)
  • Andre Leibovici—who I had the pleasure of meeting in person at VMworld—has an article on how to modify the Windows Registry settings (or apply Group Policy) for the VMware View Client in order to integrate self-service password reset.
  • The VMware vCloud Architecture Toolkit (vCAT) version 2.0 is now available; get it here (via Beaker).
  • Forbes Guthrie—the lead author with whom I worked on VMware vSphere Design, published earlier this year—posted some great 10Gb Ethernet-related information from VMworld session SPO3040.
  • This is a slightly older post from Hany Michael, but a good one nevertheless; he posts information on how to publish the vCloud Director portal on the Internet.

I guess that will wrap things up for this time around. Thanks for reading, and I hope that you found something useful in this varied mix of links. Feel free to share more in the comments below!

Tags: , , , , ,

Technology Short Take #13

Thursday, August 25, 2011 in Networking, Storage, Virtualization by slowe | 1 comment

Welcome to Technology Short Take #13. It’s been a while since my last Technology Short Take, and much has happened (vSphere 5 was announced, HP discontinued the TouchPad and webOS, and I announced my move to Denver). Here are a few data center technology-related links that stood out to me over the last few weeks. I hope you find something useful!

Networking

Servers

Storage

  • Sometimes it seems like people don’t fully understand the level of compatibility between FC and FCoE. This post by Vijay Swami provides a good review of the impact of FCoE on the average storage administrator—in most cases, no impact at all.
  • Erik Smith has a good review of the FC/FCoE connectivity options for EMC storage platforms in this post. It’s worth taking a quick look if you are interested in more detail on what sort of FCoE connectivity options are supported.
  • On the flip side, here’s information from Cisco on storage interoperability with UCS.
  • This two-part series by Itzik Reich on Citrix XenDesktop 5 with EMC VNX and FAST Cache is a good read, especially if you are considering XenDesktop for your VDI environment. Part 1 is here, and part 2 is here.
  • Here’s another look at the impact of FAST Cache on VDI workloads.

Virtualization

  • This post on application consolidation by Scott Drummonds is an old post (from January 2010), but it’s still a good one. In this post, Scott shares data from tests assessing the impact of consolidating sequential access workloads with random access workloads on the same datastore. The results of the tests underscore the importance of knowing the I/O profile of your workloads.
  • Here’s a workaround for using static MAC addresses that fall outside the normal range that vSphere allows.
  • Cormac Hogan has a great series of blog posts on new storage features in vSphere 5. Part 1 covers VMFS-5, part 2 discusses Storage vMotion, part 3 covers VAAI, and so forth. This is definitely worth reading. Of course, there is this vSphere 5 book slated to come out in early October that will discuss all these features, too…
  • I have a whole collection of posts by William Lam; he’s been on a roll: a summary of the updates to esxcli, information on enabling support for nested 64-bit and Hyper-V VMs, and information on enabling nested Fault Tolerance.

Security

  • I came across this article on how to protect Hyper-V hosts against ARP spoofing. Unless I’m mistaken—and that’s certainly very possible—I don’t think that the vSwitch/distributed vSwitch security policies around MAC address changes and forged transmits protect against ARP spoofing. Anyone have any additional information on how a VMware vSphere shop would protect against ARP spoofing? Is it even necessary?
  • Harley Stagner has a pretty good write-up of the Nexus 1000V Virtual Security Gateway (VSG). The VSG—and the Nexus 1000V, for that matter—are products in which I’m very interested, but just haven’t had the time to really spend with them. Perhaps in the future!

It’s time to wrap up now, but thanks for reading. Feel free to share any other interesting or useful links you’ve found, or any thoughts on the links I included here, in the comments.

Tags: , ,

Looking Again at VASA

Thursday, August 25, 2011 in Storage, Virtualization by slowe | 3 comments

In early August, I wrote a post titled A Deeper Look at VASA, in which I provided some additional details on how VASA (the vSphere Storage APIs for Storage Awareness) worked and some of the potential limitations of the initial VASA implementation in vSphere 5. My original post was not intended to slam VASA; rather, my goal was to provide some additional information about how VASA works so that users can appropriately understand how best to incorporate this functionality into their environments.

Since that article was published, Cormac Hogan of VMware has published an article on the VMware vSphere blog that contains a “sneak peek” at some of the VASA implementations from various storage vendors. Now that we’ve had the ability to see how the various storage vendors are implementing VASA, I’d like to go back and look at the information about VASA in light of this new information.

In my first VASA post, I explained that the VASA protocol specification allows the storage provider to pass up only a single system-provided capability, and I outlined three different options for how storage vendors might use this functionality. Based on the information in Cormac’s post (which I highly recommend you read), it would appear that a couple of the storage vendors have chosen to embed multiple attributes (RAID, disk type, snapshots, etc.) in the name of the system-provided capability. For example, Cormac’s article shows that Dell EqualLogic will use system-provided capabilities like “RAID, SNAP” or “RAID, SNAP, REPLICATED”. This is a perfectly acceptable use of the system-provided capability, as I outlined in my previous article. The only drawback—and this isn’t really a drawback as much as an observation—is that the overall list of potential system-provided capabilities can grow very long as more individual attributes are added to the name.

Similarly, NetApp has chosen to include specific storage attributes in the name of the system-provided capabilities, creating capabilities like “Fiber Channel Disks; Dedupe” and “SATA Disks; Dedupe; Replication”. Again, a perfectly acceptable workaround for the “one system-provided capability per datastore” limitation found in the VASA protocol specification.

Based on Cormac’s article, it sounds like HP’s VASA implementation will be very similar.

What about EMC’s VASA implementation? I know what it will look like, but I haven’t gotten approval to share that with anyone publicly yet, so I’ll have to defer on any comments regarding EMC’s VASA implementation. EMC does have a working VASA implementation and will provide VASA support, as outlined in Cormac’s article.

So, based on this information and seeing how the vendors are “bypassing” the protocol limitation by overloading the system-provided capability name string, it would seem to me that there isn’t really a strong limitation here. Personally, I would still recommend to VMware to stop using the term “capability” and find some other term, as I think that it leads users to believe VASA is something other than what it is (something more granular). I also think that VASA has a lot of room to grow and become more powerful in future releases, and I’m looking forward to seeing how this functionality evolves.

What do you think? Do these VASA implementations look useful? What part of VASA (and profile-driven storage) do you think will be most useful to you in your specific environment? I’d love to hear what you think, so feel free to speak up in the comments below.

Tags: , , ,

A Deeper Look at VASA

Friday, August 12, 2011 in Storage, Virtualization by slowe | 13 comments

Much has been said and written about VASA (the vSphere APIs for Storage Awareness), a key part of vSphere 5 and the “magic” behind the new profile-driven storage functionality. I recently had the opportunity to dive a bit deeper into VASA, and discovered some information that I felt was important to share with the virtualization community. This post probably won’t earn me any brownie points at VMware, but at least we’ll all have a better idea of what VASA can and cannot do.

The basic premise of VASA is that something called the VASA provider (also referred to as a storage provider in the vSphere Client UI) supplies something called capabilities about datastores. It is widely believed that for each datastore the VASA provider will pass up multiple capabilities like deduplication, replication, snapshot status, RAID level, drive type, or performance (IOps/MBps) capacities. vSphere administrators could then use some arbitrary combination of these capabilities to create a VM storage profile. VM storage profiles can then help determine which datastores are compatible (support the necessary capabilities) or incompatible (don’t support the required capabilities) when creating new VMDKs, performing Storage vMotion operations, cloning a VM, or deploying a VM from a template.

This sounds pretty cool, right? Unfortunately, that’s not how VASA works.

The VASA protocol actually limits the storage provider to supplying (or assigning) only one capability to each datastore. That’s right—each datastore can have only one capability provided by the VASA provider (a capability assigned by the storage provider is also referred to as a system-provided capability). So instead of VASA providing up individual attributes like RAID level, drive type, etc., and allowing vSphere administrators to build VM storage profiles from these attributes, the VASA provider must supply a single “meta-attribute” that is a sum of the various configuration options. This means you’ll see system-provided capabilities like:

  • A concatenation of various attributes lumped together in a single label, like “RAID 5;Thin;Deduplicated;SAS/FC Drives”
  • A generic but descriptive label, like “High Performance”
  • A fully generic label such as “Gold” or “Silver”

<aside>At this point it should be fairly obvious that the use of the word “capability” in the manner that VASA and profile-driven storage use it is horribly misleading. “Label,” as I’ve used above, is far more accurate.</aside>

The VASA provider will then assign one of these system-provided capabilities to the datastore. vSphere administrators have the option of applying one user-defined capability to a datastore as well. This means that, at most, any given datastore may have a maximum of two capabilities: one system-provided and one user-defined.

Because your datastores may have no more than two capabilities assigned, your VM storage profiles can also have no more than two capabilities selected. Think about it—if you select three capabilities (which the UI will let you do), all datastores will be found incompatible because none of them have all three capabilities.

This behavior is a far cry from what many people expected and believed VASA would do, myself included. I expected VASA to be far more powerful and far more flexible than it is, and I would imagine that a fairly significant number of readers were under the same impression.

I’d love to hear from the readers. What were your impressions of what VASA would deliver, and how do they compare to the reality? Feel free to share your thoughts in the comments below.

Tags: , , ,

« Older entries § Newer entries »