August 2011

You are currently browsing the monthly archive for August 2011.

A Couple Vendor Meetings at VMworld 2011

Wednesday, August 31, 2011 in Networking, Security, Virtualization by slowe | 3 comments

Over the last couple of days at VMworld, I’ve had the opportunity to meet up with a couple of vendors to discuss their product initiatives and offerings. I had lined up several more meetings, but due to my hectic schedule I was unable to make those meetings. To those companies that I missed, I apologize. There just aren’t enough hours in the day!

Bluesocket

One company that I met with is Bluesocket, whose link to VMware is through their vWLAN (virtual wireless LAN) product. What is a vWLAN, exactly? Don’t worry, I asked the same question; it sounded like bad marketing, to be honest. vWLAN is the name they use to describe a wireless network architecture that combines wireless APs with a fully virtualized wireless AP controller. Bluesocket has taken their wireless network architecture and built it in such a way that they’ve combined the traits of a “fat AP” and “thin AP” approach together, and leveraged virtualization on vSphere to provide the compute power. It’s an interesting approach, but—as I expressed to Bluesocket—I’m not sure how well it will hold off the bigger, more well-funded competitors in the wireless LAN space. For now, at least, Bluesocket has a first mover’s advantage.

HyTrust

HyTrust is a company I’ve written about before (just do a Google search for “HyTrust site:scottlowe.org”). HyTrust is in a very interesting space and doing some pretty cool things. I learned today, for example, that not only does HyTrust provide support for VMware vSphere and the Cisco Nexus 1000V, but also Cisco UCS. That’s pretty cool! If you are looking for some ways to enhance the security profile of your virtualized environment, it might be worthwhile for you to take a look at HyTrust.

Well, that’s it for now. I’ll have more VMworld 2011 coverage tomorrow.

Tags: , , , ,

VSP2117: Virtualization-Aware Datacenter Networks

Wednesday, August 31, 2011 in Networking, Virtualization by slowe | 1 comment

This is a session blog for VSP 2117, titled Virtualization-Aware Datacenter Networks. The presenter is Milin Desai, Group Product Manager for Networking at VMware. This is the session where I will, hopefully, get the answers I need for VXLAN.

Milin indicates that customers—he says he’s talked to over 1,000 customers—want mobility. They want planned migrations, disaster recovery, and live migrations. So how is the datacenter network going to evolve to meet these customer requirements?

  • In the future, workloads will be dynamic (“any app to any server”) and will support massive scale (more than 4,095 VLANs).
  • Services will be distributed scale-out services and will be workload-centric (programmed to the specific workload). Both policies and control plane information must travel with the workload.
  • Operations must be simplified (single interface for provisioning) and the solution must provide deterministic performance with visibility and monitoring.

Summarizing these points, the solution must be elastic and extensible, performant, and programmable.

The basis of a solution that is elastic and extensible is the vSphere Distributed Switch. A customer takes the stage to talk about how he has used vSphere Distributed Switches and the benefits his organization has seen.

VXLAN is the VMware solution that enables VMs to move across subnet boundaries. VXLAN is about improved workload mobility. VXLAN (formerly VDL2) uses a MAC-in-UDP encapsulation. It looks as if VXLAN will work between different vSphere Distributed Switches (different than what I heard at the Cisco booth yesterday), and the traffic flow across the network is unaffected.

Next Milin moves into a discussion of how to use vShield Manager to provide extensible services to third party developers. vShield Edge is VMware’s own product that leverages vShield Manager’s extensibility to provide firewall, DHCP, NAT, VPN, and load balancing services. vShield Edge supports VXLAN, but VXLAN does not address Layer 3 concerns. Milin mentions that if we have to migrate VMs, you would still have to change the vShield Edge NAT configuration and update DNS. It would appear, based on this information, that technologies such as OTV and LISP (or their equivalents) are still going to be necessary.

