Recent Cisco Product Launch

Monday, February 6, 2012 in Networking by slowe | 4 comments

Cisco recently launched a number of new products and new versions of products aimed at showing Cisco’s dedication and innovation in network switching. You can get Cisco’s summary of the products here. I’ll start with the hardware-focused announcements.

Hardware-Focused Announcements

Cisco’s announcements on the hardware side primarily centered around new switching capabilities in the form of 40/100 Gigabit Ethernet (GE) cards for both the Nexus 7000 series platform as well as a 40 GE card for the Catalyst 6500 series. (The 40 GE card for the Catalyst 6500 series does require the newer Supervisor Engine 2T, however.)

<aside>Did you know that the 40/100 GE specification, 802.3ba, was ratified in June 2010? I didn’t realize it has been ratified that long.</aside>

For the Nexus 7000 series, Cisco unveiled two cards:

  • The M2-Series 6-port 40 Gigabit Ethernet Module with XL Option (how’s that for a mouthful?) sports, as the name suggests, 6 non-blocking 40 GE ports. With 16 of these blades in the 18-slot Nexus 7018, that provides up to 96 ports of 40 GE connectivity. The “XL Option” in the name of the card enables the card—in conjunction with the Scalable Feature License—to support more IPv4 routes (up to 1 million, depending on several factors), more IPv6 routes (up to 350,000, again depending on several factors), and more access control list (ACL) entries. These increased route and ACL limits could be useful in environments with multiple Virtual Routing and Forwarding (VRF) or multiple Virtual Device Context (VDC) instances. Based on the Cisco data sheet, it looks like this card can work with either Fabric-1 or Fabric-2 modules, although you’ll need Fabric-2 modules for the most throughput.
  • The M2-Series 2-port 100 Gigabit Ethernet Module with XL Option provides two non-blocking 100 GE ports. The “XL Option” functions in the same way as with the 6-port 40 GE card, and it does work with both Fabric-1 and Fabric-2 modules. Here’s the official Cisco data sheet.

Based on the data sheet, it looks like both of these cards will require version 6.1 of NX-OS, which—to my knowledge—is a brand-new release. (Version 6.0 of NX-OS for the Nexus 7000 series was released in late December.)

One interesting note about the 40 GE card is that it supports the use of a breakout cable that allows a single 40 GE port to support four 10 GE connections. This is true for both the Nexus 7000 and Catalyst 6500 cards, as far as I can tell. (Cisco references a FourX connector for the Catalyst 6500 card, but does not reference the same connector for the Nexus blade, instead simply mentioning a “breakout cable”.)

Cisco also introduced the Catalyst 4500-X, a fixed configuration 10 GE aggregation switch. They mentioned “40 GE readiness,” but it’s not clear when 40 GE uplinks will make their way to this particular platform.

Rounding out the hardware announcements was the Nexus 3064-X, a follow-up the low-latency Nexus 3000 series of switches introduced some time ago. This version offers lower power consumption and additional reductions in switching latency. The specific switching latency reductions were not specified anywhere that I found.

Software-Focused Announcements

The software-focused announcements were primarily centered around the Nexus 1000V/1010 and a new feature called Easy Virtual Network (EVN).

  • A new version of the Nexus 1000V was announced that supports VXLAN (Virtual Extensible LAN). I’ve discussed VXLAN extensively (see here), as have others in the industry, so I won’t rehash that again.
  • Also of note is that the Cisco Virtual Security Gateway (VSG) will offer zone-based firewalling services to VMs on VXLAN segments.
  • The Nexus 1010-X is a “beefed up” version of the Nexus 1010 (yes, I know this is technically a hardware product), intended to support more virtual networks. See here for more information on the differences between the Nexus 1010 and the Nexus 1010-X.
  • Easy Virtual Network (EVN) is the most interesting of the software-based announcements (to me, at least). Cisco touts EVN as “fully compatible with established standards, including Multiprotocol Labl Switching (MPLS), MPLS VPN over IP (multipoint generic routing encapsulation, also known as mGRE), Multi-Virtual Route Forwarding (also known as VRF-Lite), and others.” (More information available here.) However, it appears that EVN doesn’t actually use any of these mechanisms. In fact, it’s unclear to me exactly what mechanism EVN does use. The data sheet (linked above) mentions the use of a VNET tag, and indicates that the VNET tag is stored in the 802.1q VLAN ID field. This looks like Cisco is creating yet another Layer 3 VPN solution, instead of leveraging existing solutions. Why not add VXLAN support to the hardware switches instead of creating EVN? Maybe I’m completely missing the mark here…feel free to correct me (courteously, of course!).

