Storage @ Work

This story speaks for itself: The Mysteries of SANS part ii

Thanks for posting, Trevor.

Deni Connor at Network World published a column yesterday, capturing the thoughts of technologist Joel Snyder. Here's the link to the Network World article: Network World Column: Is Fibre Channel Dead? I actually saw the story first on Hartmut Wiehr's blog here where there is a permalink: Hartmut Wiehr's posting on "Is Fibre Channel Dead?"

Joel is not a storage guy per se, but a technology guy with a long career who has seen a lot. Here is his profile at Network World: Joel Snyder bio

I'm not sure that I agree with Joel altogether. I do feel that iSCSI will eclipse Fibre Channel relatively soon, but I think Fibre Channel is going to have a longer tail and slower decline than other dinosaur technologies like FDDI and Token Ring- only because the market for storage tends to be extremely risk averse and the process of swapping infrastructures is both risky and expensive. Still I talk to customers every week that have jettisoned Fibre Channel in favor of iSCSI because of the flexibility shortcomings and the relative high cost of owning Fibre Channel.

Two guys, Eric Waters and Ron Whitling running the data center operations for E-Chx, an Internet payroll processing service provider, talking about how EqualLogic iSCSI SAN storage solved their performance problems on SQL Server and the overall ease of use and operations that you get with an EqualLogic SAN.

This is my first YouTube video and therefore also the first time linking a video directly into my blog. It didn't exactly work perfectly and there are several rough edges that I expect to make better in the future. The video ends at the 6 minute mark, but extends into blackness for over an additional minute. I'm not sure why that happened..... Don't be surprised if I re-post this one with a better quality video later this week.

You might need to click twice to make it play.

Solimar Systems is one of EqualLogic's longest standing customers, having purchased their first iSCSI storage system from the company over 3 years ago. I was down in San Diego yesterday and Leo Kameya, our sales manager there took me in to visit Tom Lytle at Solimar on our way to consume mass quantities of sushi together. Solimar provides large scale electronic printing services for companies who need to have PDF versions of traditional print output, such as financial statements, available on demand for their customers. If you have accessed a PDF statement for your bank or credit card, there is a good chace that this data was produced by Solimar.

Tom is a great guy, easygoing and very likable. He showed us around his data center and I took some footage of EqualLogic products at work in Solimar's data center. Maybe I'll put up some of that video, but are few things as dull as watching lights blinking on storage arrays.

What IS interesting, however, is the way that Tom upgraded his first EqualLogic storage system by refreshing (or replacing) its original 250 GB drives with new, high capacity 750GB drives. Usually EqualLogic customers are told that they can add new systems to an existing EqualLogic SAN and that the existing system's data will be spread (load balanced) across the combined volume spaces of the existing and new systems in the group. Tom explained to me how they tweaked this process by creating a two-system group, and then removing the original system from the group. This forced all the data to be migrated over to the new EqualLogic system. After that process completed, the original system was taken offline and the original disk drives were removed and replaced with new drives. With three times its original capacity, the original system was added back to the group and an inverse process was run to restore (remigrate) the data completely back to the original EqualLogic system. Essentially, this is an automated way to perform dump-and-fill storage operations between an existing disk system and its temporary replacement. The kicker in all this according to Tom was that there was never any downtime. The data was online and available the entire time.

Its really quite a cool thing, but it does make it difficult to set meaningful expectations for the lifespan of the product. What is it? - 6 years, 7 years, 8 years, 9 years or more? I really don't know and I suppose its going to be one of those "it depends" things. We're just going to have to wait to find out.

Previously I blogged about Solimar Systems and how they've been a customer for a long time and upgraded the disk drives on an early EqualLogic storage system to new 750 GB drives. So, I made a short video that - well - is somewhat self explanatory. Solimar Systems is a terrific customer with an interesting business and the story is pretty good, the sushi was fresh, but this video leaves a bit to be desired. Here goes:

