Although I’m a long-time Fibre Channel user, and certainly not the sort of person who denies the capabilities of that hallowed storage protocol, is it really necessary anymore? On Thursday, October 6, I’ll be taking up the challenge and debating Stu Miniman on this very topic as part of the Interop Conference and Expo in New York. Knowing my enthusiasm for iSCSI, organizers Mike Fratto and Howard Marks made me the rebel upstart, leaving Stu to defend the tired old lady!

iSCSI is the challenger for long-dominant Fibre Channel protocol SAN

Let me make it perfectly clear ahead of time: I’m actually something of a defender of Fibre Channel myself! I cringe whenever the “superiority” of Ethernet is raised, but this has more to do with the high standards of typical Fibre Channel SAN implementations than any real technical quality. In other words, it’s fairly straightforward to deploy a high-performance, reliable Fibre Channel SAN and fairly difficult to do the same with Ethernet-based protocols.

That said, I see the era of Fibre Channel coming to an end. 8 Gb Fibre Channel is fairly compelling as an upgrade from 4 Gb, but the jury is out when it comes to 16 Gb or even 32 Gb off in the future. By that time, Ethernet SAN will be widely available and supported, and will likely boast 40 Gb or 100 Gb performance to boot. Who is going to adopt a 32 Gb Fibre Channel SAN when Ethernet is three times faster?

But all of this is the future. Today, the battle lines are drawn between 8 Gb Fibre Channel and 1 Gb or 10 Gb iSCSI and NFS. This is the baseline for my Interop debate. I am not arguing about the future of SAN, or even iSCSI versus NFS. Rather, I am arguing that most businesses would be best served by implementing an iSCSI SAN rather than purchasing Fibre Channel today.

I intend to record and stream our Interop debate, perhaps even real-time. Watch this blog for a recording, and follow me on twitter to see if a live stream is available. See you on Thursday!

© sfoskett for Stephen Foskett, Pack Rat, 2011. | Interop NYC and The Great Debate: ISCSI Beats Fibre Channel
This post was categorized as Enterprise storage, Everything, Personal, Virtual Storage. Each of my categories has its own feed if you'd like to filter out or focus on posts like this.

For more information on earlier updates, see my articles:

• Storage Fixes in VMware ESX Server 3.5 Update 2
• Storage Changes in VMware ESX 3.5 Update 3
• Storage Changes in VMware ESX 3.5 Update 4
  
• Storage Changes in the VMware vSphere 4 Family

One first step is VMware’s whitepaper, “What’s New in VMware vSphere 5.0 – Storage“.

Licensing and Availability of Features

VMware has once again changed the licensing and pricing model, throwing the Internet into a tizzy:

• “Advanced” has been eliminated, moving up to “Enterprise”
• Pooled vRAM entitlements work across the entire vCenter environment
• New features like Policy-Driven Storage and Storage DRS (along with SIOC) are exclusive to “Enterprise Plus” licenses
• VAAI, PSP multipathing, and Storage vMotion are only found in “Enterprise”
• Thin Provisioning and VADP are available regardless of edition

VMware mucked with vSphere licensing again...

Major New vSphere 5 Storage Features

Storage DRS

Storage DRS is the world’s worst-kept secret, with everyone and his brother talking about it for over a year. Like the existing VM DRS capability, Storage DRS creates resource clusters and automatically moves VMs between them. Storage DRS uses utilization and performance metrics to make the call, and has three modes of operation. It sounds awesome, but it’s an Enterprise Plus-only feature.

Storage APIs – Storage Awareness (VASA)

There’s not much information presently, but a VAAI companion is introduced in vSphere 5: The vSphere Storage APIs for Storage Awareness (VASA) is a communication mechanism for vCenter to detect array capabilities like RAID Level, Thin Provisioning State, Replication State, etc. This will come in handy for all the other features in vSphere 5, especially policy-driven storage!

Policy-Driven Storage

Another new Enterprise Plus feature is Policy-Driven Storage. This allows storage tiers to be defined in vCenter based on SLA, performance, and other metrics which are used during provisioning, cloning, Storage vMotion, and Storage DRS. It leverages VASA for metrics and characterization and supports all arrays in the HCL, regardless of whether they’re NFS, iSCSI, or FC. It includes easy compliance status reporting in vCenter as well.

FCoE Software Initiator

Those of us “in the know” about storage expected VMware to add software FCoE support, so it’s no surprise that they did. This dramatically expands the potential FCoE footprint from just the few CNAs already supported in vSphere 4. It appears to be based on Intel’s OpenFCoE, since it shows up as “Intel Corporation FCoE Adapter” in the GUI!

vSphere Storage Appliance (VSA)

VMware enters the virtual storage appliance (VSA) market with their own offering, the vSphere Storage Appliance (also called VSA). Aimed primarily at the SMB market, it’s actually fairly clever, replicating storage between two or three nodes in a cluster for high availability and using NFS for access rather than iSCSI. And unlike the Celerra UBER that so many techies loved, the VMware VSA is ready for production use!

Existing Storage Features Enhanced in vSphere 5

VMFS 5

VMFS has been improved for scalability and efficiency, but the 2 TB limit on VMDKs remains (except for physical RDM). Only storage geeks like me need to worry about the specifics, but suffice to say that VMFS 5 requires less tuning and worrying and ought to scale and perform better thanks to increased maximums and leveraging the Atomic Test and Set (ATS) technology also used in VAAI. For newly-created volumes, there’s no more block size tuning, and alignment issues are addressed.