Why This Matters to You

All these product announcements and new product versions are pretty cool, but you might be wondering, “Why does this matter to me?” Good question. Here are my thoughts:

  • The 40 GE and 100 GE cards are important in data centers where we are seeing increased deployment of 10 GE to the servers. Once motherboard manufacturers start using 10 GE LoM (LAN on Motherboard) ports, the deployment of 10 GE to servers in data centers will naturally increase. Deploying 40 GE and 100 GE uplinks in 10 GE-heavy environments makes sense (depending on the details, naturally).
  • You already knew the VXLAN-capable 1000V was on the way (this was alluded to in the original VXLAN announcement at VMworld 2011), so no real surprises there.
  • The Nexus 1010-X simply allows you to run more VSBs (virtual service blades), such as the Nexus 1000V VSM (virtual supervisor module). If you’re a Nexus 1000V customer, you might have already started investigating the use of the Nexus 1010 to host the VSMs. Large customers (service providers, perhaps?) had a need for more VSBs on a single Nexus 1010, hence the Nexus 1010-X.
  • EVN…well, I’m stuck on EVN. I certainly see the need for simpler separation of traffic, but again I must ask why Cisco appears to be creating something new instead of re-using protocols that are perfectly suited for this purpose? Maybe I need a networking expert to explain it to me. (When I understand it, I’ll post an explanation that everyone else can understand. Fair?)

As always, feel free to post any clarifications or corrections in the comments below. I’d love to hear from any networking gurus on any of the points that I raised in this article.

Tags: , ,

Technology Short Take #20

Friday, January 20, 2012 in Networking, Storage, Virtualization by slowe | 3 comments

Welcome to Technology Short Take #20, the latest collection of various data center-related links, articles, and thoughts. I hope you find something useful here.

Networking

  • For all the writing and thinking I’ve done on VXLAN (here, here, and here), someone (thanks Ed!) mentioned something to me recently that I hadn’t even considered. (It’s so simple I’m embarrassed that I overlooked it.) VXLAN uses UDP for its encapsulation. What about dropped packets, lack of sequencing, etc., that is possible with UDP? What impact is that going to have on the “inner protocol” that’s wrapped inside the VXLAN UDP packets? Or is this not an issue in modern networks any longer?
  • Since Ivan thinks we do need to worry about spaghetti and horseshoes, I’m curious to know if he thinks we need to worry about UDP as the transport for VXLAN.
  • Jake Howering of Cisco (with whom I’ve worked on a few occasions) posted a couple of good articles on the Cisco Data Center and Cloud blog. Jake focuses on DCI (data center interconnect), so his articles naturally reflect that focus. The first article discusses the use of LISP for ingress path optimization in VM mobility scenarios. Ingress path optimization is only half of the solution, though; Jake discusses the other half in the second article, which covers egress path optimization with FHRP filtering, something I discussed in my recent VXLAN/OTV article.
  • It looks like you can’t create a vPC (virtual port channel) between a Nexus 55xx and a Nexus 50×0 switch.
  • Kyle Mestery speculates a bit here about integrating VXLAN in OpenStack Quantum.