I just posted on VMotion and iSCSI (and EqualLogic). That got me thinking about this other thread that started before I was writing this blog. People wondering if EqualLogic iSCSI storage could work for their VMware environments might be encouraged by what was witten there.

Today's ANSI news: .......... FC vendors propose FCoE. Fibre Channel Protocol over Ethernet or something like that. Serial SCSI running over Ethernet without TCP or IP. Let's see, that has been tried before with Nishan's SOIP, Adaptec's EtherSCSI and other less well known technologies - and killed off by whom? Most of the companies proposing FCoE. Ironic.

So, if you are a FC vendor and it looks like 10Gb Ethernet is going to be part of the tiger (along with iSCSI) that eats your lunch, what do you do? You resurrect old ideas that you hung five years ago, dust off the corpses, insert zombie brains and call it the new shiny FCoE (Frankenstein Convergence over Ethernet?). The only difference between what you killed yesterday and your unholy experiment today is that this bad boy saves your business. It doesn't really have that much to do with customers, except that you get to squeeze them a little longer.

Here is a link to a TechTarget blog that I agree with.

And in honor of this abomination, here is a link to Tim Burton's Frankenweenie on YouTube .

Dave Hitz at Netapp posted an interesting blog last week where he discussed the confusion that exists regarding storage networks and protocols. At the end, he punted and basically decided that a "customer is the expert" approach is best and that if a customer wants to analyze things a certain way, then it was best just to go along with them. Why bother explaining the fine points between file and block I/O when you can just agree with something that goes against your sensibilities, right? Heaven forbid, why screw up a sales opportunity trying to explain to someone who wants to buy a lot of your equipment that everything they just said was goofy? Yes, I get it, and I have to admit it, I've been there. But Dave, don't you think its a bit of a cop out to say 'I've given up, I'll let them believe what they want to believe' in a blog. Whether we like it or not, there are people who hope to catch valuable insights from guys like us - or at least the occasional entertainment of disagreement. So, in the spirit of both, I'm giving you the WAGGING FINGER OF SHAME.

At any rate, I don't think this SAN/NAS protocol/network stuff is actually all that difficult if you forget the protocol junk and focus on the applications. The first thing is to understand that the network used for storage is just a network that can carry both kinds of traffic, just like a cable TV network can carry video, Internet and voice traffic. It does not matter if the network is Fibre Channel or Ethernet (or carrier pigeons), the network is simply a way to transmit information for a storage application.

Rather than talking about protocols, which can turn an otherwise alert human into Rip Van Winkle, it helps to focus on the two primary applications in storage networks: storing and filing. Think of them as being analogous to video and voice applications running on a cable network.

Storing was historically developed to transmit information between computer systems and relatively unintelligent storage devices such as disk drives and tape drives. This is roughly similar to a TV network where the device receiving the information is an idiot box (television). Initially, storing was done over a bus, whereas television was transmitted wirelessly. As the technologies matured, both were adapted for use over networks. Storing over a network is referred to as a SAN, whereas transmitting video signals over the cable network is called highway robbery. In SANs, the storage device performs the storing function without an awareness of what the information is. Likewise a television has no awareness of what is coming out of its picture tube and speakers. Both simply do what they are told to do (its more like a master/slave thing than a client/server relationship). Where storing is concerned, a system program controls the sequence of operations that determines what information is stored, and what address spaces in the device are used to store it. This system program is usually a file system, a database system or a backup system and it has all the responsibility of knowing how to access the information stored in the device.