Storage APIs – Array Integration (VAAI 2)

See also VMware VAAI Storage Array Support in Plain English

VAAI has been revved, bringing back Thin Provisioning Stun (the AWOL “fourth primitive”) and adding NFS support.

There are now five block primitives for VAAI, depending on if you count thin space reclaim. This is really more of a bug fix than anything, since most folks assumed that the existing thin support already reclaimed deleted VMs and vMotioned VMDKs. I’m more interested in the addition of SCSI UNMAP in addition to WRITE_SAME! There’s also some additional T10 support, though I’m not clear on what it is or where it works.

We’ve also got VAAI for NFS environments now. NAS had sweet thin provisioning support even before block datastores, but the new Reserve Space command adds thick provisioning if that’s what you like. We’ve also got Full File Clone, which is like Full Copy for NFS but doesn’t work with Storage vMotion. And there’s some Extended Stats API to bring in more detail on file status. I also hear there’s an API for Native Snapshot Support, but it’s not widely discussed. Finally, note that NFS plugins come from vendors, not VMware as is the case for block VAAI.

Storage I/O Control

SIOC is enhanced for use in Storage DRS environments, becoming aware of the new datastore clusters. It also gets NFS support, and presumably uses VASA for metrics. But it’s still only available with Enterprise Plus licenses.

iSCSI Initiator GUI

The solid vSphere iSCSI initiator gets a friendly GUI for configuration. I like friendly iSCSI GUIs – just ask Microsoft!

Storage vMotion

The mechanism behind Storage vMotion has changed for a third time in as many releases, this time using “Mirror Mode” to mirror writes to in-progress vMotions. It also now supports migration of vSphere snapshots and Linked Clones. This can be offloaded for VAAI block, but not NFS.

vSphere Replication

New in vCenter Site Recovery Manager 5.0 is software-based replication. Although not technically a vSphere 5 feature, this is a major new storage feature in the VMware world. It allows any-to-any software-based storage replication for disaster recovery.

Stephen’s Stance

Once again, VMware added a ton of new storage enhancements to vSphere. With storage rapidly becoming the limiting factor in scalability and performance of virtual machine environments, this is no surprise. Also not surprising is the fact that major features like Policy-Driven Storage and Storage DRS (along with SIOC) are exclusive to “Enterprise Plus” licenses. I can’t blame VMware for making a buck, but it would be nice if more capabilities were available to the small shops!

I’ll be writing on all these features in detail shortly. Watch this space!

© sfoskett for Stephen Foskett, Pack Rat, 2011. | Storage Changes in VMware vSphere 5
This post was categorized as Enterprise storage, Features, Virtual Storage. Each of my categories has its own feed if you'd like to filter out or focus on posts like this.

Mac OS X 10.7 "Lion" lacks many of the storage features we've long hoped for, including ZFS, iSCSI, and USB 3.0

Last week, at WWDC, Apple introduced many of the features found in their next operating system, OS X “Lion”. At that time, I posted an article about the storage features found in this new release, including integrated revision control, a major update to the FileVault encryption package, and additional enterprise storage protocol support. But, like Snow Leopard, Lion still lacks many storage related features, and it doesn’t look like Apple will get around to adding these anytime soon.

A Better Filesystem (ZFS, Please)

See also ZFS: Super File System! and Mac OS X Lion Adds CoreStorage, a Volume Manager (Finally!)

During the development of Mac OS 10.5, “Leopard”, Apple spent a great deal of time working to replace their legacy HFS+ filesystem with ZFS, a much more advanced option. For starters, ZFS would have given Mac OS better reliability and flexibility, and it has been extended to include advanced features for security and capacity optimization.

But the battle between Sun and NetApp over patents related to the development of ZFS cast a shadow over the long needed replacement of HFS+. With Oracle buying Sun and focusing away from infrastructure products like ZFS, Apple seems to have lost interest in replacing their crufty old filesystem.

Instead of adding an advanced filesystem like ZFS, Mac OS X Lion extends HFS+ with versioning and enhanced security. The new Core Data incremental storage technology in Lion would probably have been easier to implement on ZFS, but Apple was able to add it to HFS+, and it will be a lifesaver in the guise of autosave, versions, and resume. The same goes for encryption, with FileVault 2 boasting background full disk encryption, remote wipe, and external drive support.

Those hoping for the integration of ZFS with Mac OS X appear to be out of luck. All components were removed from Snow Leopard, and Lion is moving forward without it. Sadly, this means that Mac OS X still lacks a flexible volume manager, something even Microsoft Windows boasts.

Perhaps the next version of Mac OS X will include friendly volume management features, but it is more likely that Apple will focus away from the filesystem and direct application developers toward the iCloud Storage API. And cloud truly is next-generation storage, making this a leapfrog approach and leaving ZFS in the dust.

Update: Lion does indeed include a full logical volume manager! See Mac OS X Lion Adds CoreStorage, a Volume Manager (Finally!)

USB 3.0: Still AWOL

See also Will OS X 10.7 “Lion” Bring USB 3.0 To The Mac? and my Thunderbolt series

Although Apple may have simply overlooked or neglected to mention it, USB 3.0 apparently made no appearance at WWDC. Thunderbolt is an impressive technology to be sure, and I am bullish on its future application and performance. But “SuperSpeed” USB 3.0 seems poised to seize the baton and become the ubiquitous next-generation interconnect for every day peripherals.

