Standards

You are currently browsing articles tagged Standards.

A Quick Thought Regarding Cloud Computing

Friday, January 9, 2009 in Virtualization by slowe | 7 comments

So, a number of sites have been tossing around this conversation regarding cloud computing, what it is (and isn’t), and where it’s headed. As I was responding to a private e-mail from another conspirator in this conversation, I came up with something that I thought would be best shared with everyone else.

First, a question: if you’ve ever architected a large enterprise solution, what was the one thing that gave you the most flexibility in designing that solution?

Think about that for a second.

OK, have an answer? Here’s my answer: standards.

That’s right, standards. How? Let’s say you’re architecting a large enterprise solution involving servers, storage, software, etc. Now, you may have had your preferences regarding some of the components in that solution—for example, you may have preferred HP ProLiant servers—but the truth of the matter is, you could have just as well used IBM servers or Dell servers. You may have preferred EMC Fibre Channel storage, but the truth of the matter is that you probably could have just dropped in an equivalently-configured HP EVA or an HDS array.

Yes, yes—sometimes there are actual technical requirements around availability, functionality, performance, etc., that drive product selection. We all know that. But in many, many cases, the products we select to create the solutions we recommend are based on preferences.

Why is it that we can mix and match these components together according to our preferences? Because they all adhere to standards. An IBM server will connect to a Gigabit Ethernet switch and communicate across the network in exactly the same fashion as an HP ProLiant or a Dell PowerEdge. These servers run the same x86-based CPUs. A Brocade Fibre Channel switch works in essentially the same fashion as a Cisco MDS. When does this mixing and matching become a problem? When you mix in proprietary extensions, proprietary interconnects, and proprietary protocols.

Ah, proprietary-ness. (Nice word, eh?) That brings us to cloud computing. Where are the protocols that define how clouds, or even cloud components, will communicate with each other? Where are the interconnects that will allow clouds to share data and metadata? Where are the standards that define what that data and metadata are? That’s my point: they don’t exist. Right now, we are in a world of proprietary interconnects and proprietary protocols that prevent us from mixing and matching cloud computing components or providers. Sure, it can be done, but only through converters and translators and such.

And that is my point. When I discuss the lack of definition around cloud computing, it’s not because of care how we define cloud computing. It’s because there’s no structure, no framework, and no standards as to how the cloud is formed. Ironically, perhaps even paradoxically, it’s the definitions, the structures, and the frameworks that give the cloud it’s flexibility.

Tags: ,

Continuing the FCoE Discussion

Tuesday, December 9, 2008 in Storage by slowe | 17 comments

A few weeks ago I examined FCoE in the context of it’s description as an “I/O virtualization” technology in my discussion of FCoE versus MR-IOV. (Despite protestations otherwise, I’ll continue to maintain that FCoE is not an I/O virtualization technology.)

Since that time, I read a few more posts about FCoE in various spots on the Internet:

Is FCoE a viable option for SMB/Commercial?
Is the FCoE Starting Pistol Aimed at iSCSI?
Reality Check: The FCoE Forecast

Tonight, after reading a blog post by Dave Graham regarding FCoE vs. InfiniBand, I started thinking about FCoE again, and I came up with a question I want to ask. I’m not a storage expert, and I don’t have decades of experience in the storage arena like many others that write about storage. The question I’m about to ask, then, may just be the uneducated ranting of a fool. If so, you’re welcome to enlighten me in the comments.

Here’s the question: how is FCoE any better than iSCSI?

Now, before your head explodes with unbelief at the horror that anyone could ask that question, let me frame that question with more questions. Note that these are mostly rhetorical questions, but if the underlying concepts behind these questions are incorrect you are, again, welcome to enlighten me in the comments. Here are the framing questions that support my primary question above:

  1. FCoE is always mentioned hand-in-hand with 10 Gigabit Ethernet. Can’t iSCSI take advantage of 10 Gigabit Ethernet too?
  2. FCoE is almost always mentioned in the same breath as “low latency” and “lossless operation”. Truth be told, it’s not FCoE that’s providing that functionality, it’s CEE (Converged Enhanced Ethernet). Does that mean that FCoE without CEE would suffer from the same “problems” as iSCSI?
  3. If iSCSI was running on a CEE network, wouldn’t it exhibit predictable latencies and lossless operation like FCoE?