Filing applications (or services) were historically developed to transmit data files between intelligent systems, analogous to the way a person can tell a story to another person over the phone. Both file services and the telephone system were developed for network environments connecting multiple intelligent entities. The system that provides the file storing service is called a NAS system, whereas the person listening to the story on the phone is simply called by their name or pronoun such as "yo" or "mom". Both enti COMMENT: AUTHOR: Paula Long DATE: 04/25/2007 12:06:56 EMAIL: plong@equallogic.com URL: Marc, as always, you have given a very thoughtful answer and a clear explanation of the difference between file access and block access to data. Believe it or not, I have talked to smart people who get confused by the difference between NAS and iSCSI SAN. It had nothing to do with the wire and everything to do with how customers' applications access their data. The applications they run access the data using file semantics. On Windows there are very few applications that talk to physical disks (raw devices in UNIX-speak); in UNIX there are fewer that talk to the raw device now than when I did DB work, but still more than zero. The fact that administrators create a physical device then put a file system on it immediately is what muddies the water. With a good SAN implementation, the administrator never views the LUN/disks again. They see their drive letter or a UNIX mount point. So when someone says their applications talk to files, people tell them they must want NAS. It’s historical more than anything else. If you ask a more specific question—for example, do you want to have your database or mail server talk to your storage using NFS or CIFS?—they look at you like you’ve grown a second head. It’s difficult for them to comprehend why you would add that additional unnecessary layer between the storage and the application. Not everyone hears/reads NAS and automatically understands this to mean NFS, CIFS or some other distributed file system protocol. NAS is an overused term that can confuse people. It means Network Attached Storage. When some folks hear “network” they think “Ethernet.” You say “iSCSI,” they hear “Ethernet.” Hence the confusion; our language is precise if you understand the history of the term NAS, and don’t confuse the term “NAS standards” with Network Attached Storage. We should make sure we don’t argue with customers. At the same time, we should make sure we clearly understand what they are telling or asking us. Our definitions and theirs aren’t always the same. So I guess I agree with David that the terms can confuse people. I am not sure that saying “There’s no difference” is the answer, though, since you’ll have one disappointed DBA if she finds her database talking NFS or CIFS to access storage. Paula

Nigel at the RupturedMonkey blog site wrote a post titled "Grrrrr big beefy manly SANs". He talks about a number of things that I think belong as part of a SAN best practices. The post has an interesting confessional tone where he discusses a certain fascination with large and complex networks - something that I think is common in our line of work. One of the things he discusses is limiting the number of ISLs in SANs as a way to reduce problems: I quote one of his paragraphs below:

"One thing that had a real influence on me was some work that I did for a telco company who have a policy of no ISLs in their SAN environments. A lot of people initially sniggle at the idea, and to be honest, I too raised an eyebrow when I first heard this. But I have to say that in their SAN environments problems were noticeably fewer and farther between, and when they did occur they were so much more limited in their scope and so much easier to troubleshoot."

A common mistake people make when thinking about SANs (especially iSCSI SANs) is assuming the same design principals and best practices apply to both LANs and SANs. A simple examination of the requirements indicates profound differences: For instance, with LANs, systems communicate frequently with other systems with the potential for any one system to communicate with every other system, but with SANs, systems usually don't have any reason to communicate with many other systems and storage. In fact, most SANs implement technology and processes to restrict potentially harmful communications. Put another way, LANs assume any-to-any communications whereas SANs assume a need-to-communicate-only operating model.

An excellent strategy for providing a need-to-communicate-only environment is to reduce the number of potential connections. In general, it is difficult to err in the pursuit of restricting SAN communications and this should be a design goal that is carried through the initial implementation and all subsequent changes to the SAN. Pursue policies that limit the number of ports in a SAN.

The use of ISLs should be limited as a way to prevent "connection creep" in the SAN. Core-edge designs with ISLs should not be blindly assumed as the best way to add nodes in the SAN. Instead think about using a single layer of switches that operate in parallel providing a single-hop environment. Stackable switches such as the Cisco 3750 for iSCSI or the QLogic 5200 for Fibre Channel have valuable scalability benefits.

Core-edge designs should be implemented with a goal of limiting the number of hops. The best core edge designs would have two hops between systems and storage. One way to do this is to connect storage ports to core switches and servers at the edge.