Thunderbolt is a strategic protocol for Apple, and I expect it to rapidly spread across the entire Mac product range. Rather than simply a high-speed interconnect, Thunderbolt will soon enable advanced docking features, as envisioned in my recent post about the iMac as a Thunderbolt peripheral. It will also enable changes to the physical size and shape of laptop and desktop computers and servers, with many suggesting that the next-generation MacBook Air will become the standard Apple laptop.

In contrast, USB 3.0 is simply a performance bump for USB. It is likely that Apple will support USB 3.0 sooner or later, and third-party vendors are already rolling out Mac OS support. CalDigit recently shipped their third USB 3.0 controller for the Mac, and LaCie sells their own “walled garden” card and peripherals as well. I heard rumors that a few vendors are working on Thunderbolt to USB 3.0 bridges and breakout boxes as well.

USB 3.0 will come to the Mac sooner or later, but Thunderbolt is here to stay.

Enterprise iSCSI Support

See also Will Snow Leopard Finally Bring iSCSI To The Mac?

Another technology that Apple has flirted with in Leopard but never delivered is a software initiator for iSCSI, the block storage protocol that runs over Ethernet. We have not heard anything further about iSCSI since 2007, and there was no mention in the Lion introduction either.

Interestingly, Apple did rollout other new enterprise storage protocol options, including NFSv4, DFS, and even integration of Xsan, the Fibre Channel filesystem. Xsan also added ALUA compatible multipathing, a real surprise for storage geeks like me. But iSCSI was nowhere to be found.

This is a real shame, since iSCSI is becoming increasingly common in enterprise storage circles. Convergence on Ethernet is a hot topic right now, and iSCSI for Mac would give exceptional flexibility and interoperability and fit right into the “prosumer” Mac market niche.

Instead, end-users are stuck working with third-party iSCSI initiators, Fibre Channel and Xsan, or NFS. Although I am a fan of their free globalSAN product, Studio Network Solutions does not offer enterprise support for third-party arrays. The other major option for Mac iSCSI is ATTO’s Xtend, which is supported but somewhat expensive. Drobo also offers an iSCSI client for use with their storage arrays, but it is severely limited. An integrated Apple solution would be a welcome addition, both for consumers and enterprise systems administrators.

Stephen’s Stance

Apple is not in enterprise storage company to be sure, and news from WWDC dashed any hopes we had for ZFS and iSCSI support. USB 3.0 seems a foregone conclusion, but Apple seems intent on ignoring it as long as possible. Although I welcome the new storage features included in Lion, it is disappointing that these were left out.

Note that TRIM support was also not mentioned at WWDC, but it is likely included.

© sfoskett for Stephen Foskett, Pack Rat, 2011. | Three Key Storage Features Missing in Mac OS X “Lion”
This post was categorized as Apple, Enterprise storage, Everything, Personal. Each of my categories has its own feed if you'd like to filter out or focus on posts like this.

"FCoE vs. iSCSI" isn't a battle or cage match. Your choice depends on many factors, and is more a reflection of convergence than a religious conviction. (photos by Peter Tsai, @SuperTsai)

My presentation at Interop in Las Vegas on May 11, 2011, focused on the protocols that will underpin converged storage networking in the future. My topic, assigned by network computing editor Mike Fratto, was “FCoE vs. iSCSI – Making the Choice.” Although this sounds like a grand competition between the two protocols, my take on the subject is very far from that idea. Rather than a battle, the rise of FCoE and iSCSI is part of the ascendance of convergence of storage and data networking on Ethernet.

“The notion that Fibre Channel is for data centers and iSCSI is for SMB’s and workgroups is outdated. Increases in LAN speeds and the coming of lossless Ethernet position iSCSI as a good fit for the data center. Whether your organization adopts FC or iSCSI depends on many factors like current product set, future application demands, organizational skill-set and budget. In this session we will discuss the different conditions where FC or IsCSI are the right fit, why you should use one and when to kick either to the curb.”

I began my session by pointing out that I am neither a vendor nor protocol cheerleader and don’t really have a horse in the race in terms of a transition to FCoE, iSCSI, InfiniBand, SAS, or any other protocol.  Frankly, I don’t see this as a race, and I don’t care who wins if it is one as long as IT infrastructure progresses to a more flexible state.

Converging on Convergence

The important aspect of any discussion of FCoE is not the protocol itself but the underlying shift away from specialized storage networks converging on Ethernet. ISCSI began this trend almost a decade ago, and the Ethernet roadmap leaves Fibre Channel in the dust.

I see three key elements converging to bring, if you pardon the pun, convergence of data and storage networking:

1. The wholesale adoption of Intel compatible processing architectures
2. A shift toward open systems (Windows and UNIX) for application processing
3. And the widespread adoption of IP as an internetworking protocol.

None of these “trends” is surprising or even questionable: Intel compatible open systems servers using IP dominate modern data centers.

Given this dominant processing architecture, Ethernet is a logical choice as an interconnect. No other network protocol even comes close to the market share, compatibility, and support for Ethernet.

Then we must consider the factors that drive convergence of networking protocols. After all, we have long seen a variety of different protocols in niches such as storage, voice, video, WAN, clustering, and other areas. But virtualization of servers, the need for consolidation to reduce port count and cabling, and a continuing thirst for better performance makes convergence on a single protocol a logical step for these and other areas of IT infrastructure.

If we converge on Ethernet, much will change both inside and outside the data center. Server managers will see greater flexibility and mobility of virtualized servers and blades, as well as increased performance overall. Storage managers will shift from managing esoteric networking protocols to a focus on data management and array performance. But network managers will bear the brunt of the shift, with a wider sphere of influence and new headaches from workloads that do not behave like conventional LAN applications.