Servers/Applications/Operating Systems

  • I’ll put this under the “Servers” category even though it’s storage-related: In this post, Ryan Hughes explains how to use the UCSM CLI to do some cool—and useful—boot from SAN troubleshooting.
  • Purely by accident, I stumbled across this humorously-titled series regarding Oracle on Fibre Channel. It turns out the author works for EMC, although I didn’t know that ahead of time. In any case, if you’re interested in finding out how manly men deploy Oracle, check out the series titled “Manly Men Only Deploy Oracle with Fibre Channel” (parts 1, 2, 3, 4, 5, 6, 7, and 8).

Storage

  • Clint Kitson recently published a guide on setting up the FC zoning for WAN communications on a VPLEX Metro cluster. This article is a good complement to my own MDS zoning articles (creating MDS zones, managing MDS zones, using device aliases) and shows some practical examples of those commands in action.
  • Simon Seagrave points out a firmware update for Iomega IX2 and IX4 storage devices that fixes problems with Time Machine under Mac OS X 10.7 “Lion”. Thanks Simon!
  • This post by Hans De Leenheer was written in July of last year, but it only came to my attention in late November after I met Hans in Vienna during my “round the world” trip. (Great guy, by the way.) He asked me to respond to his criticism of EMC’s “mega-launch” in early 2011. I wish I could say Hans is way off, but I personally agree that the hyperbole was a bit much. I do have to disagree a bit with his comment about no new products; while EMC didn’t introduce all new hardware for some lines (like the VMAX), they did introduce new array software (like Enginuity 5875 for the VMAX). Does that count as a “new product”? I guess the answer to that depends on whether you work in marketing. At least it’s good to hear that Hans feels EMC is, in his words, “a solid company making solid storage solutions”. Perhaps EMC should focus more on that…
  • Erik Smith has written a very detailed post on FC/FCoE hard zoning versus soft zoning. It’s an excellent post, and well worth the time if you aren’t already an FC/FCoE expert. By the way, if you haven’t yet subscribed to Erik’s RSS feed, I highly recommend it. He puts out some great stuff.
  • David Robertson wrote up the steps for creating a Linux-based SMC/SPA server, in the event you use EMC Symmetrix in your environment.

Virtualization

Here are a few other virtualization-related links that I also thought you might find interesting or useful:

Are operational considerations overlooked in virtualization?
VMware KB – Detaching a datastore or storage device from multiple ESXi 5.0 hosts
What happened to vShield in vSphere 5?
Linux VMware Tools Install Changes to Upstart
VMware KB – Disabling VAAI Thin Provisioning Block Space Reclamation (UNMAP) in ESXi 5.0

Cloud Computing

  • You’ll note that I didn’t lump cloud computing under virtualization, since I think that there’s more to “cloud” than virtualization (although I would grant that virtualization is a big part of it). So much more, in fact, that people are referring to cloud computing as complex. (Gasp!) But this post puts cloud complexity in perspective. If you are merely a consumer of services, then cloud is simple; if, however, you are a provider of services, then cloud is more complex. Good article.

That’s it for this time around. If you have any comments or thoughts on anything shared here, feel free to speak up in the comments.

Tags: , ,

What Does FCoE Have To Do With VM Mobility?

Monday, January 16, 2012 in Storage, Virtualization by slowe | 2 comments

I recently read over Stephen Foskett’s Eight Unresolved Questions About FCoE article, in which he outlines eight topics that should be addressed/prioritized in order to make FCoE, in his words, “truly world-class”.

One of these topics was virtual machine mobility. Here’s what Stephen wrote under the heading “How Do You Handle Virtual Machine Mobility?”:

As I described recently, virtual machine mobility is a major technical challenge for existing networks. The VMware proposal, the VXLAN, seems to be gaining traction right now. But this is only a solution for data networking. How will FCoE SANs handle virtual machine mobility? This remains unresolved as far as I can tell, though Ethernet switch vendors have come up with their own answers. Brocade demonstrated just such a solution at Networking Field Day 2, and I know that others have answers as well. But will there be an interoperable industry solution?