Consider using different SANs for disk I/O and backup. For instance, primary disk I/O might require dual paths with independent switches in those paths, whereas backup might only require a single path between servers and backup devices/systems. This limits the impact that backup and restore operations have on production disk I/O operations and solves many of the problems originating from the conflicting connectivity models for primary disk I/O and backup (the connectivity requirements for backup tend to be much broader than the connectivity requirements for disk access). For example, a dual-port HBA/NIC could be used to connect to the disk SAN while a single port HBA/NIC could be used to connect to the backup SAN.

Dave Hitz and I are going back and forth in our blogs, explaining our views on language - specifically the lexicon of storage. Dave's most recent post reiterates the explanation given in his previous post. Apparently he didn't like the fact that I awarded him the wagging finger of shame for willingly blurring the definitions of SAN and NAS.

My take on it still the same. The terms we use stand for something and provide a way for us to communicate complex concepts quickly. When we start polluting the definitions of accepted terms like SAN, for instance, we create confusion about things that are already complex - and this wastes a lot of time. A room full of people discussing storage can make a lot of progress if everybody clearly understands the terms. That same group without a shared lexicon will have a very difficult time succeeding. You can use the word "hammer" to refer to a hammer, a pair of pliers, or a screwdriver; or you could use the word "tool" to generically refer to these things. I think the problem you are having Dave is the lack of a generic term for a network that does "storage stuff". I use the term "storage network".

It has always been a problem in storage networking and I've always thought the term "SAN" was flawed. Let's face it - it was a term adopted by the Fibre Channel industry a decade ago to get the market to identify the technology with a new storage architecture. Your customers will use whatever terms they want to use and I don't particularly care what terms you use with them. However, I think you understand the difference between your role as a thought leader in this industry and your role as a sales support dude at Netapp. If you had written about the need for a better generic term for networks with storage traffic, that would have been a good topic, but instead you wrote about how it doesn't really matter what you call it and suggested we kidnap the term SAN for that purpose. This just creates confusion, which leads to wasted time, arguments, blame and all the other unfortunate things that go on when people don't communicate effectively. The finger wags because you are contributing to the confusion.

Storage-zilla has a post where he points to an EMC White Paper that explains how Netapp Filers make their SAN (block I/O) storage work through their WAFL-based filers.

The same argument the Zilla man lays out here works for EqualLogic of course too. If you are looking for iSCSI performance, make sure you check out EqualLogic iSCSI SAN solutions as well as those EMC and Netapp boxes.

Microsoft just released a document written by Dennis Martin of Demartek showing a variety of iSCSI storage configurations. Here is a link to the PDF from Microsoft's web site:
http://www.microsoft.com/downloads/details.aspx? FamilyID=da150335-2d76-4cc7-9e3b-a95ed688fd2a&DisplayLang=en

Here is a link to a page on Demartek's website where you can download it as a Word file or as a PDF:
http://www.demartek.com/Demarte k_Deploying_iSCSI_Storage_Solutions_2007-06.html

An EqualLogic solution is featured in this document along with solutions from other vendors. I may have some comments about this document in the days to come after I get a chance to look it over.

I'm extremely happy to see Microsoft getting behind all of us, helping to grow the entire iSCSI industry.

Thanks Claude, SW, Suzanne, and all the rest of you in Redmond that are supporting iSCSI!

Anne Silverthorn wrote a pretty decent article in InfoStor about how SMBs can benefit from installing SANs to replace DAS storage. Lots of vendors are mentioned

The employees of Brocade are really tired of the shadow Greg Reyes' trial is casting. I think they deserve a break.

Click To Play

They always do things a bit differently in the UK. This page from the UK's Storage Magazine web site shows storage people carrying on as if they were "normal people". I think Storage Magazine UK deserves an award for pulling that off. EqualLogic was awarded the Storage Virtualization Product of the Year for the PS3900XV. Its not clear to me why this particular product was singled out because all our storage systems have the exact same storage virtualization software. But that's OK, we're happy for the recognition.

We also recently won the top prize in e-Week's Excellence Awards for Enterprise Storage Hardware. for our PS-3800VX . I don't know how long the link will be good, but here is the page on eWeek's site. Again, we appreciate the recognition. Thanks to the customers, readers, writers and publishers who contribute to our success.