The Performance Picture

Turning back to the face of storage networking, we see that one major driver for convergence is pure performance. Although Fibre Channel has an impressive roadmap, with performance doubling again and again, it can’t hold a candle to Ethernet. With historical leaps of an order of magnitude and performance, Ethernet will soon leave Fibre Channel well behind.

When iSCSI first appeared, it was hitched to fairly unimpressive Gigabit Ethernet even as Fibre Channel networks made a transition from 2 to 4 Gb. But iSCSI made a quantum leap in performance this year, transitioning to 10 Gb Ethernet even as Fibre Channel networks moved to 8 Gb. ISCSI FCoE will continue benefiting from Ethernet performance improvements in the coming years, transitioning to 40 Gb and 100 Gb. This will make 16 Gb and 32 Gb Fibre Channel look slow by comparison.

One area that is often overlooked in terms of performance is latency of I/O operations. Although iSCSI over 10 Gb Ethernet can carry 50% more data than 8 Gb Fibre Channel (thanks to more efficient encoding), it also benefits from drastically lower latency. It can handle 50% more packets than 8 Gb Fibre Channel or 10 times as many as Gigabit Ethernet. In other words, in a shared virtual environment, 10 Gb Ethernet allows more systems to get more work done in the same amount of time.

Ethernet Enhancing Data Centers

But performance is only half the story of converged Ethernet. It also supplies server connectivity, reducing the all too frequent situation where configuration and location of servers is dictated by cable availability rather than application need. This will change the face of the data center, encouraging the use of blade servers, virtualization, and flexible (dare I say “cloud”?) infrastructure. It will encourage mobility of machines, especially virtual ones, and demand new networking protocols like OpenFlow.

Ethernet required a serious upgrade to handle this workload, however. Although iSCSI works fine over just about any network, thanks to TCP/IP, FCoE and similar protocols require flow control and guaranteed lossless data delivery. This led to the development of data center bridging protocols (DCB), including priority flow control, bandwidth management, and congestion management. With the first two of these now widely available and the third following shortly, Ethernet is ready to take center stage.

FCoE vs. iSCSI

With discussion of convergence out of the way, we can finally talk about making the choice between iSCSI and FCoE. There are four main reasons to choose one protocol or the other:

1. Data center strategy
2. Performance needs
3. Desire for compatibility
4. Cost concerns

Each of these is a valid reason to pick FCoE or iSCSI in any given situation, and none is a drop–dead decision-maker. There are cases where FCoE will be cheaper than iSCSI and vice versa, for example.

Regardless of the choice between these two protocols, one element remains the same: SCSI. Nearly every enterprise block storage protocol is based on SCSI, and it is one of the seminal technologies that enabled the development of enterprise storage as an industry. Every enterprise block storage protocol, including FCoE, iSCSI, SAS, and plain old Fibre Channel, is really a transport for SCSI.

This makes the selection of protocol less relevant to operating systems and applications, since all will “see” storage the same way. There are major differences between the three SAN protocol choices, in terms of routability, availability of host and initiator hardware and software, maturity, and the availability and selection of management tools.

iSCSI has a more robust support matrix than Fibre Channel over Ethernet, with hardware and software drivers available for nearly every operating system. It is widely supported with mature storage systems available from nearly every vendor. Green field SAN designs with no existing Fibre Channel infrastructure should look no further: iSCSI is a great choice for new storage networks.

The selection of FCoE, on the other hand, is more about evolution from Fibre Channel in enterprise storage networks. There is a threefold path for Fibre Channel architects: They can continue with end-to-end Fibre Channel, and Ethernet and FCoE at the edge, or attempt to build out an end-to-end FCoE SAN. This last option is only recently possible, and is by far the least popular model for Fibre Channel architecture at the present time but will become dominant eventually.

Making the Choice

There are good reasons and bad to pick one protocol over the other, and none rises to the level of religious conviction one might see perusing blogs and tweets on the subject.

FCoE is an evolutionary transition for organizations that already have a large installed base of Fibre Channel equipment, tools, and skills. These environments can incrementally adopt Ethernet as an edge protocol while they continue to leverage the enterprise Fibre Channel storage arrays they already own. Strategically, FCoE makes perfect sense for users of “blocks” or “stacks” from vendors like Cisco, EMC, HP, and NetApp. But FCoE remains somewhat unproven, and some supporting protocols, like congestion notification and so-called Ethernet fabric technology, are immature at best when it comes to interoperability.

One common refrain when comparing FCoE and iSCSI is the efficiency of the protocols. Packaging SCSI in TCP and IP can’t be efficient, can it? But an analysis of the protocols reveals that absolute bit efficiency is very similar between Fibre Channel, FCoE, and iSCSI. Tests by Dell’s Tech Center and others show that iSCSI is fairly efficient in terms of data throughput and CPU utilization as well.

Stephen’s Stance

iSCSI is an excellent choice in situations where Fibre Channel investment is nonexistent or badly in need of wholesale upgrade, while FCoE is likely to take over in high-end enterprise shops

iSCSI is an excellent choice in situations where Fibre Channel investment is nonexistent or badly in need of wholesale upgrade. It will continue to grow based on ease of use, low cost and high performance, and widespread support, in the transition to 10 Gb Ethernet could not be simpler. FCoE, on the other hand, is likely to take over in high-end enterprise shops. It is relentlessly promoted by major vendors, and it seems that they will force the upgrade eventually. But some areas are still not ready for prime time, and buyers should beware of grandiose promises at this point.