My response to Stephen’s question is pretty simple: VM mobility isn’t a problem for FCoE. VM mobility is a problem for all storage, regardless of protocol.

In my view, tying VM mobility to FCoE is simply buzzword hype. Let’s look at this from a technical perspective—what is so different about FCoE compared to FC, iSCSI, or NFS with regard to VM mobility? Nothing! Regardless of storage protocol, when you move a VM from one data center to another data center, the VM’s storage is still going to sit back in the original data center. The protocol whereby we access that data doesn’t change that fact.

Yes, you can route the IP-based protocols (iSCSI and NFS), which might give you some additional flexibility. But the migrated VM’s storage is still going to sit in the original data center—the only thing you’ve accomplished is introduced some additional latency by adding routers into the mix.

As you can see, VM mobility and storage isn’t an FCoE problem—it’s a storage problem, plain and simple. Protocols can’t fix it. What’s needed to fix it is a fundamental shift in how storage is designed. We need distributed file systems (not just clustered file systems), distributed caching algorithms, greater integration between the block storage and the distributed file systems, greater hypervisor awareness of the underlying storage topology, and more efficient data movement mechanisms. Until then, we can rage all we want about how this protocol or that protocol doesn’t address VM mobility, but we’re simply missing the mark.

Tags: , , ,

VSI 5.1 Issue and Fixes

Friday, January 13, 2012 in Storage, Virtualization by slowe | 1 comment

As you might have already seen (Chad broke the news here, Itzik has more details here), EMC has released version 5.1 of the Virtual Storage Integrator (VSI), the vCenter plugin available to customers at no additional charge. I won’t revisit all the new features; rather, I wanted to bring to your attention a late-discovered issue with the VSI 5.1 release. If this information hasn’t already made it into the Release Notes, it should be there soon (there’s also an EMC Primus case being created).

Here’s the lowdown: there’s an issue with VSI Storage Viewer 5.1 that prevents it from properly upgrading previous versions of VSI. After an upgrade to Storage Viewer 5.1, the user may encounter an error like “Unable to load DLL ‘SEWrapper.dll’: The specified module could not be found” (or similar).

The problem isn’t in SEWrapper.dll, which is working properly and is, in fact, installed on the system. The problem is in the Microsoft Visual C++ 2010 Redistributable Package (x86) isn’t installed, and that’s a pre-requisite for the SEWrapper.dll library.

There are two workarounds for this issue:

  1. Remove VSI Storage Viewer 5.1 and re-install it from scratch. This will cause the Visual C++ redistributables to get installed correctly, fixing the problem. Note: If you have older VSI features installed—like Storage Pool Management 5.0 or Path Management 5.0—reinstall those after Storage Viewer 5.1 is installed.

  2. Download and install the Microsoft Visual C++ 2010 Redistributable Package (x86) separately. You should be able to download that here.

This will be in the Release Notes very soon (if not already), but I wanted to highlight the problem—and the fixes—here just in case.

Tags: , , ,

Technology Short Take #19

Tuesday, January 3, 2012 in Networking, Storage, Virtualization by slowe | 4 comments

Welcome to Technology Short Take #19, the first Technology Short Take for 2012. Here’s this year’s first collection of links, articles, and thoughts regarding virtualization, storage, networking, and other data center technology-related topics. I hope you find something useful!