With regards to performance, Milin mentions Network I/O Control, and how vSphere 5.0 adds 802.1p tagging to help with the end-to-end QoS configurations. Looking ahead, how will this evolve? He discusses the use of advanced technologies like ROCE/iWarp, SR-IOV, etc. These technologies will potentially let VMware address low latency workloads (less than 50 microseconds). On the visibility front, Milin discusses such things as NetFlow, SNMP, and the use of tools like vCenter Operations. VMware is also working on technologies that will do a better job of providing automated alerts with regard to network configuration mismatches (MTUs, VLANs, etc.).

In the area of programmability, VMware is looking at “Network as a Service”—publishing network services/capabilities to workloads. Milin again uses the “barcode” example, where a VM contains the specific requirements that it needs with regard to the network connectivity. This is a concept that VMware has been discussing for quite some time but is still very early in the process of actually delivering.

At this point, Milin ends his presentation and opens the floor to questions.

Tags: , , , ,

VMworld 2011 Tuesday General Session

Tuesday, August 30, 2011 in Virtualization by slowe | No comments

This is a session blog for the Day 2 general session at VMworld 2011 in Las Vegas. Today everyone here at VMworld is looking forward to the in-depth technical discussions that typically follow after Paul Maritz’ more high-level presentation the previous day. VMware CTO, Steve Herrod, should be one of the primary if not the primary speaker today.

The session begins with some videos from various VMware employees discussing their products: vCenter Operations, vFabric and vFabric Data Director, vSphere. The ending quote: “It should just work and work well.”

Dr. Stephen Herrod, CTO of VMware, then takes the stage. Steve starts his discussion with describing the shift from thinking of individual servers and individual PCs to thinking of services (the cloud) and people (the users). Thinking about the users means thinking about all the devices that people want to use, universal access to information, and high expectations. He next goes to a video that describes how VMware is thinking about the “post-PC” era. The video is decidedly marketing-focused, but Steve follows up the discussion with a deeper look at the actual mechanics and tools used to help achieve that vision.

There are three key tasks that Steve thinks must be accomplished in order to achieve the “post-PC” era: simplify, manage, and connect.

To simplify, VMware looks to tools like VMware View and ThinApp, to make Windows desktop and Windows applications easier to use and manage. The next step is an application catalog, and data management, to keep users’ data accessible regardless of where the user is or what device the user is using. This is managed/driven by a unified service broker, and the unified service broker then provides connectivity to all the various devices that a user might use (iPad, PC, mobile phone, etc.). Steve will take a look at this architecture and the tools from the perspective of IT as well as the perspective of the end user.

The first demonstration is VMware View 5 provisioning a pool of virtual desktops using linked clones. Nothing really new or exciting here, except perhaps a look at the View 5 user interface.

The next demo is something called Project ThinApp Factory, a tool to automate the process of extracting applications out of Windows using ThinApp, and Horizon, an application portal for provisioning applications to people. The demo shows the web interface for Project ThinApp Factory being placed into Horizon’s application catalog, showing both SaaS and traditional Windows-based applications in the same application catalog. Horizon will also include mobile applications and broker access to non-VMware reesources, such as Citrix XenApp.

Steve now moves on to something called Project Octopus. Project Octopus seeks to provide corporate IT with a way of running their own Dropbox-style sevice for data management services. The demo shows a web interface for Octopus and how IT can allow a user to access this service and how IT can provide simple but reasonably secure sharing of data with external entities. Project Octopus can be delivered via both private cloud and public cloud models.

So far, Steve has shown us—from an IT administrator’s perspective—provisioning desktops, extracting applications, connecting users with applications via Horizon and connecting users with data via Project Octopus. At this point, Vittorio (Product Manager for EUC at VMware) comes on stage to show us the end-user’s perspective. He walks through using the Horizon interface to access applications, see documents, and activate his mobile phone. Vittorio demonstrates Mobile Virtualization Platform (MVP) on an LG Android phone, showing a personal phone instance and a virtual phone instance as well.

Steve takes the stage again to break down Vittorio’s demo. He points out the applications and technologies that were shown:

  • VMware View 5 with virtual profiles
  • Horizon
  • Horizon Mobile (the new name for MVP)
  • Project Octopus