In counterpoint, one may ask the question of why we chose Ethernet at all. It required much work, and unnatural acts like DCB, to prepare Ethernet to become the dominant protocol for convergence. Why not use InfiniBand instead, since it already works, has widespread implementation, excellent performance and scalability, as well as interoperability and hardware availability? Price is one concern, but the major factor is far more basic: No one doubts that Ethernet will eventually ascend and overcome its obstacles. It is a foregone conclusion.

In retrospect, many alternative protocols might have been better suited to convergence, including ATM and even Token Ring. Although the topic of Fibre Channel over Token Ring (FCoTR) brings a smile to the faces of network and storage nerds everywhere, we all expect that fiber Channel over Ethernet (FCoE) and iSCSI will rule the day.

Photos by Peter Tsai

Watch the presentation from Interop (apologies for the poor camera angle and sound!)

© sfoskett for Stephen Foskett, Pack Rat, 2011. | FCoE vs. iSCSI – Making the Choice
This post was categorized as Computer History, Enterprise storage, Everything, Features, Virtual Storage. Each of my categories has its own feed if you'd like to filter out or focus on posts like this.

The Iomega StorCenter PX4 is both an evolution of the older IX4 and the start of a new line of business-focused devices

Iomega today announced a new line of small desktop and rackmount storage devices. The PX Series addresses many of the limitations of the IX line, bringing high-performance CPUs, SSD, “bring your own drive” options, and “personal cloud” data protection. But the PX will not replace the recently-refreshed IX; instead, it segments the market between home office (IX) and small business (PX).

A Look Back At the IX

I have been ambivalent about Iomega’s IX line of StorCenter devices since they appeared in 2009. Although they bring impressive features like iSCSI and multimedia at a low cost, devices like the ix4-200d in my lab left me wanting more. This was especially true in the area of performance, where the 4-drive ix4 delivered a mediocre 25-30 MB/s of iSCSI throughput in my testing.

The core issue for the ix4 was its reliance of an under-powered embedded CPU and modest 512 MB of integrated DRAM. It was nice to have a sub-$1000 iSCSI array for VMware ESX and Microsoft Windows Server testing, but there was no way I would deploy it in a production business environment. The performance issue was addressed with the ix12-200r, but it came at a steeper price and that rack-mount device was not intended for use outside the data center.

Another concern about the IX was its dizzying set of features. One got the feeling that EMC’s engineers were given free rein when adding features to the StorCenter’s “LifeLine” platform, and the result was something of a mess. This improved with each successive release, but the IX feels like a servant of too many masters: Is it a home multimedia device, a security server, an office file server, or an iSCSI target for virtualization?

PX: A New Level of Performance?

The PX changes everything, or appears to at least. Clearly aimed at the small business and remote office market, the PX promises an enterprise feature set and the horsepower needed to deliver serious performance.

		PX4-300d	PX6-300d	PX4-300r
Form Factor		Desktop		Rack-Mount
Disk Slots		4	6	4
CPU		Intel Atom D525		Intel Celeron
RAM		2 GB SO-DIMM

Let’s start with the brain. All StorCenter PX devices include a dual-core Intel CPU: An Atom D525 in the PX4 and PX6 desktop models and a Celeron multi-core in the rack-mount PX4. All three models also feature 2 GB of RAM, and SSD can be used for high-performance applications. The StorCenter operating system should perform much better on this platform, which is reminiscent of the existing ix12 array. Expect that device to be refreshed shortly with SSD support and perhaps a Sandy Bridge CPU.

The new devices have been completely redesigned mechanically. The PX4 is similar in total volume to the IX4, though it appears smaller since it is taller and skinnier. The PX6 is a veritable tower, while the rack-mount PX4 has a conventional look but adds an optional swappable power supply and redundant fans for datacenter use.

Flexible Drive Options

Iomega has added "bring your own drive" capability to the PX line

There are three firsts in terms of drive support:

1. Iomega has added a “bring your own drive” (BYOD) option, allowing end users to buy an empty or partially-populated PX device and add supported drives in the future. The software does not support dissimilar drives as flexibly as some competitors, but this lowers the price point substantially.
2. The PX Series supports solid state drives (SSDs), as we will discuss in a moment.
3. Finally, the included drive carriers now support 2.5-inch drives, though capacity and price points make this less interesting except when it comes to SSDs.

This is a big step forward for Iomega, who has long required their own drives to be used in these devices. Iomega will ship 1, 2, and 3 TB Hitachi 7200 rpm Deskstar drives at first, but may add other options in the future. I expect a low-power “green” drive from Seagate or Western Digital.

The PX Series approved vendor list (AVL) includes many popular options, including the Hitachi Deskstar, Seagate Barracuda (including the LP line) and Western Digital Caviar and Green. The company has created an area in their support forums for customers to discuss other drive options, though only AVL-listed drives are supported. Since many of these drives are 4K natively, the PX Series should have no trouble with the shift to Advanced Format.

SSD Ahoy!

The introduction of solid state disk (SSD) storage is a major step forward. Iomega will use the excellent Micron C400 (aka Crucial M4) SSD in 128 or 256 GB capacity points. These  are installed in pairs and will typically be used as a RAID 1 mirror for performance-sensitive data. The best application for the SSD, therefore, is the 6-bay PX6-300d, along with a 4-disk RAID 5 set.