Networking

  • While configuration limits aren’t the most exciting reading, they are important from time to time. Here’s some configuration limits for the UCS 6100 and 6200 series.
  • Understanding the differences—both positive and negative—between the various approaches to solving a particular challenge is a key skill. That’s why I like this article on HP Flex-10 versus NIOC for VDI. The author (Dwayne) weighs the pros and cons of both approaches in helping to shape network traffic for VDI deployments using 10Gb Ethernet.
  • It would appear that my recent VXLAN and OTV connectivity posts (incorrect VXLAN post here, corrected VXLAN post here, and OTV/VXLAN post here) sparked a discussion about whether we really need to concern ourselves with traffic trombones. On one side we have Brad Hedlund speculating that the network should be treated like a large virtual I/O fabric; on the other side we have Greg Ferro countering that we do need to be concerned about the topology of the network. I can see both sides of the argument, but at this stage of the game, I’m inclined to agree more with Greg. In the future (it’s unclear how far in the future) I think that Brad’s points will be more valid, but not right now.
  • This post by Ivan Pepelnjak on VXLAN, IP multicast, OpenFlow, and control planes highlights some of the current limitations with VXLAN and thus reinforces why I think that Brad’s arguments are a bit ahead of their time.
  • A few folks had some write-ups on Embrane Heleos: Greg Ferro, Jason Edelman, Brad Hedlund, Brad Casemore, and Ivan Pepelnjak. My question (and this is spurred in part by some comments by Brad Casemore): is this another Cisco spin-in move?

Servers/Operating Systems/Applications

Storage

Virtualization

And that it’s for this time around; as always, I hope you’ve found something useful here. Courteous comments are always welcome; feel free to speak up below.

Tags: , , , , , , , , , , ,

Some Projects for 2012

Monday, January 2, 2012 in General, Networking, Virtualization by slowe | 13 comments

Rather than posting some sort of “2011 in review” article where I talk about how many visitors the site had or how many RSS subscribers there are, I thought I’d instead focus on the upcoming year and some of the projects in which I’ll be involved. By describing some of the projects that I’m undertaking this year in 2012, that gives you—the readers—a rough idea of some of the types of content that will likely appear in the coming year.

Here are some of my 2012 projects (some of these I’ve already tweeted about):

  1. I’m going to learn to script in Perl. Many people have asked why Perl and why not Python or Ruby or something else. Honestly, I don’t have a really good answer for you. I tried (unsuccessfully) to teach myself Perl a couple of years ago, so I still have the O’Reilly Learning Perl book. Rather than spending money to learn some other scripting language, it seemed reasonable to revisit Perl again and just leverage the resources I already have. You might see a few Perl-related posts here and there as I work through Learning Perl, but I’ll try not to bore you with elementary stuff.

  2. I’m going to learn German. Same scenario here—many people have asked why German and why not Spanish or French. I do have an answer this time: I seem to be spending a fair amount of time in Vienna, so German seemed to make sense. I also have a series of customer meetings planned in Germany in the first quarter of this year. Plus, German is completely new and different than anything I’ve learned before, and I wanted to challenge myself to learn and think in new ways. It’s unlikely that this will find its way into any blog posts, but you never know…

  3. I’m going to become much more familiar with the Xen hypervisor. I haven’t yet decided if I’ll focus strictly on the open source version of Xen or Citrix XenServer; I’m open to suggestions there. No, this doesn’t mean that I’m abandoning VMware or anything like that; I just want to expand my knowledge. You can’t simply discount Xen; after all, Amazon EC2 is built on Xen. Along with this dive into Xen, I’ll also be looking very closely at Open vSwitch and OpenStack. I’d expect that a great deal of this education will eventually end up in various blog posts here.

  4. I’m going to pursue my CCNP. I “re-achieved” CCNA last year, and this year I’m pursuing my CCNP. As with Xen, I’m confident that the learning curve required to move closer to (or even achieve) CCNP will result in a number of related blog posts on various networking technologies or concepts.

I do have a few other projects planned for this upcoming year, but I’m not quite ready to discuss those publicly yet. At least one of these other projects will be something new that I haven’t done before. Stretching myself and my skills/experience in new directions is a bit of a theme this year.

If you have any tips/tricks/advice to share on any of these upcoming projects, or if there are specific things related to these projects that you’d like to see blogged about here, please let me know in the comments. Thanks, and I hope that 2012 is going to be as exciting for you as it will be for me!