Steve announces a new partnership with Samsung to provide Horizon Mobile services on their Android-powered phones. This is in addition to the partnership that VMware already has with LG. Additional partnerships are in the works.

Vittorio now takes the stage again, this time as a mobile user out of the office. In this demonstration, he’s using an iPad and SocialCast, and then starts using Project Octopus to access files on his iPad. He attempts to edit an Excel file on his iPad, which opens Mobile Safari and then runs a version of Excel inside Mobile Safari using something called AppBlast. Vittorio next does a video call to a call center, where the agent, who uses a couple of different applications to assist Vittorio. (Presumably the call center agent is using a virtual desktop on VMware View.)

So now Steve takes the stage again to break down Vittorio’s demo:

  • Project Octopus to access files from his iPad
  • Project AppBlast, which converts traditional applications being converted into HTML5 to run on any HTML5-compliant client (Windows, Linux, or Mac apps)
  • VMware View 5 was running in the call center, showing off unified communications, Aero user interface, high-speed graphics with PCoIP over a wide area network (WAN)

Steve points out that Vittorio “accidentally” forgot his mobile device; this is to illustrate that IT could wipe/delete the corporate IT managed phone instance on that device.

Steve wraps up his end-user computing discussion by re-iterating the role of Horizon as the central unified broker, bringing together technologies like VMware View, Project ThinApp Factory, Project Octopus, Horizon Mobile, and Project AppBlast. This sets the stage for him to shift the discussion to the infrastructure that supports these efforts.

Steve shows off a preview of the next version of the vSphere iPad Client, where vMotion is now enabled. I’m not so sure about the user interface—it seems a bit gimmicky—but I’m glad to see VMware continuing to push into new client markets and provide new functionality.

The next demonstration is a demo of VMware Go, a hosted virtualization service designed for the SMB market, and a demo of the vSphere Storage Appliance, a shared storage solution for the SMB market.

Steve shifts to a discussion of Auto Deploy. Auto Deploy is a PXE boot solution for ESXi hosts, and many bloggers have already discussed it in some detail. (There will also be full coverage of Auto Deploy in my upcoming vSphere 5 book.)

The next discussion is about VM scalability: 32 vCPUs, 1 TB of RAM, and up to 1,000,000 IOPs per vSphere host.

Steve shifts the discussion to more of a focus on policy-based administration, i.e., “VM contracts”. This leads Steve into a discussion of performance guarantees and storage, and that brings up three new features in vSphere 5:

  • Logical pooling of storage (datastore clusters)
  • VM placement (VM storage profiles, VASA, Storage DRS)
  • Load/usage balancing (Storage DRS)

To address more short-term storage performance concerns, vSphere offers Storage I/O Control (present in vSphere 4.1 as well). This addresses more short-term concerns while Storage DRS can address longer-term balancing. There’s also Network I/O Control, which provides similar controls at the network layer.

The mention of networking lets Steve focus a bit more on networking. Steve discusses the “identifier = location” problem, and the solution is VXLAN, which encapsulates L2 packets into L3 packets. This is intended to address the “identifier = location” problem, but is it standards-based? Why create a new VXLAN standard instead of leveraging existing solutions? VMware says that VXLAN has been created in collaboration with Cisco, Arista, Broadcom, Emulex, and Intel. The specification has been submitted to the IETF, but again I would question why they felt the need to create a new standard instead of leveraging an existing solution.

Next on stage is a discussion of Site Recovery Manager 5, which provides a DR workflow solution. Naturally, Steve brings up vSphere Replication, which provides host-based replication of VMs from one site to another site. SRM 5 also provides automated failback, and some vCloud partners are providing “DR to the cloud” solutions using SRM 5.

vShield 5 is the next topic in Steve’s talk. There are several different vShield offerings:

  • vShield Endpoint
  • vShield App
  • vShield Edge

vShield App incorporates DLP technologies (taken from RSA), which provides some additional functionality to ensure sensitive data is appropriately protected.