There is no automated storage tiering or SSD caching in the Iomega PX series. Administrators simply create RAID sets, LUNs, and shares on SSD or HDD and manually place data there based on need. It is possible to leverage the StorCenter’s included “copy job” functionality to create a rudimentary tiering system, but it seems likely that most users will rely on manual data placement.

It will be interesting to see what the combination of the dual-core 1.8 GHz Atom CPU and C400 SSD will offer in terms of performance. This represents a “maximum speed” configuration for the Iomega device and will likely set a new benchmark in the segment. Although just two Gigabit Ethernet ports are available for connectivity (no 10 GbE or USB 3.0), iSCSI and NFS performance should be very respectable. Iomega tells me they will be demonstrating a VMware VDI “boot storm” scenario using a PX6 with SSDs at EMC World next week.

Updated Software

Beyond the hardware, Iomega has revved the LifeLine software stack for performance, features, and integration. Iomega previewed many of these updates in the “Cloud Edition” versions of the IX2 and IX2 products earlier this year. This includes a cleaner interface as well as “Personal Cloud” software for SOHO or small business users.

The Personal Cloud is pretty clever, allowing different devices (StorCenter, IX Cloud, PX, PC and Mac) to share data using a peer-to-peer architecture. Desktop users experience Personal Cloud similar to Dropbox, using Explorer or Finder to mount a volume for drag and drop copies. This Iomega technology can be accessed remotely or scripted for data distribution between locations.

Owners of older Iomega IX devices can’t officially upgrade to Personal Cloud, but I’m told it is possible. Call the support team and ask for help. Sadly, this upgrade is destructive to data, so back up first!

One important change (necessitated by the BYOD option) is that the LifeLine operating system image is stored in (and executed from) flash rather than on the disks. The iSCSI stack finally supports SCSI-3 persistent reservations and trusted domains for clustering, and Iomega also promise that the updated iSCSI target software performs better with simultaneous file and block traffic.

Pricing and Availability

The PX Series is shipping to resellers now, and will be in end-user hands next week. Pricing is up from previous offerings, but still reasonable, especially in BYOD configurations. CDW has an exclusive on the pre-populated models, but others will sell BYOD versions (and the pre-populated arrays after 30 days).

Iomega will continue to sell the IX lineup for SOHO users but will focus on the PX for business and server use cases.

Stephen’s Stance

The StorCenter PX line is a major step forward for Iomega. The BYOD option is welcome, as is SSD performance and improved specs. With official Citrix XenServer, Microsoft Windows Server, and VMware ESX support, the PX is finally up to the task of business computing. We look forward to putting these new devices through their paces in the future!

Strategically, it makes sense for Iomega to segment their “network storage” offerings into the home/home office-oriented IX line and business-focused PX series. I would prefer even stronger differentiation and perhaps the elimination of home media features from the PX line. It pains me to mention it, but perhaps the IX no longer needs iSCSI support, since it was so woefully underpowered and unable to deliver on the promise of block storage. At least these features should be de-emphasized since they don’t appeal to the intended audience of the products.

© sfoskett for Stephen Foskett, Pack Rat, 2011. | Iomega StorCenter PX Series Preview
This post was categorized as Apple, Enterprise storage, Features, Virtual Storage. Each of my categories has its own feed if you'd like to filter out or focus on posts like this.

Servers, storage, and networks may be interconnected, but most large IT organizations keep the administrative teams from mixing. But the next-generation virtual data center might change that!

Lots of my IT infrastructure management clients are talking about how the advent of Ethernet/IP and virtualization is changing the roles of storage, server, and network administrators. The evolution of the storage role in particular in enterprise IT organizations has been a topic of particular interest to me for a while: I definitely remember thinking about this as iSCSI and Cisco came on the scene a few years back, but the question of integration of storage, server, network, and application management areas is as old as IT.

Back in 2005, I wrote a column in Storage magazine, asking Who Watches the SAN? Although there were (and still are) reasons one might consider handing SAN management over to the network team, such as the use of iSCSI, Cisco FC, or (soon) FCoE, I concluded that many network teams just aren’t ready to take on SAN management. Storage is different – extremely sensitive to latency and outages and burdened with interconnect concepts that are similar, but not identical, to their network cousins. So most people are better off leaving SAN management in the hands of storage people, regardless of whether their SAN is made up of FC or iSCSI.

The Virtual Data Center

Things are changing, however. The modern data center is evolving to virtualize all three major IT infrastructure components: Servers, storage, and networks. Over the last year or so, we’ve seen the first fully-virtual infrastructure built, with all three areas combined in a single box, soup-to-nuts. Consider a VMware ESX server with virtual servers talking over virtual networks to a virtual storage array from FalconStor or LeftHand – it’s an entire data center in a box!

Server admins are normally tasked with everything “in the box”, including VMFS and virtual network connectivity, just as they always had to manage volume managers and path management software back in the “physical server” world. I doubt this will change. So we could see not just storage but network folks excluded entirely from the next-generation virtual datacenter!

This doesn’t have to be how things end up, though. I strongly believe that network and storage pros have critical insight into their areas, and cutting them out would be a tragic loss akin to what happened when open systems folks decided not to pay attention to the lessons of the mainframe generation. We would effectively repeat a decade of experience and learning that could, with minor modifications, be brought right into the modern world.

There are three things to do:

1. Re-combine the stovepipe IT infrastructure organizations (server, storage, network) into a single management organization with specialists in these areas and others like virtualization and cloud computing.
2. Spend the time and money to cross-train everyone to re-apply their experience and skills in this new world. Storage folks, for example, must know a good bit about server virtualization or their skills will have much less value!
3. Bring the mainframe, security, and records management folks to the party, too! They all have essential insights, and a failure to give them a seat at the table would be a critical loss.

Database and Applications

Then there are the DBAs and IT application folks. These teams have always been held at arms-length in the open systems world, and much closer on the mainframe side (especially the database people!) I think there has been a feeling that there were enough interests at the IT infrastructure planning meetings already without mixing them in as well! The current response is a service-based approach, where IT infrastructure adds an analyst role to develop SLAs and standard service offerings and act as a liaison between ITI and IT Apps.

This is probably enough for a conventional system, but there are changes here as well. Virtual appliances can step right into the apps arena, and the database/storage hybrid devices from Oracle/HP, Netezza, and the rest tromp right through the DBA world. Then there are the “webby dubby” (Web 2.0) storage services/devices like Amazon S3, Nirvanix, and EMC Atmos to consider.

Stephen’s Stance

I think we’re seeing another serious change to the status quo: Right after the data center is virtualized and IT infrastructure is recombined, applications themselves will fundamentally transform, demanding a merger of the current IT infrastructure and IT applications groups. This could all come within five years, or it could be delayed or diverted by organizational infighting and intransigence. It will be very interesting to see how it plays out!

© sfoskett for Stephen Foskett, Pack Rat, 2011. | Changes in Technology Drive Changes in IT Organizations and Roles
This post was categorized as Enterprise storage, Virtual Storage. Each of my categories has its own feed if you'd like to filter out or focus on posts like this.

• My writing:
  • My thoughts concerning HDS following their “blogger day” in London
  • My good friend W. Curtis Preston announced more Backup Central Live! dates; you really ought to go see him!
• Other great stuff:
  • Intel Announces New Xeon 4 Socket CPU (E7); Dell, HP and IBM Slated to Refresh Blades
  • Awesome! Free Microsoft iSCSI Target!
  • Anatomy of an Attack is a forthright and honest statement from an RSA blogger
  • The Impossible Project -new- PX 680 Film is amazing. Just amazing!
  • The Iomega StorCenter ix2-200 Network Storage, Cloud Edition is out
  • Jeff Fry shares his impression of Drobo

Subscribe to my Google Reader feed or follow me on Twitter to see these in real-time.

© sfoskett for Stephen Foskett, Pack Rat, 2011. | Back From the Pile: Interesting Links, April 8, 2011
This post was categorized as Enterprise storage, Everything, Personal, Terabyte home. Each of my categories has its own feed if you'd like to filter out or focus on posts like this.

• We kick off this week still focused on Apple (of course) and their new MacBook Air. Although some have suggested it uses a mSATA or PCI Express Mini Card, it definitely does not. Read Apple’s Unconventional New MacBook Air SSD for more information.
• While we’re at it, I posted a video about How to install an internal Apple SuperDrive in an external USB case. Watch for a post soon!
• Finally, I posted another preview: Iomega Bundles Capacity and Performance in New External SSD Drive
• A blast from the past, (not so) Recent comments about FCoE and iSCSI from a 2007 discussion featuring some big names in storage
• Jay posted Drobo FS – A review – worth a read if you’re looking at the FS
• Then there’s Simon’s excellent piece on Running VMware vSphere on an HP MicroServer
• The Keyboard Cult looks at folks like me who love keyboards (mine is a 1987 IBM Model M)
• Four hidden features in vSphere 4.1 is another great read
• Last there’s the Storage Gorilla with Man Bites Dog – Why IBM (and everyone else) should fear EMC’s acquisition of Isilon Systems

Subscribe to my Google Reader feed or follow me on Twitter to see these in real-time.

© sfoskett for Stephen Foskett, Pack Rat, 2010. | Back From the Pile: Interesting Links, October 26, 2010
This post was categorized as Apple, Enterprise storage, Everything. Each of my categories has its own feed if you'd like to filter out or focus on posts like this.

"Bridging versus routing" brings us to the perennial networking debate: Are low-level protocols better?

Unless you’re “in the know”, terms like “layer 2″ can seem mysterious, making it all the more plausible when someone touts the benefits. It seems logical: “Bare-metal” communication must be better, faster, and cheaper than higher-level “everything over IP” approaches, right? But it’s not quite that simple.

This piece assumes you know something about the OSI model.

Ivan Pepelnjak posted a great overview of the “bridging versus routing” debate (Bridging and Routing: is there a difference?), and Marko Milivojevic posed the question in response: “I’m one of those who doesn’t understand the whole L2 obsession of the modern networking world, but…”

It really is an obsession: Data communications folks continually argue about the merits and trade-offs between high-level network protocols and low-level communications. We hear it in storage all the time: FCoE proponents assume performance benefits, and AoE fans add cost advantages to the mix. But many of these claims are unsubstantiated, and iSCSI and NAS protocols like SMB and NFS just keep rolling forward. If storage over IP is so bad, why does iSCSI work (and perform) so well?

One thing often missing in the “layer 2″ arguments is what’s missing when you skip the network layer. There’s a reason IP is so widespread: It may not be the best protocol ever, but it works really well in a huge variety of situations and there is a vast pool of associated technologies that can be drawn upon when using it.