Tags: , , , ,

OTV and VXLAN Layer 3 Connectivity Compared

Thursday, December 22, 2011 in Networking, Virtualization by slowe | 14 comments

Building large-scale L2 networks, including stretched L2 networks, seems to be all the rage these days, driven in part by virtual machine mobility (aka vMotion in VMware vSphere environments or XenMotion in Citrix XenServer environments). While this isn’t always a good idea—some might say it’s never a good idea—it is still something that many organizations are evaluating.

With the announcement of VXLAN at VMworld 2011, a new question seems to have arisen: can I use VXLAN instead of (insert some other protocol here) to create my stretched L2 networks? In this post, I’d like to compare the use of VXLAN with OTV (Overlay Transport Virtualization) for that very purpose. Of course, since VXLAN hasn’t actually been released, the discussion is partially theoretical.

My primary focus in this post will be how each of these protocols handles traffic patterns in the course of addressing the need for L2 connectivity over routed L3 networks.

First, let’s look at VXLAN. The figure below is taken from my revised L3 connectivity with VXLAN post, which I encourage you to read for more details.

As you can see, once a VM inside a VXLAN segment is migrated to a new network, the traffic “trombones” back and forth across the VXLAN segment because all traffic has to pass through a single vShield Edge (VSE) instance. This brings up a key limitation of VXLAN that I think is important to point out: VXLAN has an innate dependency on VSE, and VSE cannot be made redundant. That’s right—you can’t have VSE-specific failover functionality; instead, you have to rely on vSphere HA, VM Monitoring, and other features. That means failover times in the minutes, not seconds. What do you think that will do to network connections?

Now, let’s compare VXLAN’s L3 connectivity with OTV. First, here’s a diagram to show connectivity with OTV before a VM is migrated to the second site:

No real surprises here. I’ll just point out here that a typical OTV deployment following “recommended practices” will use redundant Nexus 7000 switches, as shown here. That’s a key advantage that OTV has over VXLAN—the ability to provide redundancy is there and redundancy is easily built into the solution, with failover times in the seconds (or better).

Now, take a look at the post-migration traffic flows with OTV:

In case you didn’t notice it, let me point out the obvious: note the lack of traffic tromboning here. Here’s how it’s accomplished (and documented in this blog post by Ron Fuller, aka @ccie5851 or VDCBadger to his friends):

  • Each Nexus 7000 pair runs HSRP.
  • The HSRP hello packets are filtered (blocked) from the OTV interfaces. This keeps the HSRP pairs in each data center from knowing about the pair in the other data center.
  • Each HSRP pair runs the same virtual IP (the default gateway for the 10.1.1.0/24 subnet).

In this configuration, once the VM migrates to the second site the HSRP pair at the second site won’t need to send traffic across the OTV link to reach the migrated VM. This appears to be a significant advantage to OTV—a greater knowledge of the routing topology allows OTV to be more intelligent about how traffic should be directed across/around the network.

<aside>Of course, this doesn’t address L3 routing concerns from subnets not directly attached to the Nexus 7000 pairs. For that, we’d need something like LISP.</aside>

As I see it—and networking experts are welcome to jump in if I’m mistaken—this gives OTV two key advantages over VXLAN:

  1. OTV, because it is running on physical networking equipment, is more intelligent than VXLAN about how traffic is directed/routed in/around/across a network. This can result in more efficient utilization of a data center interconnect as a result of reduced “traffic tromboning.”
  2. OTV, because it is running on physical networking equipment, can provide better redundancy and faster failover than VXLAN (which relies on single instances of VSE).

It’s entirely possible that if VXLAN ever makes it into physical network equipment that these advantages of OTV will be nullified.