Steve switches now to management. Performance, availability, and security are great, but management is important and necessary, and Steve indicates that VMware has a large number of engineers currently focused on management. Steve shows off some demonstrations of new versions of various VMware management applications, like vCenter Operations.

At this point the keynote is wrapping up.

Tags: , ,

VMworld 2011 Monday General Session

Monday, August 29, 2011 in Virtualization by slowe | 4 comments

This is the session blog for the Monday general session. I’m fortunate enough to have arrived in time to get a seat at the blogger/press/analyst tables. While the network connectivity is good, the power is—unfortunately—not so good.

The general session started with an impressive lightshow across the front of the conference that depicts the change of computing with the advent of virtualization and cloud computing. It was visually appealing and interesting.

At the conclusion of the visual show, Rick Jackson, Chief Marketing Officer for VMware, takes the stage to kick off the general session. Rick indicates that there are about 19,000 people here at VMworld 2011 this week; attendance is down, understandably, due to Hurricane Irene’s effect on the East Coast of the United States and the resulting impact on air travel.

Rick indicates that the Hands-On Labs for VMworld 2011 are completely hosted on public clouds: Switch SuperNAP, Colt, and Terremark all provide public cloud services for this year’s labs. The labs are built on vSphere 5.0 and vCloud Director 1.5. Both Paul Maritz and Carl Eschenbach will be speaking later in this session; and tomorrow morning VMware CTO Steve Herrod will be doing a technology keynote to demonstrate what VMware’s working on.

Rick also confirms that VMworld 2012 will be back in San Francisco (yay!), being held from August 27 to 30, 2012. At this point, Rick introduces Paul Maritz, CEO of VMware, and gives him the stage.

Paul gives some statistics:

  • One VM being deployed every six seconds (that’s faster than babies being born in the US)
  • 20 million VMs running on VMware vSphere
  • More VMs in flight using vMotion than there are aircraft in flight
  • Greater than 800,000 vSphere administrators (that’s the population of San Francisco)
  • Greater than 68,000 VMware Certified Professionals (across 146 countries)
  • More than 1,650 ISV partners and more than 3,000 apps certified on VMware

So, given all this success, where does VMware go from here? This sets Paul up to give VMware’s vision and explain the various forces that are at work in the transformation of IT in this “unfolding cloud era.” Paul takes us on a journey from his early days in IT and how the industry transformed during the client-server era and now into the cloud era. For the most part, this is the same material that we’ve seen in previous conferences, but with one notable addition: a strange focus on data fabrics (the relational database, for example). Maritz says that the relational database as a data fabric simply cannot handle the scale of traffic that the cloud era demands.

Maritz spends some time talking about the tasks that need to be completed to help us move into the cloud era, and ties that to vSphere versions that have been delivered by VMware in recent years (4.0 in 2009, 4.1 in 2010, 5.0 in 2011). The delivery of vSphere 5 is a key part of the first task to be completed: modernize infrastructure and operations.

VMware is also aggressively target public cloud-based services running on vCloud Director, and Maritz announces a couple new vCloud partners. Not leaving out the sizable SMB market, Paul Maritz also described VMware’s commitment to that marked with a new release of vSphere Essentials, and he touches base on VMware Go, a SaaS-based service to assist in getting their infrastructure setup and running.

The second task we must address to move into the cloud era is to handle the migration or transition of existing apps to new and renewed apps. This is the core of VMware’s vFabric push: to build new frameworks, provide new platforms, and supply new data fabrics that are capable of handling the scale and volume that the new cloud era needs. SQLFire takes the extraordinary scalability of GemFire and enables people to use it with the more traditional SQL query language. VMware is also announcing vFabric Data Director, a new way of automatically provisioning and managing databases on vSphere. The first “example” or “implementation” of vFabric Data Director is vFabric Postgres, a vSphere- and vFabric-optimized version of Postgres to be used with vFabric Data Director and vSphere. The third aspect of vFabric and VMware’s push to modernize applications is CloudFoundry, a new Platform-as-a-Service (PaaS) offering. CloudFoundry supports node.js, Ruby, and Spring. Scala support has been added by the open source community. To help with adoption, VMware has created a local version of CloudFoundry that can run on a local laptop.