IP can run over just about anything, from FireWire to SONET, so any protocol using IP can (theoretically) run there, too. I’ve run iSCSI over Wi-Fi and WAN links, and it works great out of the box with 10 Gb Ethernet. Protocols that are tightly linked to a layer-2 protocol face stiff challenges when moving to different data links. Witness the difficulty moving Fibre Channel to 10 Gb Ethernet, including all those data center bridging technologies. In fact, when faced with the challenge of long-distance Fibre Channel SAN communication, encapsulation over IP was a natural choice.

IP also has a myriad of wonderful technologies to choose from. The creators of iSCSI were able to pull authentication, encryption, lossless communication, and many other features straight from the existing toy box. Developers of new non-IP protocols have to invent their own solutions to these problems, often with disastrous results. Why reinvent the wheel? Just apply a little CHAP, some IPsec, and roll it in TCP and you’re done!

Photo credit: “Akashi Kaikyo Bridge 明石海峽大橋” by Shenghung Lin

© sfoskett for Stephen Foskett, Pack Rat, 2010. | The Lure of Layer 2
This post was categorized as Computer History, Enterprise storage, Gestalt IT. Each of my categories has its own feed if you'd like to filter out or focus on posts like this.

Fear

Back when I used to teach the “Storage 101″ session at Storage Decisions, I was consistently amazed to find little awareness of enterprise NAS systems. People complained about LUNs and Fibre Channel but when I suggested using NFS or SMB their heads almost exploded. “We would never use that for application storage,” they shouted. “File servers are for home directories, not data center stuff!” Clearly, NAS faces an uphill battle.

In a recent piece I wrote, I referred to what I consider to be the prime best practice: Use the right tool for the job. It’s a simple statement, and one that resonates beyond IT and the technology world. But it can be devilishly difficult to see what the right tool is sometimes. Why not use NAS for virtual machine storage? NetApp has been beating that drum for years, yet NAS has a very small footprint in VMware. How about databases on NFS? Exchange over SMB? Block storage has a massive lead over NAS in all of these areas.

Rear this “best practices” piece, Use Process Solutions For Process Problems, Technical Solutions For Technical Ones

IT folks seem downright fearful of file-level storage protocols. Has NFS really burned them that badly over the decades? Can SMB/CIFS really be as bad as they think?

Loathing

I wonder if this terror has more to do with the products people have used than the fundamental concept of file services. Many NAS servers (and clients) are barely functional. Sadly, NFS and SMB are easy to get 80% right, but the 20% corner case interaction takes decades to overcome. My daily storage consulting work exposes me to a myriad of NAS configurations, and few of the multi-platform combinations end well.

Note: Although it has long been known by a variety of names, the Windows NAS protocol is currently called Server Message Block or SMB. Common Internet File System (CIFS) was a failed mid-1990′s attempt by Microsoft to make this protocol standard on the Internet.

Consider the Mac. Apple added an SMB client to OS X in 2001 but, despite many updates, it is far from reliable. Mac users in general loathe connecting to Windows file servers, and business users have located numerous bugs in the handling of Mac-specific file types. It’s bad enough that one company, GroupLogic, created an entire AFP server for Windows just to solve these tricky issues.

This situation often happens in reverse, too. Windows admins are justifiably cautious when deploying non-Windows SMB servers, whether software (Samba, Novell, etc) or system (NetApp, Celerra, BlueArc, etc). As a very early NetApp user, I watched their CIFS/SMB server evolve over a decade and a half into a fairly robust solution, but the early years were downright painful.

Lest you throw rocks at Redmond, know that SMB is not alone with functionality problems. The interoperability of NFS servers and clients is a bit better thanks to open(ish) standards and open source implementations, but its reputation is just as bad. And Apple’s proprietary AFP protocol is downright notorious.

I’ve been there myself many times. I tried to set up a home server based on open source software (Linux, FreeBSD, Samba, Netatalk, etc) but rejected it outright after many frustrating years. Today I use a Mac Mini for file sharing in OS X and serving iTunes music and movies (goodbye, Firefly!) And years of fighting with Samba in enterprise environments taught me two things: It’s possible to get it running well with Windows clients but it’s astonishingly easy to get it wrong.

Enterprise NAS?

We all know that interoperability is devilishly difficult. I don’t envy the NetApp and EMC engineers that have to tweak and tune their server for every possible client, bugs and all. And I am impressed that, after probably millions of man-hours of work, they were able to come up with something stable for a subset of use cases. But this just makes me even more cautious about third-party NAS servers.

I talk to storage vendors all the time, and many of their new products support NFS and SMB. But my internal alarms start going off when I hear about these products. There are two simple reasons for this:

1. As mentioned above, NAS is rare in primary data center applications. It may be common for user files (euphemistically called “unstructured data”) and certain distributed applications (simulation, rendering, etc), but most use cases still call for block SCSI (FC/iSCSI) storage.
2. As further mentioned, getting NAS right takes a massive amount of effort. New and small vendors tend to slap Samba on their (Linux-based) box and call it a day. This is very, very far from being sufficient for enterprise use.

This is why I usually ignore NAS functionality in storage systems except for long-tenured and deep-pocketed vendors. Although the world is turning to “Unified Storage” and multi-protocol support, I’m focusing primarily on block (SCSI) and cloud (REST) capability because the former has proven somewhat easier than NAS to get working and the latter is both simple and “green field” with no legacy concerns.

© sfoskett for Stephen Foskett, Pack Rat, 2010. | Why Do I Ignore NAS?
This post was categorized as Apple, Computer History, Enterprise storage, Gestalt IT, Terabyte home, Virtual Storage. Each of my categories has its own feed if you'd like to filter out or focus on posts like this.