These questions—and the thoughts behind them—are not necessarily mine alone. In October Stephen Foskett wrote:

And iSCSI isn’t done evolving. Folks like Mellor, Chuck Hollis, and Storagebod are lauding FCoE at 10 gigabit speeds, but seem to forget that iSCSI can run at that speed, too. It can also run on the same CNAs and enterprise switches.

If those Converged Network Adapters (CNAs) and enterprise switches are creating the lossless CEE fabric, then iSCSI benefits as much as FCoE. Dante Malagrino agrees on the Data Center Networks blog:

I certainly agree that Data Center Ethernet (if properly implemented) is the real key differentiator and enabler of Unified Fabric, whether we like to build it with iSCSI or FCoE.

Seems to me that all the things that FCoE has going for it—10 Gigabit speeds, lossless operation, low latency operation—are equally applicable to iSCSI as they are functions of CEE and not FCoE itself. So, with that in mind, I bring myself again to the main question: how is FCoE any better than iSCSI?

You might read this and say, “Oh, he’s an FCoE hater and an iSCSI lover.” No, not really; it just doesn’t make any sense to me how FCoE is touted as so great and iSCSI is treated like the red-headed stepchild. I have nothing against FCoE—just don’t say that it’s an enabler of the Unified Fabric. (It’s not. CEE is what enables the Unified Fabric.) Don’t say that it’s an I/O virtualization technology. (It’s not. It’s just a new transport option for Fibre Channel Protocol.) Don’t say that it will solve world hunger or bring about world peace. (It won’t, although I wish it would!)

Of course, despite all these facts, it’s looking more and more like FCoE is VHS and iSCSI is Betamax. Sometimes the “best” technology doesn’t always win…

Tags: , , ,

FCoE versus MR-IOV…huh?

Monday, November 17, 2008 in Storage, Virtualization by slowe | 7 comments

I’ve had this link sitting in my “Articles To Read” list for quite some time, but—to be perfectly honest—I’ve been just too busy to really do anything about it. Now that a hectic few weeks has wrapped up and I have a small breather before the next hectic few weeks, I wanted to comment briefly on Doug Gourlay’s discussion of FCoE versus MR-IOV.

First, some background: For those that aren’t familiar, FCoE is Fibre Channel over Ethernet, a T11 standard for running Fibre Channel Protocol over Ethernet, specifically 10 Gigabit Ethernet. More information on FCoE is found here. MR-IOV is Multi-Root I/O Virtualization, a PCI SIG specification for using PCI Express (PCIe) to connect and share multiple devices. More information on MR-IOV can be found here. MR-IOV is a multi-server extension to Single-Root I/O Virtualization, or SR-IOV.

Like Doug, I’ll put in a disclaimer that I haven’t read the report to which he’s referring in his article, either. However, as an individual who has done some research on the topic of I/O virtualization, I will say that anyone who compares FCoE to MR-IOV is comparing apples to oranges. These two technologies, in my mind, are designed to address two different problems.

FCoE provides the ability to use a single physical transport—10 Gigabit Ethernet, in this case—for Fibre Channel Protocol (FCP) as well as TCP/IP, iSCSI, and other Ethernet-borne protocols. This allows for the creation of a unified fabric, a single physical transport that carries all the various kinds of traffic that Ethernet-based Local Area Networks (LANs) and Storage Area Networks (SANs) carry separately today. Via the IETF Converged Enhanced Ethernet (CEE) standard—adopted by Cisco as Data Center EthernetTM—FCoE will ultimately have the same low, predictable latency and error-free operation that FCP enjoys today. FCoE is not, however, designed or architected to do anything other than allow FCP to run over Ethernet. It’s not intended to be a server interconnect technology. (Unless I’m missing something?)