The third task to move into the cloud era is addressing end-user access. To that end, VMware is announcing VMware View 5.0, with improvements in bandwidth usage, greater availability of View clients (clients for just about any device), and greater integration with VoIP/unified communications providers and services. View is, of course, only part of the strategy; there’s also Horizon, VMware’s offering to manage users and applications across traditional applications and “cloud era” applications. Horizon is no longer a single product, but a collection of products that allow IT to associate information and applications to people instead of devices. Maritz also makes references to MVP, VMware’s Mobile Virtualization Platform. Virtual phones? We shall see.

At this point, Carl Eschenbach is brought onto the stage to transition into a discussion about moving to the cloud era from the perspective of three different customers who have made this journey themselves.

My battery is now running down, so I’m wrapping up this session blog.

Tags: , , , ,

VSP3205: Tech Preview, vStorage APIs

Monday, August 29, 2011 in Storage, Virtualization by slowe | 6 comments

This is a session blog for VSP3205, titled “Tech Preview: vStorage APIs for VM and Application Granular Data Management.” The presenters are Satyam Vaghani and Vijay Ramachandran, both with VMware.

This session will be repeated tomorrow at 1PM and Wednesday (didn’t catch the time). As usual, the presentation starts out with the VMware disclaimer, followed by a quick review of the “state of the union” with vStorage APIs for Array Integration (VAAI) and vStorage APIs for Storage Awareness (VASA). Both of these features enable greater communication and information exchange between vSphere and the underlying storage arrays. They are attempts to “bridge the gap” between vSphere’s logical view and the array’s physical view. While these features do help, there is still more to be done. What is really needed is a general framework to leverage future storage array features and enhancements.

The presenters share some quotes and comments from customers, where the feedback primarily resolves around greater granularity (i.e., being able to failover a single VM, or offer differentiated services on a per-VM/per-application basis). The existing VAAI and VASA features aren’t granular enough to meet these requests/demands from customers. VMware needs more granular data management.

The reason VMware can’t provide more granular data management currently is because vSphere is managing VMs and VMDKs but the arrays are operating at LUNs or RAID groups or volumes. This again reinforces the need for a larger framework that allows more integration with arrays and at the same time offers granular data management.

Here are the ideal “wish list” requirements:

  • Ability for VMware to offload per VMDK-level operations to storage systems
  • Build a framework for future features and enhancements
  • No disruption to existing VM creation workflows
  • It needs to be highly scalable

Next we see the VMware vision. They want to move to an application-centric view of the world. Let the applications specify the policies (the requirements), and let the virtualization and storage layers provision against those policies. In addition, the unit of management should be the same between vSphere and the array. That is, the unit of management needs to be the VMDK.

RDMs can help accomplish some of these goals, but the management overhead is tremendous.

Now Satyam takes the stage to show VMware’s technology direction. Satyam reinforces the disconnect between vSphere (which operates at/on the virtual storage layer/fabric) and the arrays (which operate at/on the physical storage layer/fabric). The physical and virtual fabrics never exchange information, which means that information like QoS and hardware-based data services cannot be effectively leveraged.

So the goal is to enable storage systems to natively storage VMDKs as distinct entities and provide granular VMDK data services. This interaction would be done via a policy-based interface where vSphere acts as an arbitrator of services between the virtual fabric and the physical fabric. This functionality requires new storage access methods and new vStorage APIs, and it will fundamentally change how storage is provisioned and managed in vSphere environments.

VMware decided that VMFS was not a good option for storage system differentiation and new storage solutions. Likewise, NAS was not an ideal solution, because most data services are not at file granularity. Object-based storage was considered, but VMware felt the protocol (part of T10) was not successful.

Satyam next shows a demonstration of a VM volume, which is a representation of a VMDK on a storage system. The demonstration was using a future build of ESXi and a future build of an EMC storage array with VM volume awareness. This demo shows how, for the first time, the virtualization layer and the storage layer working on the same management objects. It operates the same across both SAN and NAS. Lots of questions arise from this demonstration: Does this mean millions of VM volumes? Are we re-inventing storage systems? Is this even feasible?