It’s also important to point out that while OTV and VXLAN have some overlap in functionality they are partially targeted at solving different problems. While both protocols address L2 connectivity across L3 networks, VXLAN also addresses the exhaustion of the VLAN address space in larger networks (especially service provider networks). This is an issue that OTV does not try to address. However, it seems to me that OTV would co-exist better with a solution like Q-in-Q, which could (as far as I can tell) address the VLAN ID exhaustion issue.

Once again, I encourage network experts to chime in and share their views. If I’ve misstated something, please let me know. Questions, thoughts, and comments are always welcome.

Tags: , , ,

VMware View Client for Mac with PCoIP

Friday, December 16, 2011 in Virtualization by slowe | 5 comments

VMware just released the PCoIP-enabled version of the VMware View client for Mac OS X (download here; login required). After having used it this morning to connect to my corporate View desktop, I must say that I am quite impressed.

The responsiveness of my View desktop is significantly improved over RDP. Under RDP, browsing any sort of Web site—and accessing various internal-only sites is a key use for my corporate View desktop—was just downright painful. With the new PCoIP-enabled Mac client, it’s drastically better. Pages redraw much more quickly, and the browser is much more responsive.

Aside from the much-improved performance granted by the PCoIP support, a few other things stand out:

  • It’s nice to see VMware fully embrace the idea of developing for the Mac—no installer package, just open the DMG and drag-and-drop the application into your Applications folder. The new client also offers Lion full-screen support as well.
  • The new client no longer requires the Microsoft RDP Client installed. (However, note that if you need RDP connectivity to Windows 7, the new client won’t support that just yet. For that, you’ll need to use the previous generation VMware View client along with the Microsoft RDP Client.)
  • You can easily resize your desktop by simply resizing the window. That’s a little thing, I know, but it’s still handy.

Overall, it’s great to see VMware working hard to expand endpoint availability. If I understand correctly, VMware also released updated clients for the iPad and Android as well, both of which also support PCoIP (the View client already supported PCoIP and I’ve used that before as well). Now we just need a PCoIP-enabled client for Linux and we’re good to go!

Tags: , ,

UIM/Operations 3.0 Now GA

Thursday, December 15, 2011 in Networking, Storage, Virtualization by slowe | 2 comments

Within the last couple of days, I received an e-mail notification that UIM/Operations 3.0 had been finalized and was now generally available (i.e., it was now considered GA).

For those that aren’t familiar, UIM has two flavors:

  • UIM/Provisioning (also referred to as UIM/P), which is tasked with handling provisioning/de-provisioning tasks in a Vblock. This would include tasks like deploying UCS B-series blades, zoning FC fabrics, and setting up storage pools.
  • UIM/Operations (also referred to as UIM/O) is tasked with providing near real-time visibility into the Vblock, as well as root cause and impact analysis.

In addition to support for UIM/P 3.0 (more info here) and all associated Vblock types, this latest release of UIM/O adds the following features:

  • Model-based deterministic automated root cause analysis for faults in a Vblock environment
  • Automated impact analysis that visualizes impact on higher-order abstractions such as vApps, UIM Services (these are defined within UIM/P) and Vblocks
  • Event forwarding via SNMP traps to enable northbound integration
  • Automation of trap reception from MDS and Nexus switches
  • Saving and restoring user preferences

As with UIM/P, the new version of UIM/O is available to authorized users on Powerlink:

Home > Support > Software Downloads and Licensing > Downloads E-I > Ionix Unified Infrastructure Manager/Operations

Documentation for UIM/O 3.0 is also available on Powerlink:

Home > Support > Technical Documentation and Advisories > Software ~ E-I ~ Documentation > Ionix Family > Ionix for Data Center Automation and Compliance > Ionix Unified Infrastructure Manager/Operations > 3.0 and Service Packs

(Think that’s a deep enough structure to navigate?)

Enjoy!

Tags: , , ,

Technology Short Take #18

Sunday, December 11, 2011 in Networking, Storage, Virtualization by slowe | 3 comments