In this podcast Farley talks about the problem of managing changes to storage infrastructures.

Here's an interesting and strange article about EqualLogic's first iSCSI SAN customer in Australia. I really don't know much more about the customer, Ranjeet Rustogi or his company Link Communications Group than anybody who follows the link and reads it. In fact, others usually read things more closely and carefully than I do, so by now, they know more than I do about how an EqualLogic disk array made its way down under. Hey Ranjeet, if you see, this, Thanks a lot! Drop me a line sometime.

The thing that interested me most in this article was which one of our incredibly talented and strange SEs made the trip (it was before I started here). I first thought it was the one who consumes mass quantities like there is no tomorrow, then I figured it was the one who believes sleep is an over-rated luxury because there is so much to do while awake. Hmmmm, now I'm not so sure. Whoever, it is, you need to frame that quote from Mr. Rustogi: "The most knowledgeable person I have ever met". I can only hope for everybody's sake that the knowledge transfer he was thinking of when he said this was limited to network storage because I'm sure many other topics may have been - "embellished?"

Here is a callout to my storage homey, Pai, at Riverbed - I saw the press release you issued with John Rhon at the Lifelink Foundation. He is a terrific guy and excellent customer. Moreover, the time critical nature of their business showcases the value of Riverbed's Steelhead appliances. BTW, Pai if you see this - do you think anybody can beat RF at Wimbledon?

Kirk Goodwin the IT Manager at Unicity - and James Rupprecht, the Storage SE at Valcom in Salt Lake City talk about their success working together on the installation of an EqualLogic iSCSI SAN.

Click To Play

Hey Elfshadow, Happy System Administrator Appreciation Day to you too! A co-worker brought Elfshadow's blog - "Life in the Digital Matrix" - to my attention. He had attended the VMWare Users Group meeting near Sandusky Ohio and talked about the various sessions he attended.

In his blog he talks about how Dave Siles from Kane County Illinois presented on their extensive use of EqualLogic iSCSI SANs and how impressed he was with it all. The thing that impressed me was that Dave had been invited to speak to the group about VMWare and VM Users groups (I guess he grew up in Sandusky too - small world syndrome!) and he saw that one of our guys, Tim Sherbak, was going to present and asked Tim if he could present his EqualLogic storage perspective to the audience. Tim's no fool and Dave made a great impression.

That's what's amazing about this company: our customers. I say it over and over again, but we really do have the best customers in the world. Thanks Dave for being such an enthusiastic supporter!

Here is our schedule for VMworld. Many have asked me about the BOF (birds of a feather) meeting. It's going to be at Terra on Wednesday the 12th from 4:00 to 5:00 followed by a customer appreciation party from 5:00 - 7:00. For those that recall last year's party it was a pretty good time. Definitely a lot of energy and excitement around VMware, consolidation and virtualization. I know - it sounds geeky, but if you are into it, there is nothing better. See You there.

I caught up with Chris Fricke, from Clackamas County Oregon and we were talking. I like to say we have the greatest customers in the world and in this video, Chris shows why I say that. Thanks Chris!

Click To Play

Chris Sims from the Clayton County Water Authority in Georgia was a panelist at VMworld today and he talks about their DR setup, VMware implementation and their EqualLogic iSCSI SAN. Like I always say, we have the best customers and it is a joy to work with customers like Chris.

Click To Play

John Webster wrote a piece yesterday in praise of FCoE. Now John is somebody I like to talk to and I usually think his arguments are sound, but I can't disagree with him more on this one. Here's what he says: "it leverages the Fibre Channel protocol’s use of SCSI directly over Ethernet, whereas iSCSI uses a different encapsulation method to send SCSI over TCP/IP, which then usually goes over Ethernet."

The glossing over of the FC protocol is important: FCoE uses the FCP protocol, which is an encapsulation of serial SCSI developed for Fibre Channel networks and mapped instead onto non-routable Ethernet frames. It is not somehow more "natural" as John's statement implies.