MR-IOV, on the other hand, is intended to play in the server interconnect field. Its purpose is not to allow FCP to run over Ethernet, or to allow FCoE, iSCSI, and other TCP/IP protocols share the same physical connections. MR-IOV’s purpose is to allow multiple servers to share PCIe-based devices, like a FC Host Bus Adapter (HBA), or an iSCSI HBA, a 10 Gigabit Ethernet network interface card (NIC), or a video capture card. MR-IOV is intended to provide I/O virtualization, regardless of what type of I/O that might be. As long as the I/O runs across a PCI Express bus, MR-IOV comes into play.

I’ve heard multiple people refer to FCoE as an I/O virtualization technology, but I just don’t agree. FCoE only applies to FCP over Ethernet. It doesn’t apply to iSCSI. It doesn’t apply to video traffic, or audio traffic, or HTTP traffic. It only applies to FCP over Ethernet. While I might allow that FCoE does allow for a form of virtualization, by virtualizing the physical transport beneath FCP, I would not call it I/O virtualization. Further, FCoE and MR-IOV are complementary. You could use MR-IOV to share a single Converged Network Adapter (CNA), which provides FCoE and 10 Gigabit Ethernet functionality, among multiple servers. In this situation, what’s providing the I/O virtualization: MR-IOV, which is allowing multiple servers to use a single I/O card, or the CNA, which is putting the traffic onto the converged fabric?

I’m probably missing something huge here, some vital piece of information that would make sense why FCoE and MR-IOV would be considered competitive standards/specifications. Without that information, though, it just doesn’t make any sense to me to compare these two different yet complementary technologies. Someone want to enlighten me?

UPDATE: I’ve corrected my use of “Data Center Ethernet” to Converged Enhanced Ethernet (CEE) when referring to the IETF standard. As correctly pointed out in the comments, Data Center EthernetTM is a Cisco trademarked term referring to their implementation of CEE.

Tags: , , , , , ,

Miscellaneous Tidbits

Friday, May 12, 2006 in General by slowe

I have a variety of miscellaneous tidbits to mention, in case you haven’t already heard about them.

  • ODF for Microsoft Office:  Now that OpenDocument format (ODF) has been approved as an ISO standard, the OpenDocument Foundation has announced a plug-in for ODF that allows Microsoft Office (as far back as Office 97) to open, render, and save files as ODF.  This, in my opinion, is a great thing, as it allows those organizations that can’t use an alternate office suite to still take advantage of open file formats.
  • Vista’s Security Implications:  While Microsoft touts the impressive security benefits of Windows Vista, others are disagreeing.  A recently published report believes that the new security measures interfere so heavily with users that they’ll end up getting turned off.  Furthermore, the new features and their administrative overhead will likely cause significant delays in the adoption of Vista.
  • Resource Manager Web Interface:  Jason Conger has released the Web Interface for Resource Manager.  If you use Citrix Resource Manager, this is a must-have add-on.
  • Virtual Security:  Joining Reflex Security (which unveiled its Reflex VSA virtual appliance a while ago—I hope to be able to review/demo this product soon and will provide more details here when that happens), Astaro has announced the Astaro Security Gateway for VMware.  The cool part is that users are encouraged to download a trial copy from Astaro’s web site.

Tags: , , , , ,

OpenDocument Gets ISO Approval

Wednesday, May 3, 2006 in Interoperability by slowe

Mark one up for cross-platform standards:  the OpenDocument format, an XML-based file format originally derived from work on OpenOffice.org (and Sun’s StarOffice) has been officially approved as an ISO standard.

There are numerous announcements of the approval—this eWeek article, which initially alerted me; this press release at the OpenOffice.org web site; and this blog entry by Andy Updegrove, a participant in the standardization committees.

Of course, Microsoft continues to push its Open XML format as an alternative to ODF.  The push for ODF was never really about taking power away from Microsoft, though; it was really about moving documents and records and information into a format that isn’t controlled by a single vendor.  With ODF as an ISO/IEC standard (and likely to see much broader adoption now as a result), organizations don’t have to worry about changes in file formats suddenly wreaking havoc with years of accumulated documents.  If the application(s) they use with ODF are Microsoft Office, StarOffice, KOffice, or OpenOffice, who cares?  It’s not really about the application, it’s about the data.