Welcome to Technology Short Take #18! I hope you find something useful in this collection of networking, OS, storage, and virtualization links. Enjoy!

Networking

The number of articles in my “Networking” bucket continues to overflow; I have so many articles on so many topics (soft switching, OpenFlow, Open vSwitch, MPLS) that it’s hard to get my head wrapped around all of it. Here are a few posts that stuck out to me:

  • Ivan Pepelnjak has a very well-written post explaining the various ways that virtual networking can be decoupled from the physical network.
  • I stumbled across a trio of articles by Denton Gentry on hash tables (part 1, part 2, and part 3). This is an interesting perspective I hadn’t considered before; as we move more into software-defined networks (SDNs), why are we continuing to use the same mechanisms as before? Why not take advantage of more efficient mechanisms as part of this transition?

Servers/Operating Systems

  • Nigel Poulton and I traded a few tweets during HP Discover Vienna about SCSI Express (or SCSI over PCIe, SoP). He wrote up his thoughts about SoP and its future in the storage industry here. Further Twitter-based discussions about fabrics led him to say that HP buying Xsigo would bring the competition back against UCS. I’m not so sure I agree. Xsigo’s server fabric technology/product is interesting, but it seems to me that it’s still adding layers of abstraction that aren’t necessary. As SR-IOV, MR-IOV, and PCIe extension matures, it seems to me that Ethernet as the fabric is going to win. If that’s the case, and HP wants to bring the hurt against UCS, they’re going to have to invest in Ethernet-based fabrics.
  • Speaking of UCS, here’s a “how to” on deploying the UCS Platform Emulator on vSphere. You might also like the UCS PE configuration follow-up post.
  • Here’s what looks to be a handy Mac OS X utility to track how long until your Active Directory password expires. Sounds simple, yes, but useful.

Storage

Virtualization

  • Jason Boche, after some collaboration with Bob Plankers, wrote up a good procedure for expanding the vCloud Director Transfer Server storage space. It’s definitely worth a read if you’re going to be working with vCloud Director.
  • Microsoft has released version 3.2 of the Linux Integration Services for Hyper-V. The new release adds integrated mouse support, updated network drivers, and fixes an issue with SCVMM compatibility.
  • Julian Wood, who I had the opportunity to meet in Copenhagen at VMworld 2011, has published a four-part series on managing vSphere 5 certificates. Follow these links for the series: part 1, part 2, part 3, and part 4.
  • Thinking of deploying Oracle on vSphere? You should probably read this three-part series from VMware’s Business Critical Applications blog: part 1 is here, part 2 is here, and part 3 is here.
  • I’m so used to dealing with VLANs in a vSphere environment, I didn’t consider the challenges that might come up when using them with VMware Workstation. Fortunately, this author did—read his post on mapping VLANs to VMnets in VMware Workstation.
  • I thought that this article on virtual disks with business critical applications would be a deep dive on which virtual disk formats (thin, lazy zeroed, eager zeroed) are best suited for various applications. While the article does discuss the different virtual disk formats, unfortunately that’s as far as it goes.
  • Fellow VMware vSphere Design co-author Forbes Guthrie highlights an important design concern with AutoDeploy: what about a virtual vCenter instance? Read his full article for the in-depth discussion.
  • This post by William Lam gives a good overview of when vSphere MoRefs change (or don’t change).
  • Here’s a good explanation why NIC teaming can’t be used with iSCSI binding.
  • Cormac Hogan also posted a nice overview of some new vmkfstools enhancements in vSphere 5.
  • Terence Luk posts a detailed procedure to help recover VMware Site Recovery Manager in the event of a failure of one of the SRM servers. Good information—thanks Terence!

And that’s it for this time around. Feel free to add your thoughts in the comments below—all comments are welcome! (Please provide full disclosure of vendor affiliations/employment where applicable. Thanks!)

Tags: , , , , , , , ,

« Older entries