There are two key takeaways: 1) FCoE is going to cost a lot of money in fork lift upgrades of data center switches. It doesn't run on your existing switches and its going to be disruptive and expensive to purchase and deploy. 2) John Webster mentions that FCoE developers are missing the ease of management message. It's probably more realistic that they are trying to hide from the management question because management doesn't improve much with FCoE. It uses Ethernet MAC addresses, which are roughly equivalent to Fibre Channel's worldwide names, which are one of the root causes of so much pain installing, configuring and changing a Fibre Channel SAN.

Customers with lots of FC storage want FCoE because they want to maintain their investment in their FC storage systems. That's understandable, but they ought to think through what that means for their virtual server plans. It will probably work, but it might not be as simple to manage or as flexible as one would hope for. After all, who would have predicted that FC was going to be so taxing to manage ten years ago when it was first being deployed? And who would have thought those fundamental management problems would still be unsolved ten years later? FCoE is not pain relief, its the reason SAN administrators will need pain relief.

The best course of action for those customers might be to stick with 4Gb FC and avoid all the disruption and cost.

If there is one thing I really like, its satire. So, I have to point you to this posting:

Actually, I'm not too worried about THAT happening. For starters I expect that Dell values the capabilities of our top notch support organization and their role in building our customer loyalty. More importantly, Dell's business divisions are being recognized as having excellent support as Keycruncher points out.

Adding to the list of comments is Andrew Reichman from Forrester who concludes his posting by saying: "There will be concerns around product roadmap continuity and focus, as well questions about placement of EqualLogic products within the current Dell storage lineup, but these are likely to be minimal in comparison to the strong technology benefits and complementary fit between the two companies". His entire posting can be read here.

Justin (of cmsJustin) writes about his company's purchase of an EqualLogic iSCSI SAN array. He's been documenting his evaluation process on his blog and we're very happy to have Justin as a customer. Thanks Justin for spelling things out on your blog and you made a good move with the 400 GB drives.

Read to the bottom of his blog entry: he's looking for help with dynamic VLAN configuration linked to MAC addresses. If anyone reading this has any insights for him, please jump on his site and let him know.

There's been so much written in the last couple days, its been crazy keeping up. Good crazy though.

Infoworld's Mario Apicella had an article today about the Dell acquisition. Mario likes to dig beneath the surface - in this case he sees well past iSCSI and virtualization to several key benefits our customers enjoy with our technology.

Dan Primack writes a column for Private Equity Hub, a site covering the world of private equity investments and deals. There is an interesting bit of history in his article today on Dell's acquisition of EqualLogic.

Steve Duplessie referred to EqualLogic employees this week as "flannel clad folks", Say that 5 times in a row. The funny thing is, its not that far off. He has a previously unseen photo of our dignified founders on his site here.

There has been a lot of speculation about the future of our channel business when the acquisition completes in a few months and I thought I'd post links to what I'm reading in the bloglands.

Robin Harris, Storagemojo: The Bastards Say Welcome
Barbara Darrow, Tech Target's Channel Market: Dell Seeks Partner Progress in EqualLogic Buy
The Var Guy, TechIQ: Will Dell Push Storage Through Partners?
Joseph Kovar, CMP: VARs say Dell's EqualLogic Acquisition Could Backfire
Edward F. Moltzen, CMP: Dell Bags EqualLogic for $1.4 Billion, Says Deal Will be Channel 'Catalyst'
Dan Bricklin, Theirway.net: Congratulations Don Bulens and Equallogic
Sharon Lisenbach, Eweek: Dell: EqualLogic Buy Validates Channel Commitment
Brad Anderson, Direct2Dell: Dell to Acquire EqualLogic

I've received a couple emails now about a bizarre web slideshow that eWeek is linking to in their editor's pick newsletter. It's called "10 Things You Should Know About iSCSI"