To accomplish the goal of enabling VM volumes, VMware has the idea of a IO Demultiplexer, or IO Demux. The IO Demux is a special I/O channel from the host to the entire storage system. Behind the IO Demux will reside thousands of VM volumes. To handle the capacity management issue—i.e., preventing the vSphere administrator from creating too many VM volumes and overrunning the entire array—VMware introduces the idea of the capacity pool (CP). The capacity pool is not visible in the data path; it is not a LUN or mount point. CPs can span arrays, or could even span datacenters. The VM admin/user can carve VM volumes out of the CP until they run out of space. (However, this doesn’t address IOPs requirements for VM volumes or the CP. How will IOPs requirements be handled?)

Profiles enable the application to communicate its specific QoS requirements to the storage system. (Is this how we handle IOPs?) Profiles will have fixed and customizable attributes (snapshots are allowed, snapshot retention is a certain value, snapshot frequency is a certain value, etc.). (Let’s hope that these attributes are implemented in a more granular basis than the current VASA implementation.) VM admins/users can customize attributes on a per-VM (i.e., per VM volume) basis.

Satyam next moves into a demonstration with more detail on the IO demultiplexer. In this demo using protocol EMC equipment, we show multiple IO demultiplexers using multiple storage protocols.

Following this demo, Satyam shows a prototype vCenter Server UI from VMware showing capacity pools with various storage capabilities (profiles).

Next there is a demo of prototype storage from NetApp showing the awareness of the capacity pool from vCenter Server and using an NFS-based IO demultiplexer.

From there we move into a CLI-based demonstration of the same capabilities using a Dell EqualLogic array.

The next demonstration flips back into a prototype of EMC Unisphere to show off storage profiles, where the storage administrator has defined multiple storage profiles at the storage array.

Putting everything together, VM volumes looks a lot like profile-driven storage in vSphere 5 today: the storage profiles are defined at the array level (instead of at the vSphere level) and the destination “datastore” is a capacity pool instead of a LUN or NFS mount point. After creating a VM using this process, we flip over to EMC Unisphere to see the individual VM volumes created on the array, and looking at the properties for each VM volume. Satyam also shows demos of the same operation on prototype NetApp and Dell EqualLogic arrays.

The next demonstration shows an IBM XIV prototype that supports VM volumes and shows a VM being cloned at the hardware level, on a per-VM/per-VM volume basis.

The session wraps up with a review of the four major components: IO demultiplexer, capacity pools, storage profiles, and VM volumes. Satyam closes the session with a mention of the partners that participation vendors: Dell, VMware, HP, NetApp, IBM, and EMC.

Tags: , , ,

VSP1682: VMware vSphere Clustering Q&A

Monday, August 29, 2011 in Virtualization by slowe | 4 comments

This is the session almost-live-blog (no wireless signal available in the session room) of VSP1682, VMware vSphere Clustering Q&A. The panelists are Duncan Epping, Frank Denneman, and Chris Colotti, all of VMware.

Lots of notable names were present in the session—Jason Boche, Kendrick Coleman, Mike Foley, Andy Banta, fellow co-authors Forbes Guthrie and Maish Saidel-Keesing were among the ones I noticed, and I’m sure that there were even more that I didn’t notice. Clearly this session has received a lot of attention, due in no small part I’m sure to Duncan and Frank’s successful vSphere 5 Clustering book.

As the session gets started and they open the floor for questions, the audience is a bit reluctant to get started with participation. The first question from the audience is in regard to a large-scale HA environment: what is the actual usable amount of bandwidth that you can/should allocate to an environment? Duncan answers with an observation that I would echo: very few environments are network constrained, even in 1Gbps network environments. Frank expands upon that discussion with a mention that higher network speeds for vMotion will affect DRS and how it will help DRS keep the cluster workload balanced.

