Here’s a summary of interesting articles/posts that I’ve come across in the last couple of weeks.
We’ve been talking a lot at work recently about virtualizing our big workloads. One of the first points of discussion is usually storage performance and someone inevitably brings up RDMs. This VMware blog post reminds us that a) RDM and VMDK performance is pretty much on par these days and b) that the storage method should be chosen based on a combination of business and technical requirements, not on assumptions or outdated information. Thanks to Paul Gifford (@paulgifford) for the link.
Virtualized Exchange Storage: VMDK or RDM or…?
In early versions of ESX the virtualization overhead associated with deploying virtual disks (VMDK files) was much higher than it is today and why it was considered a best practice to place Exchange data files on physical mode raw-device mappings (RDM). As ESX and vSphere have evolved the performance difference between RDMs and virtual disks has become almost nonexistent.
Earlier this month Riverbed announced version 7 of its RiOS software which runs its Steelhead WAN acceleration appliances. There’s a couple of new features which are interesting, including support for IPv6 traffic, UDP traffic, and video optimization. The release describes video optimization as “application layer multicasting [which] allows a single video stream to serve a large number of viewers in a particular location.” With the accelerated adoption of video in the enterprise this sounds pretty good but the article does not mention what types of video codecs and formats it works with.
New features and optimizations included in the version 7.0 release include native support for HTTP video, User Datagram Protocol (UDP), and IPv6, as well as an extension to its existing optimizations for virtual desktop infrastructure (VDI).
Ivan Pepelnjak (@ioshints) has a great writeup about the history of MPLS in IOS and Junos. It goes a long way in describing some of the differences in the two implementations and, more importantly, describes why the two are different. A good read for anyone who works with the MPLS features on these platforms.
Junos Day One: MPLS Behind The Scenes
The fundamental reason for widely different MPLS implementation is the first use case: Cisco IOS started with tag switching targeted at IP-over-ATM transport, where every IP prefix needs an end-to-end LSP; Junos started with layer-3 MPLS/VPNs, where you need LSPs only toward BGP next hops.