There's so much wrong with this that its difficult to know where to start. Maybe, there should be parallel slideshows pointing out the hazards of eating meat (choking, high blood pressure, pets disappearing, etc.) or gardening (bee stings, falling tree limbs, impaling oneself on rusted pitchfork tines, etc.) It has a blatant FC bias. BTW, just imagine if someone tried to enumerate the things you need to know about Fibre Channel. Could they do it?

One slide says: "Don't believe the ease-of-use claims. Yes, the vendors will claim that there's "one-button" setup. Even if everything works exactly as it should, it still takes more than one button." Ummmm....... and careful dialing those 10 digit phone numbers!

Then there is the slide suggesting that the Microsoft iSCSI initiator is risky (remember to chew that meatball before you swallow it). If you haven't used it, you might not know that it is one of the easiest and most stable pieces of SAN host-based software ever developed.

The last slide I'll comment on is the one titled, "It may not save you money". It says: " But even under ideal circumstances, you'll need four iSCSI connections for every Fibre Channel connection, unless you're using 10G Ethernet. And, of course, 10G Ethernet is really expensive, too." OK, and which is faster - a car going 15 miles an hour or a train going 15 miles an hour? People often make the mistake of confusing bandwidth and transmission speed. Even though iSCSI over Gigabit Ethernet has a quarter of the bandwidth of 4Gb FC, there are rarely bandwidth or performance problems with iSCSI. That has been a very pleasant surprise to nearly all iSCSI customers. In addition, automated load-balancing with iSCSI acts as a bandwidth multiplier.

The value of the press in the Internet era is vetting. This piece should have been sent back for more scrubbing and objectivity.

Here are links to a couple pieces that showed up in the last 24 hours regarding Dell's acquisition of EqualLogic. Both reflect the writer's intent to present fresh, thoughtful perspectives.

The first is by longtime technology editor Bill Snyder in his InfoWorld blog, Tech's Bottom Line, where he combines technology and financial analysis.

The other is from ZDnet Australia, where author Liam Tung provides regional commentary. I always appreciate the candor from down under.

Chris Preimesberger wrote about the Dell EqualLogic news @ Channelinsider.com.

Tony Pearson, storage blogger for IBM, wrote about the impact on the rest of the industry from the Dell EqualLogic aquisition. As Tony likes to do (and what he's paid to do), he turned it into a platform for talking about IBM's storage products.

I want to correct him on his EqualLogic history. Apparently after surfing or talking to IBM market researchers he came across news that we had signed an agreement with Sun several years ago. Figuring that such a deal must have been an important part of our rapid growth he pieced together an odd collection of Jabberwocky on the topic. What he didn't surmise was that the Sun EqualLogic agreement turned out to be one of those worthless pieces of paper that mostly wasted human and natural resources.

The real story is that we have been 100% focussed on selling through our VAR channel for a couple years now since our fearless leader, Don Bulens, came aboard. FWIW, Don doesn't really care for the spotlight much but he needs to be given credit for making this business transition - without our committed channel business model, I don't think Dell would have paid $1.4B in cash for us. These types of transitions sound easy when you read about them, but they aren't that easy when you are the one steering the boat through the rapids.

Here we go again on a new transition - one that will be much more visible to industry observers than our apparently mysterious past.

This post is for people wondering how to set up iSCSI drivers for Solaris.

It has not been tested or approved by EqualLogic. I'm just passing along a link that looks like it would be useful to blog readers. Please send any comments about its contents to the author on the Weibeltech site.

Ezra Wiesner from the Kimmel Center in Philadelphia talks about using EqualLogic iSCSI SAN storage for their SQL server and video applications. The audio on this interview is a bit screwed up - my apologies.

Check out their online media player for events and artists appearing during the 2007-2008 season. Extremely cool!

Note: The web video service I use for this blog appears to be having some performance problems - I don't know how long this will last.

Click To Play

EqualLogic announced its support for Microsoft's DPM 2007 today.

DPM 2007 appears to have excellent data recovery capabilities for Microsoft servers, using VSS writers to ensure data integrity during data protection operations.

Here's a link to a video presentation