Search results for 'app:weblogs' matching tag 'iscsi'

Boot from iSCSI – We’d like your $.02

DELL-Jeff S — Thu, 22 Oct 2009 05:00:00 GMT

Our storage interoperability lab team is taking a look at updating a boot from iSCSI document found here. If you consider the possible scenarios (four different supported array types and multiple supported server/NIC combinations across the supported OS's (W2K3, W2K8, W2K8R2, RHEL, SLES) you start to get a feel for the challenge of creating and maintaining up to date content across all potential Dell supported configurations.

That’s where you come in. The Interop team would love to hear your real world datacenter management perspectives on this. What configurations do you think we should look at first? Why and where do (or would) you boot from iSCSI?

You can comment at the end of this blog, or on our forum section where I’ve started a thread. Not only do you get to influence development of our support content, but there’s also a DellTechCenter.com t-shirt for the best one or two responses.

(Wookie suit not included.)

The Search for SANity: Comparing FCoE and iSCSI

DELL-Jeff S — Wed, 21 Oct 2009 05:00:00 GMT

For those of you who would enjoy a little balance to all the FCoE buzz in the industry, let me introduce you to Robert Winter and Gaurav Chawla - two of Dell's strategic engineers in this space.

Read below for their take on the realities of FCoE. Thanks again, guys.

Robert Winter Gaurav Chawla

FCoE has been positioned by some as a future primary data center fabric and by others as simply a transitional technology. We believe that the ultimate position of FCoE will probably be somewhere between these two extremes. At this point, FCoE is not a full-formed solution and will probably require several years to achieve the same maturity level as iSCSI or FC.

The fact is that FCoE represents an attempt to completely detach an existing, purpose-built storage protocol, namely Fibre Channel (FC), and move it to a completely different physical fabric, Ethernet. To say that this migration is seamless ignores some very real practical challenges.

Let’s take a look at the technology facts.

The FCoE Storage Protocol and the OSI Model Are Not The Best of Friends

The OSI Layered Model (Open Systems Interconnect) is a well-known architectural abstraction that helps to describe the operation of protocols. In looking at FC, FCoE, and iSCSI, one consideration that mustn’t be lost is that Fibre Channel protocol layers cannot be mapped to OSI layers in a straight forward manner because the FC protocol originates from a much different historical context. FCoE, which leverages the FC protocol, has an inherent awkwardness when applied to Ethernet networks that iSCSI does not. The iSCSI protocol, which originated from a traditional Ethernet and IP environment, was designed with those technologies in mind. (Figure 1)

Figure 1: Storage Protocols mapped to the OSI model

Fibre Channel is a layered protocol and may consist of 5 layers if all are implemented. iSCSI is also a layered protocol but folds more easily into the OSI model and has a determinate and consistent implementation. The iSCSI layer can be interpreted as an application protocol that exists over a native TCP and IP infrastructure. SCSI can then be thought of as a presentation layer as it adapts data to an iSCSI format and the iSCSI layer adapts SCSI messages to the TCP/IP protocols.

FCoE Needs DCB to Work

There’s been an unfortunate blurring of FCoE and the standards that attempt to evolve Ethernet fabrics to the point where they can better support a lossless network, namely, DCB (Data Center Bridging), DCE (Cisco’s version of DCB; Data Center Ethernet) or CEE (Brocade’s version of DCB; Converged Enhanced Ethernet). Data Center Bridging improves the Ethernet fabric irrespective of what protocol (be it iSCSI, NFS, TCP or FCoE) runs over the top of it. The important qualifier here is that FCoE won’t work at all without this new type of Ethernet. iSCSI works with any Ethernet but the same benefits that come from DCB may also accrue to iSCSI when running over a DCB network. You don’t need FCoE to have DCB but you MUST have DCB to support FCoE.

FCoE Lacks Native Routing

FCoE is deployed on a layer 2 Ethernet network and does not seamlessly work across WANs or IP subnets. Both FC and FCoE require the use of other companion protocols to connect multiple FC or FCoE SANs. FCIP (Fibre Channel over IP) and FC-IFR (Fibre Channel Inter-Fabric Routing) are two such protocols. FCIP is well defined and it tunnels FC over IP to connect two FC fabrics. However, it is not widely deployed in practice. FC-IFR is another protocol, currently under development.

FCoE is More Expensive

There is a fork-lift upgrade for FCoE – new switches, new adapters, new software and, at some point, new targets. See Figure 2.

Figure 2: FCoE fork-lift upgrade

Several additional cost components come into play with FCoE. FCoE switches are more costly due to additionally needed functionality and they require access to FC services, either co-located on the switch or accessed via a remote FC switch. The only reusable component is the FC target and possibly some FC switches.

FCoE Requires New Hardware

Figure 3: FCoE New Hardware transition

There are several components that need to be deployed for an FCoE SAN. This is necessary because FCoE is a new protocol that maps FC onto a non-FC link layer and that link-layer (Ethernet) does not have the same capabilities as the FC physical layer. See figure above.

The focus of the first version of the FCoE standards specification (FC-BB-5) was to allow FCoE initiators (FCoE enabled servers) to connect to existing FC SANs via Ethernet. This requires both DCB capabilities and FC services to be available on the Ethernet network. In the initial deployments, there is a single link hop on the Ethernet network. FCoE enabled servers run a new adapter called CNA (Converged Network Adapter). The CNA runs FCoE initiator functionality in the firmware or as a combination of software and firmware. The FCoE initiator connects to the edge switch via Ethernet. This edge switch is typically a Top of Rack (ToR) switch. It supports DCB functionality to ensure there are no packet drops on the CNA-to- switch link. The edge switch also contains FCF (FCoE Forwarder) functionality. i.e. it contains both DCB Ethernet and native Fibre Channel ports. The FC ports connect to an FC-SAN. Due to the above components such a single hop deployment requires new CNAs and switches (FCoE Forwarder). The Cisco Nexus 5000 is an example of such a switch. Since 10GBase-T is not widely available these deployments use SFP+ direct attach schemes for cabling.

As a next step in its evolution FCoE may evolve to multiple hops on a DCB network. As the DCB standards mature customers will have the opportunity to further reduce cabling complexity by converging Ethernet and FC cables from a ToR switch to a core switch. In this environment FCF functionality will move to the core network. The chassis switches in the core network will have Fibre Channel blades which will connect to an existing FC SAN. This will require new core switches. The Cisco Nexus 7000 is an example of such a switch.

As a final step in the evolution of FCoE native FCoE may become viable. In this environment, both FCoE initiators and FCoE targets will connect to a DCB enabled Ethernet network. It will not require FCoE Forwarder devices, but will require FC services to run on the Ethernet network. The standards work for this is currently in progress but it will require FC services and may require new capabilities on the DCB enabled edge switches.

iSCSI, on the other hand, does not necessitate the use of new hardware components. iSCSI can run over a standard Ethernet network. The server may run iSCSI stack in software (SW-iSCSI stack is part of OS) or may run it on an adapter (full iSCSI offload to hardware). However, if the underlying network infrastructures (CNA, switches) are DCB capable then iSCSI will take advantage of all the DCB capabilities. It will leverage the DCB layer 2 flow control (802.1Qbb) and will also be able to provide a guaranteed QoS (bandwidth reservation) using 803.1Qaz.

FCoE must overlay specific services, provided by new types of equipment, over a new kind of Ethernet, DCB. To say this is convergence stretches the point a bit as FCoE is an overlay network and only converges Ethernet to the extent that Ethernet frames are used in data transfers.

FCoE Still the New Kid on the Block

Figure 3: FCoE and iSCSI maturity timeline

The timeline indicates that FCoE is still an emerging technology with wider deployment expected around 2011. FCoE will take time to mature and be inter-operable due to its dependencies on multiple standard’s efforts. Expectations are for most IEEE DCB standards to be finished by April 2010. iSCSI was approved by IETF in 2002 and has a three to five year edge over FCoE in terms of maturity and use in deployed user networks.

Summary

A technology such as FCoE that attempts to bring simplification to the data center by converging on a single fabric, namely Ethernet, is an effort that we fully support. We support the effort, however, with our eyes fully open to the difficulties of porting the FC protocol to a completely different underlying fabric. The FC protocol was designed to be a reliable, lossless fabric from the ground up. The physical layers of FC were in large part responsible for its success. The migration of FC to Ethernet requires Ethernet to have same level of lossless behavior as native FC.

FCoE will require time for maturity and interoperability. FCoE depends on multiple standards activities (T11 FCOE, IEEE DCB) and all these standards need to be ratified and implemented to ensure inter-operability. Given enough money and time we believe all these concerns can be alleviated but this will not occur easily, cheaply or simply.

Convergence to a single Ethernet fabric really means that an overlaid FC protocol network rides over the top of native Ethernet. Convergence is, therefore, somewhat mythical at this point

iSCSI was built, from the ground up, to run on Ethernet. While it is true iSCSI doesn’t need an expensive Ethernet upgrade such as DCB (DCE, CEE) it is also true that a better experience occurs over DCB with iSCSI. iSCSI can take advantage of better Ethernet but doesn’t require it as FCoE does.

iSCSI has evolved to adapt to the advantages that 10Gbps Ethernet, protocol offload and TCP protocol efficiencies have provided. iSCSI today is not your Father’s iSCSI. It is a reliable, fast, native storage protocol that continues to improve and evolve.

Where FCoE and iSCSI are in 3 years, when FCoE reaches iSCSI’s current maturity level, will be critical to which storage fabric wins the data center. FCoE may be more mature but iSCSI won’t stand still and will continue to evolve into a superior storage protocol

16 Member Groups Available with Latest Dell EqualLogic Firmware

DELL-Jeff S — Tue, 13 Oct 2009 05:00:00 GMT

Last week Dell EqualLogic debuted 4.2.1 firmware for the PS Series arrays, which you can download from the support site. Take a look at the release notes and you'll find there's some pretty amazing additions --and you didn't even have to buy a new array to take advantage of them. Well, unless you want to pick up a PS6500X or two (which I talked about here.)

Here's a few highlights of what's new in the 4.2.1 release:

Preemptive drive replacement
Support for new PS6500X
Support for 16-member groups

Take note: ALL GENERATIONS of EqualLogic arrays are eligible for the latest firmware upgrade. They too benefit from the expansion of up to 16 members/arrays in a single group. One of the best selling points, beyond the widely accepted ridiculous ease of use, is the investment protection through backwards compatibility that Dell EqualLogic continues to deliver.

Growing the group size by 33% (from 12 to 16 members) provides several benefits. It allows a storage admin to manage more arrays in a single pool. It load balances data more efficiently across more arrays and more drives. The larger spindle count and group capacity also reduces sprawl of applications. You can manage more of those applications in a single group.

Upgrading is a cinch, especially if you are at a 4.1.3 or later versions of the firmware. Here's a short video of me upgrading one of our arrays through the GUI to 4.2.1:

(Please visit the site to view this media)

I recommend you read the "Updating Storage Array Firmware" document found on the support site before giving it a go.

Michael Dell Paints His Vision of the Efficient Enterprise at Oracle OpenWorld

DELL-Greg W — Tue, 13 Oct 2009 05:00:00 GMT

You might think that after two full days of keynotes, breakout sessions, events and meetings at Oracle OpenWorld it would be hard to excite a convention hall full of business and IT leaders, but Michael Dell had just the right formula with:

A compelling vision - Redirect IT dollars from management and maintenance to innovation and improving the business by building an Efficient Enterprise;
Big commitments for quantifiable results like working to take $200 billion of inefficiency out of the $1.2 trillion IT infrastructure industry spend and driving $200 million in savings for Dell's own IT;
Impressive statistics, something almost all of us in the IT industry get into, of the power of the Dell and Oracle partnership and Dell's leadership and track record in providing solutions;
Cool products, including:
- Dell's 11th generation of PowerEdge servers were onstage and Michael highlighted the enhancements in these new servers to simplify deployment, enhance performance, reduce complexity and lower power and cooling requirements;
- He also discussed more innovation to come next year with new PowerEdge servers based on Intel Nehalem EX architecture; and,
- Talked about continued enhancements to the EqualLogic storage products, like SSD (launched this year) and 10Gbps Ethernet (coming soon) that will drive efficiency and performance for storage.
A blueprint to make this vision a reality including:
- Standardization on open standard solutions built on x86-based servers;
- Simplification by starting with the applications and taking the complexity out of the way they are supported and managed, and by using Virtualization and Storage Consolidation;
- Automation by streamlining Services delivery and enabling self-service IT models where critical business services can be deployed through the cloud.
Dell's own plan - Robin Johnson, CIO of Dell, shared how he is driving inefficiency out of the Dell IT machine
Having fun - Everyone was excited by Larry Ellison's surprise appearance and from the return of the Tech Force alliance!

Hopefully you are as excited as we are about building the Efficient Enterprise, and if you’re here this week, be sure to come see us in the booth.

You can follow us on Twitter @dellatORACLEwld and check out my earlier post on Direct2Dell with details of all our activities.

Comparing Performance Between iSCSI, FCoE and FC.

DELL-Jeff S — Wed, 07 Oct 2009 05:00:00 GMT

The following post is written by Ujjwal Rajbhandari, from our Storage Product Marketing Group.

There are number of discussions, blogs and articles comparing iSCSI, FCoE and FC. Many of them share a common belief that FCoE and FC are better suited as core datacenter SAN and iSCSI is ideal for Tier 2 storage or for SAN deployments in ROBO/SMB environment. That is because iSCSI is characterized as “low performing”, “lossy” and “unpredictable”. In this blog I will tackle the mis-information around iSCSI performance as compared to FC and FCoE. I will also compare effective efficiency of the various SAN protocols since efficiency is an aspect of performance

Both iSCSI and FCoE share the same 10Gb Ethernet at the transport layer. However, the perception is that the TCP/IP overhead makes iSCSI inefficient as compared to FCoE and FC (both having better payload to packet size ratio) thus leading to lower performance and efficiency. Figure 1 shows protocol efficiency calculation for iSCSI (both 1.5K MTU and 9K MTU), FC and FCoE (2.5K MTU). It can be seen that when jumbo frames are enabled, iSCSI has the best protocol efficiency.

Figure 1: Protocol efficiency comparisons

In regards to performance, iSCSI having low performance might have been true when 1Gbps was maximum throughput available per iSCSI port where as FC was delivering 2Gbps, 4Gbps and 8Gbps per port, but with the availability of 10GbE the commonly held belief that iSCSI performance is not being up-to-par as compared to FCoE or FC is no longer true.

The Office of CTO at Dell conducted a series of performance test to compare 10GbE iSCSI, FCoE and 4Gb FC. To ensure similar workload the application throughput was limited to 4Gb. The host adapters used for the different protocols were as follows:

1. 10GbE NIC with iSCSI offload for iSCSI traffic

2. 10GbE converged network adapter (CNA) for FCoE traffic

3. 4Gbps FC HBA for fibre channel traffic

The goal of the testing was to capture achieved throughput and CPU utilization for a given SAN protocol.

The protocol efficiency comparisons from Figure 1 might be theoretical in nature, Figure 2 shows results from an IO workload study compare throughput of 10GbE iSCSI, FCoE and 4Gb FC HBAs. To keep the results easy to visualize, the results show the throughput achieved when application generated 4Gb throughput. It can be clearly seen that iSCSI outperforms FCoE and FC regardless of read or write operation for various IO block size.

Figure 2: Throughput Performance Comparisons (MB/s)

Alongside capturing the throughput, let’s examine the host CPU utilization to better assess the performance and efficiency of specific SAN protocol. All the host adapters are comprised of hardware based offload capability to process the protocol specific traffic minimizing use of CPU resources. Figure 3 shows the effective CPU utilization for various workloads. It can be seen from the figure that all the host adapters have similar CPU utilization metrics, again reinforcing the fact that iSCSI is as efficient as FCoE and FC.

Finally, Figure 4 shows throughput efficiency, defined as MBps/%CPU, for the various storage protocols. The chart clearly shows 10GbE iSCSI having the best throughput efficiency across the workload types clearly outperforming FCoE and FC.

From the test results we can undoubtedly summarize that iSCSI as a SAN protocol is not “lower performing” or “inefficient” as compared to FC or FCoE. On the contrary, iSCSI outperforms both FC and FCoE. Customers who are planning to purchase storage for their datacenter can consider iSCSI SAN as a viable option knowing iSCSI performance is at par or even better than FCoE and FC. Also, customers considering unifying their datacenter network over Ethernet can start doing so now with iSCSI. While FCoE can also deliver storage traffic over Ethernet it is still under development and is not ready for prime-time.

Figure 3: CPU utilization (%) for iSCSI Offload, FCoE and FC

Figure 4: Overall protocol throughput efficiency (MBps/%CPU) for iSCSI Offload, FCoE and FC

Dell and 10GbE at VMworld 2009 - Do not Confuse 10GbE as Unified Fabric.

DELL-Kong Y — Tue, 01 Sep 2009 05:00:00 GMT

Let's start off by stating that Unified Fabric is not 10GbE alone. Unified Fabric can be defined as a wire-once backbone that unifies computing and I/O resources. And this includes the complete integration of 10GbE, iSCSI, and FCoE. The main idea is that 10GbE can provide the infrastructure to run both iSCSI and FCoE.

Both 10GbE and iSCSI are standards. However, FCoE is still being finalized as a standard. The missing piece for FCoE is DCB, DCE or CEE. Regardless of the name, they all represent the same thing- flow control in the network. So what options does one have while waiting for standardization? The answer is quite simple- consolidate your Ethernet to 10GbE since it can support both iSCSI and FCoE. And this will ease the transition towards unifying your data center fabric once the IEEE standards are defined.

On the storage side, on 8/25 Dell announced 10GbE support for the Dell/EMC CX4 series storage arrays and has been demonstrating 10GbE on them at VMworld 2009. Dell | EqualLogic has shown a technology demonstration of 10GbE modules in its PS series storage enclosures at VMworld the past two years. On the networking front, Dell has announced a new high-port count switch, a pass-thru blade I/O module and a mezzanine card that all support 10GbE. These are examples of what Dell is doing with 10GbE. All these enhancements will provide more bandwidth and more options for virtualized environments. In addition, VMware vSphere features such as VMotion, storage VMotion, HA, FT, and DRS as well as the VM networks will benefit from the larger pipe. The net effect makes the data center more efficient to deploy and manage when using Dell. Overall, 10GbE will be an important enabler of data center infrastructures and Dell is actively integrating it into our solutions.

Network Design Considerations for EqualLogic SANs - Part 2

DELL-Jeff S — Wed, 26 Aug 2009 05:00:00 GMT

Last week, I posted an article on what makes EqualLogic architecture different from other iSCSI/FC offerings and why the switch interlink bandwidth is important. In Part 2, the dramatic conclusion to the series, I'm focusing on cables and switch settings.

I had an opportunity to spend a few hours in the Dell Interoperability Lab last week. We discussed what they were working on and afterwards was introduced to a neat little Chinese restaurant nearby with some excellent General Tso's... I suppose I should save my restaurant reviews for when I replace that guy on Man Vs. Food. As I was saying, the team was busy installing things that I'm not at liberty to discuss yet; but let’s just say some of them had 10GbE ports. The 10GbE sparked an interesting conversation on cables. Arguably, with 1Gb networking, quality of cables became important in the datacenter. With 10GbE on the crest of becoming mainstream, it’s even more important now. The rigorous testing the interoperability team puts various components through tends to show that what you may think about cable quality and reliability isn't always true. They asked I not discuss the testing details as that information might be used to tune products to beat the tests.

My favorite quote of the day, in true lab-geek-guru fashion, was: "One word on making your own cables: Don't." I chuckled a bit at this statement, but it’s true. It's likely you may get most of the cables crimped right, but the ones that don't will cause you the most pain. When 10Mbs and 100Mbs were mainstream, handmade wasn’t really an issue. Starting with 1Gb and faster, it really can be a major factor. Because TCP connections have error recovery, your marginal home-made cable might just impact performance, but not actually break completely. In many cases, you won’t get any error messages on those packet retries, so just use quality cables. Another insight from the team was that even if you aren't getting 10GbE anytime soon, start ordering the correct cables now. If you have the choice when ordering, go ahead and get Cat 6 or 6a. The difference in cost is negligible and Cat 6/6a is ready for 10GbE. Better yet, it's better insulated and provides better noise rejection. Per one of the interoperability team members, this statement from Wikipedia (with a few edits) is valid:

10GBASE-T should work up to 55 m (180 ft) with current Cat 6 cabling. In order to allow deployment at the usual 100 m (328 ft), the standard uses a new partitioned Category 6a (a.k.a "augmented Cat6") cable specification, designed to reduce crosstalk between UTP cables, known as alien crosstalk. Some manufacturers of cable have released "Cat7" cable which is specifically marketed for 10GBASE-T compatibility and claims greater shielding beyond cat6a specifications. FYI the difference…cat6a is 550MHZ and cat 7 is 600MHZ. And though they SAY you can use cat 7 on 40GbaseT, nobody has as of yet, of course. For now…the big deal is that a 7ft cat 6 cable is $5 and a cat-7 is $15 or more. Talk is that cat-7e will be even better, and prices will go down in a few years.

Cable testing and qualification should be at the top of your list of considerations. Some basics from the lab: Make sure the cable is tested to the right standards. Try aiming for 55-micron gold plating as the better coating is more resistant to multiple plug ins and plug outs and will provide a clean and clear transmission. Just because a cable says it meets specs unfortunately doesn't mean they are good enough for your environment. Our testers said the only way to really know how a cable is to buy a couple and test them thoroughly with a QUALITY cable tester before you place the big order. The guys went on to say that most shops probably use a run of the mill tester from a local computer supply that may not be telling everything. In general they found they had to get at least +2 DB headroom over spec to be a truly robust cable. In fact, some of the best cables they have go over +17DB in headroom. One of the geeks noted that he had a cable with 0 headroom, but did test out as a perfectly good CAT6 cable, and yet was causing hundreds of errors (retransmits of packets) at the switch port. The cable was replaced with one that had +2.3 DB headroom, and the errors went away!

I asked for some signs that might indicate the presence of suspect cables: As with anything in Tech, 'it depends' and can vary switch by switch, but they did say seeing a high number of transmission retries or intermittent LUN drops usually means its time to do some cable testing. By the way, the guys in the lab use a neat little cable tester, that costs about $10K! This is why they buy quality cables and STILL test them first, to insure that they are not going to find issues the hard way… when something breaks!

Where possible, jumbo frames (size set to 9000 or 9014 bytes depending on your NIC) and flow control should be enabled. Set them on your switch and server levels, and the EqualLogic arrays will adjust accordingly. Additional network considerations include minimizing switch hops and maximizing the bandwidth on the inter-switch links if present. Reducing the number of switch hops between the server(s) and the storage reduces the chances of storage traffic competing with other data traffic on congested interswitch links.

Also, a word on firmware of PowerConnect switches, since many Dell servers and storage products are sold with them -- schedule some time to update them to current firmware versions. After EqualLogic joined Dell, some significant changes were implemented that provide for more performance and reliability. In fact, in the lab it was pointed out the reliability testing of these switches was on par or actually better than many of the costlier solutions out there.

Network Design Considerations for EqualLogic SANs - Part 1

DELL-Jeff S — Fri, 21 Aug 2009 05:00:00 GMT

Last week, I dropped in on our sales force at an internal training event to make sure they are telling their customers about the wonders of DellTechCenter. Once my duty as a booth-babe was over, I attended an interesting session on proper network design for EqualLogic SANs given by Marc Keating, Principal SE at Dell (and one of the waaaay back EqualLogic guys.) I went in thinking my lab setup was fine and came out thinking I need to make some serious changes! Although it's a lab and we have yet to have performance issues, I feel its my responsibility as a pocket protector carrying member of the technical workforce to correct this egregious slight against the capability of our EqualLogic PS Series arrays. Its akin to limiting a Ferrari to 70 MPH because that's the maximum speed on the roads around here. What if I drive through West Texas where its 80 MPH or better yet get some track time over in College Station?

Back to reality. I'll temporarily pause my dreaming of fast cars and finish my point. According to Marc, the network setup is probably the most important and likely least understood aspect of getting the much heralded performance out of an EqualLogic group. Most other iSCSI (and FC for that matter) products subscribe to the typical frame based multi-path failover concept, or 'hard path link' between components. You have one port on your adapter going to one switch and another port on another card going to another switch. Then each one of those switches in turn has a connection going to each controller on your iSCSI device. Should any one of those components fail (adapter, switch or controller), then the multi-pathing software makes a 'hard-path' switch to maintain connectivity. This is the way the world worked for me before I ran into EqualLogic SANs. The world was flat... But then, in the network session, I began to understand the advantages of the EqualLogic architecture; and why networking setup is important to take advantage of it all.

PS Series arrays optimize resources by automating volume and network load balancing. It is a frame-less architecture. Instead of a single head unit with two controllers, there can be multiple arrays all in a single group. Despite the multiple arrays, its still a single management interface, single discovery address for the clients, single... OK, you get the idea. Each array has two controllers. Data is intelligently managed across the entire group of arrays and the luns/volumes may span across any or all of the arrays in the group. I/O is load balanced across the interfaces - and the assumption is made that your network is sound and has equivalent bandwidth regardless of the path data takes to and from the iSCSI initiators. Redundancy is inherent. If the path through one particular switch or controller or adapter goes down (or is overloaded ), it'll re-route automatically.

Keating's presentation also pointed out that this breaks the typical 'hard path' scenario I described earlier because in that scenario the two switches typically do not have interlinks that can support this type of bandwidth. That's really the key, either use stacking or trunking (depending on your switch capability and size of your group) to make sure there is enough bandwidth between the switches. For a smaller environment (i.e. 1 or 2 switch environment) trunking is probably sufficient. It's recommended that you have a trunk capacity equal to the network capacity of the arrays, although 70-80% is considered acceptable. 10-Gig links are most efficient if available. To maintain performance scalability with more than a few arrays (and/or switches) in the group, its likely you'll want to make sure your switches support stacking. As you grow and scale your datacenter environment, you may get to the point where stackable switches (even a couple of stacks that are trunked together) may not be enough. At that point you will have to move towards some kind of chassis based switch. The technical report titled "Dell EqualLogic PS Series Network Performance Guidelines", found at the EqualLogic support site (under resources/tech reports after you register and log in) covers the network requirements and recommendations in detail.

In part 2 I'll discuss some interesting insights from the Dell Interopability Lab into cables and specific switch settings. Now back to my regularly scheduled obsession with fast cars.

iSCSI's Not Enterprise, Said The Instructor

DELL-Jeff S — Thu, 23 Jul 2009 05:00:00 GMT

Talk about incendiary... especially considering the instructor's audience: mostly Dell technical personnel. (MD3000i, EqualLogic ring a bell?) This statement was delivered, probably without much thought on how it would be received by the attendees, during a recent training session. The course focused on products that play almost exclusively in a fiber channel SAN arena. The teacher was "kinda like a nut living amongst squirrels." More than once that day, a heated discussion flared on iSCSI vs fiber channel and eventually spanned to cover FCoE as well.

Naturally, I tweeted about the entertaining debate. The twitter response was equally interesting. It was as if I had mentioned Microsoft in a Linux forum. Ford vs. Chevy. You get the idea --it's a religion. I began to think about my last 10 years at another company. The kool-aid I was drinking was the color of orange wires. The instructor's glasses, understandably, seem to be a little orange tinted as well. Its what he and his company grew up with. Over the next few days, I discussed this topic with several folks in and out of the DellTechCenter. I also read a number of related interesting blogs and forum posts. What did I learn? Here's a quick summary of the various opinions I ran into this week:

Fiber Channel:
FC SANS are thought of for performance and reliability. Management and implementation of FC SANS requires a specific knowledge set and can be viewed as expensive to get started. Another common opinion was that customers with FC investments likely won't be quick to adopt or move to iSCSI.

iSCSI:
iSCSI is generally viewed as easy and less expensive to implement from both a training and hardware perspective. It's likely the infrastructure skills required already exist within the companies evaluating the technologies. Although, sometimes the intricacies of infrastructure configuration for best performance are somewhat glossed over. The iSCSI SANS found their way into the smaller shops initially, but has quickly been moving up the food chain. The predominant opinion is that when 10 GB Ethernet becomes widely accepted, so will iSCSI.

FCoE:
There were tentative opinions in the group on FCoE. The common thread was that the cost for the needed additional hardware might hinder market acceptance.

Fortunately, I have multi-colored kool-aid these days. As a storage evangelist for DellTechCenter, I have the opportunity to evaluate and write about the various technologies. I previously did not have hands on experience with iSCSI. Now that I've had a chance to connect a few servers to both EqualLogic and MD3000i arrays, I was truly surprised at how easy it was to get going. Factor in the ease of implementation, equivalent storage features (mpio, replication, snapshot, etc), scalability and cost of the solutions --the 'not enterprise' opinion seems a bit uninformed. I personally don't see it as an end to fiber though. In this industry these type of debates will always come up. I'm sure there were token-ring proponents that had similar opinions on Ethernet's viability in the enterprise.

DellTechCenter Chat on iSCSI Security and Best Practices

DELL-Jeff S — Wed, 01 Jul 2009 05:00:00 GMT

Most heard phrase this week after my return from family excursion: "Wow, new guy and already taking vacation." I'd feebly attempt to explain how I had purchased the cruise tickets well in advance of joining Dell; however the finger wagging didn't seem to let up much. Oh well, last week's sunburns and margaritas were well worth the ribbing.

Speaking of vacation -just before you catch the yard on fire with bottle rockets and black cats, join us for a special special July 2 "TechThursday" Chat, iSCSI Security and Best Practices, at 3:00 PM CDT. We'll have several KEY members of the Dell storage team on hand to field any questions or comments.

The picture shows behind the scenes of our last chat: Kong, Scott & I hard at work.