The second question regards shared storage and what best practices might exist. Duncan answers first; one key consideration is the vSphere version; for example, what sort of servers could affect your architecture because of HA dependencies in pre-vSphere 5 environments. The question is really more of a storage design question than a clustering question, to be honest; while storage design and clustering design are linked, they are relatively independent. Frank adds that EVC (Enhanced vMotion Compatibility) and LUN access is another consideration, especially with very large (32 host) clusters. Identical configuration on all the hosts will help the DRS algorithms more effectively balance the cluster workload.

The third question concerns VM swap files and the interaction with Storage DRS. Frank answers that; he mentions that by default Storage DRS has a built-in VMDK affinity rule that keeps all the VM’s virtual disks together. But what is the affect? Is there an effect on VM swap file performance or on Storage DRS? Frank mentions that he really doesn’t think there will be an impact. The attendee follows up with a clarifying question about placement of the swap files; Frank indicates that placing them on slower (cheaper) disks might be a viable approach. The discussion then evolves into the use of auto-tiering arrays with Storage DRS; the general recommendation is to disable I/O metrics when using Storage DRS with auto-tiering arrays.

The next question is if there is a dependence on VAAI by Storage DRS. Duncan answers; there is no dependence on VAAI or VASA on Storage DRS. That being said, VAAI would be preferential to help offload Storage vMotion operations invoked by Storage DRS. The audience member has a unclear understanding of VAAI and VASA; he believes that I/O metrics and information are passed from the storage array to vSphere by VAAI/VASA. That is, of course, incorrect; Duncan points this out by explaining (again) the use of the I/O injector to gather I/O information from the array. Future versions might leverage VASA/VAAI to gather information.

The next question is about why someone should use HA in vSphere 5 if they are reluctant to implement HA due to problems with previous versions? Duncan responds that earlier versions of vSphere had a strong reliance on DNS; this reliance on DNS was removed/addressed in vSphere 5. I would agree with Duncan’s response; name resolution was vitally important in HA environments prior to vSphere 5. Duncan mentions that the user will want to consider admission control policy and settings, but otherwise recommends that the user should enable HA. Duncan also goes into a more detailed description of storage heartbeating.

Next, a couple is asked about Storage DRS and VMs with virtual disks that live on different datastores. (The example given is database workloads with OS disks and data disks on separate tiers of storage.) What impact/benefit will this have with Storage DRS? Frank explains that Storage DRS uses both capacity (space available) and I/O metrics to determine recommendations. As a result, setting the appropriate latency on the datastore and datastore cluster will help drive SLAs, and suggests that using different tiers of disks might be unnecessary depending on the underlying disk structure. Or, as Duncan points out, you could use different Storage DRS datastore clusters.

Chris Colotti (who is acting as moderator) points out that Storage DRS is a new factor that will affect everyone’s designs.

The next question is why someone should use HA when they are using a load balancer. Duncan’s response is that, from an operational perspective, it helps address the failure of hardware nodes. Even with an F5 load balancer as this user has, someone still has to address the failure of the hardware node and restart VMs; HA can do that automatically even though hardware load balancers can help address traffic flows. Chris Colotti asks how many people are NOT using HA; a small number of people raise their hands.

Next, a user asks about the interaction of Microsoft clustering and vSphere HA/DRS. Duncan’s response is that most people disable HA/DRS for Microsoft clusters, and that VMware is working on technologies that could replace Microsoft clustering. In the end, though, the answer for Microsoft clustering is still that you have to disable HA/DRS on the VMs participating in the cluster.

The next question is about the interaction of multiple HA clusters accessing a single datastore and the impact of that design decision. Duncan mentions that he masks datastores on a cluster level, instead of exposing a datastore to multiple clusters. This user also asks about VM failure monitoring; not many people are using it (based on the number of hands raised when Duncan asks how many are using it). It’s not enabled by default, but it can help with guest OS failures. VMware has also opened the SDK for application monitoring. Frank adds that vCenter Server takes a guest OS console screenshot before resetting the VM, and Duncan answers a follow-up question about the interaction between VMware Tools and VM failure monitoring. The VM failure monitoring feature looks for network I/O, disk I/O, and the VMware Tools heartbeat to detect guest OS failure.