Tags: , ,

Problems with 802.1Q

Tuesday, March 14, 2006 in Macintosh, Networking by slowe

I stumbled across a forum on Apple’s web site this morning (referred to me in turn by Derrick Story’s request for MacBook Pro feedback) that makes me glad I’m not yet able to afford a MacBook Pro.

According to the forum, there is a bug in the Ethernet driver in the Intel version of Mac OS X 10.4 that causes excessive packet loss on networks that employ 802.1Q.  802.1Q, in case you aren’t already familiar with it, is an Ethernet networking standard used in networks that employ multiple VLANs.  Apparently, the Ethernet driver on the Intel-based Macs is incorrectly processing packets as 802.1Q packets when they really aren’t.  This causes excessive packet loss and network connections that are pretty much unusable.

I guess I’ll have to wait for the second generation of Intel-based Mac laptops.  That’s OK, as it gives me plenty of time to get my money’s worth from my current PowerBook G4.

Tags: , , ,

Open Enough for Massachusetts

Tuesday, November 29, 2005 in Microsoft by slowe

Not suprisingly, Microsoft’s moves to “open” up its XML-based file formats for current and future versions of Microsoft Office have swayed the State of Massachusetts back to its side again.  Get the details here.

Tags: ,

Microsoft Promises Not to Sue

Tuesday, November 29, 2005 in Microsoft by slowe

Microsoft recently made a move to “open” up its XML-based file formats for Microsoft Office 2003 and the forthcoming Office 12.  These file formats were offered to ECMA International for consideration as a formal open standard.  However, the “license” for these file formats was merely a promise not to sue people violating its patents on the use of the file formats.  Read more here.

Also see these comments from a legal analyst regarding Microsoft’s Patent Protection Covenant.

Personally, a promise “not to sue” from any large corporation—not just Microsoft—wouldn’t be good enough for me were I a developer.  Somehow, I don’t think that many developers are going to feel completely comfortable incorporating Office 2003/12 XML-based file formats into their applications based solely on the Patent Protection Covenant.  What happens when (not if) the covenant changes?

Tags: ,

Microsoft’s Counter-Move

Monday, November 21, 2005 in Interoperability by slowe

The rallying cry around OpenDocument prompted Microsoft to make its counter-move.  As fully expected, Microsoft is trying to create a standard based on Microsoft’s own (until now) proprietary XML formats.  Please tell me you saw this coming, right?

With companies from Novell to Corel standing in support of the OpenDocument format, a new coalition forming in support of the format, and governments agencies such as the State of Massachusetts requiring the use of file formats such as PDF and OpenDocument, clearly Microsoft was worried.  Otherwise, why try to create an alternate standard of your own creation?  Why not just join the existing standards?  Many are also saying that Microsoft’s decision to include PDF support in the next version of Office is another attempt to keep from being shut out.  After all, Office is a major cash cow for Microsoft, so the company will do whatever it can to provent a loss of marketshare (and revenue as a result).

Tags: , ,

LSB Recognized by ISO

Tuesday, November 1, 2005 in Linux by slowe

News surfaced today that the International Organization for Standardization (ISO) has approved the Linux Standards Base (LSB) as an international standard.  The LSB 2.0.1 core specification has been accepted by the ISO and will be published as International Standard 23360.

In my eyes, this is a big indicator of Linux’s maturity.  Does Linux still need growth in some areas to be more competitive with Microsoft Windows, Novell NetWare, Solaris, or Mac OS X?  Yes, certainly.  And yet, at the same time, Linux has strengths all its own as well.  This recognition by the ISO of the Linux Standards Base serves to further legitimize Linux as a viable and worthy competitor to the proprietary operating systems listed above.

(By the way, you’ll note that I did not include Novell’s Open Enterprise Server in the list of operating systems above because it is, of course, based on Linux.)

Tags: ,

« Older entries