The next user asks about handling storage failures with vSphere HA; is there a way to handle storage array failure with vSphere HA? Duncan points out that HA will not address storage array failure. The customer mentions that EMC VPLEX will address the concern, but there are not any VMware software-based solutions to this need.

With regard to EVC, Frank highly recommends always enabling EVC on a cluster; there is no performance impact and it will help ensure processor compatibility between old and new hosts. In addition, enabling EVC on a cluster with VMs running could require some downtime in order for the CPU masks to get applied.

The next question is about VMFS-5 and the 2TB limit. What is the “sweet spot” with regards to datastore sizing? (I personally would say the answer depends on many different factors, not the least of which is the underlying storage architecture.) Frank asks the question back about how many VMs he’s comfortable placing on a single datastore. Many of the attendees are still using only a few VMs per LUN; I’m curious to know why this is the case. Is it I/O driven? Is it based on time to backup and time to recovery? That’s not clear to me, and if any readers would like to provide some feedback in the comments that would be great.

The next user asks about array-based snapshots and Storage DRS; how do the two interact? Replication, snapshots, deduplication, and thin provisioned LUNs are all affected by Storage DRS. You will definitely want to adjust operational procedures and how you use array-based features like snapshots and replication with Storage DRS. Frank recommends using Storage DRS for initial placement, but don’t use I/O metrics and don’t enable migrations.

The next user asks if Storage DRS and SRM work together; Duncan mentions that it breaks replication but doesn’t break SRM. I thought I recalled that you couldn’t use datastore clusters at all with SRM, but I don’t remember where I saw that. Anyone have more information on that?

There were a few more questions, but I had to shut down and prepare for my next session, which is my vSphere design session (VSP1926).

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: , , ,

Thinking Out Loud: Logical Link Multiplexing (Sort Of)

Monday, August 15, 2011 in Networking, Virtualization by slowe | 10 comments

Over the last few days I’ve been listening to some episodes of the excellent Packet Pushers Podcast, trying to learn about such things as Shortest Path Bridging (SPB) and 802.1Qbg. It’s this second item—802.1Qbg—that this blog post is about (indirectly).

If you’re unfamiliar with 802.1Qbg, I highly recommend Ivan Pepelnjak’s articles on the topic:

Edge Virtual Bridging (EVB; 802.1Qbg) Eases VLAN Configuration Pains
EVB (802.1Qbg) – The S Component

This second article, in particular, contained a statement which really prompted this “Thinking Out Loud” post. In his discussion of EVB and the S component, Ivan states:

Logical link multiplexing might seem a solution in search of a problem until you discover that VMware-related design documents usually recommend using 6 to 10 NICs per server – an approach that either wastes switch ports or is hard to implement with blade servers’ mezzanine cards (due to limited number of backplane connections).

I’m quite familiar with the design recommendations that led vSphere architects and administrators to build environments with 6, 8, 10, or 12 NICs in their servers—I designed and implemented my fair share of them. If that’s what’s driving logical link multiplexing, then it seems to me that we are constraining our next-generation networks and next-generation data centers with design criteria from the past. This was the idea behind the tweet I posted very early in the morning:

It would seem to me that logical link multiplexing is the result of imposing the designs of the past on top of the technology of the future.

Why did we need 6, 8, or 10 NICs in our servers in the past? Because we only had Gigabit Ethernet networks, and we needed more bandwidth than a couple of Gigabit Ethernet links provided. Add to that recommendations saying that management traffic needed to be separate from vMotion traffic which needed to be separate from VM traffic, when in reality a fair part of those recommendations stemmed from even earlier versions of ESX (anyone remember the dedicated Service Console NIC from ESX 2.x?). More than a few of these criteria don’t apply any more. Why are we still imposing those thought processes on environments leveraging dual or quad 10 Gigabit Ethernet links? Why are we driving technologies that allow us to emulate old ways of doing things on new platforms and new technologies?

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