Dell TechCenter

Solutions by Engineers for Engineers Discusses Things to Do Before You Hit CTRL-ALT-DEL on VMware vSphere 4.0 Host Servers

DELL-Kong Y — Thu, 19 Nov 2009 16:28:00 GMT

I recently posted a Dell TechCenter wiki page on the default behavior of VMware vSphere 4.0 when you hit CTRL-ALT-DEL. That behavior being to initiate the soft reboot process on the server even if the server is not in Maintenance Mode; and thereby, ungracefully rebooting all of your VMs on that server. The wiki page describes what you need to do to remedy the situation.

Tools for the Efficient Enterprise

DELL-Kong Y — Mon, 09 Nov 2009 22:09:00 GMT

Lead by Thomas Cloyd, Product Marketing Senior Consultant, Dell has delivered tools designed to help customers move their datacenters toward the Efficient Enterprise.

Dell Blade Servers - Dedicated website to explore Dell M-Series Blade technology from high level to deep dive.
Dell Blade ROI Calculator - Calculate the Financial Benefits of Dell Blades, Fully Customizable to Your Specific Business
Dell DDR3 Memory Advisor - Understand new Intel Nehalem DDR3 Memory Architecture
Dell Server Savings Calculator - Illustrate your Power and Space Savings with New Dell Servers

Also, check out the initial and follow-up external review of the Dell Blade ROI Calculator.

Dell Repository Manager Demos

DELL-Scott H — Thu, 05 Nov 2009 21:16:00 GMT

I'm a big believer in simple tools with flexibility to create solutions for your needs.

As a technical person I find nothing more satisfying than hacking a piece of code to create a unique solution.

Dell Repository Manager allows you to create custom repositories that contain the Dell Update Packages (DUPs) which are then exported to either an ISO file or a lightweight deployment script for Windows or Linux.

I've created two demos that show both. The first one is an overview of the product and shows exporting to lightweight script for use in Windows.

In the second demo I hack on one of the files to automate the deployment after exporting the ISO and mounting across multiple blades in the chassis. The changes to the script eliminate the user input and also reboot the blades if the updates were successful. The nice thing is it is a simple shell script you can edit. If you are familiar with simple scripting I'm sure you'll find yourself building more intelligence into the code. I've also included details on editing the script used by Repository Manager to automate the execution and reboot after completion.

Watch the demos here.

SAN HQ 2.0 First look

DELL-Jeff S — Wed, 28 Oct 2009 18:35:00 GMT

If you are already a part of the EqualLogic fan base, hopefully you downloaded a free copy of SAN HQ 1.0 off the support site. Less than a year after introducing an already great product (free to customers on support I might add), Dell EqualLogic is getting ready to debut the second version, likely before the end of the year.

SAN HQ 2.0's interface is still as snappy, informative and intuitive as the previous generation, with some added capabilities:

Packaged Reports --

"Top 10" reports such as Top 10 Busy Volumes, Top 10 Hosts by Connection, and more.
Performance Report
Host Connections Report
Group Configuration Report with Alerts
Capacity Utilization and Trending Report
Thin Volume Status Report
Replication Status Report
Alerts Report for All Groups
Hardware Summary Report

Enhanced Analytics: calculation and display of maximum theoretical IOPS; degraded performance limits; estimated percentage-busy IOPS for groups, pools, and members; IOPS vs. latency; and volume queue depths

Broader Data Collection: additional metrics on iSCSI sessions, outbound replication, volume collections, network ports and controllers, including temperature charts

New Alerts: including those for unreachable member ports, port status, member disk mirroring issues, and disk alternate signatures

Better Communication: finer-grained control over e-mail notification and group e-mail settings

Improved Usability: single sign-on, new wizards, simpler navigation, and chart enhancements

Since a picture is worth a 1000 words, I'll save my usual marathon-length blog and throw up some screen captures from our two groups in the DellTechCenter monitored by SAN HQ 2.0:

Figure 1: Main page of one of our groups.

Figure 2: New with 2.0 SAN HQ Report Wizard

Figure 3: Page from "Top 10" report generated

Figure 4: Expanded Network port and controller information available in 2.0

Solutions by Engineers for Engineers Present Dell Design Principles for Microsoft Windows Server 2008 R2 Hyper-V

DELL-Kong Y — Tue, 27 Oct 2009 20:41:00 GMT

Meet Ryan Weldon, Dell Virtualization Solutions Engineering Hyper-V lead. He is helping Dell simplify IT with best practice for Microsoft Windows Server 2008 R2 Hyper-V in Dell’s solution stack. He has put together a wiki page at the Dell TechCenter on a Hyper-V R2 lab configuration describing networking best practice recommendations for a Hyper-V R2 environment built on Dell.

The design best practices are based on:

Redundant hardware to eliminate a single point of failure
Load balancing and failover for iSCSI and virtual machine traffic
Redundant paths for cluster, Cluster Shared Volume (CSV), and Live Migration traffic
Separation of traffic type for security and availability
Ease of use and implementation

Ryan has also provided a script that takes any adapter that begins with the name "Local Area Connection" and renames them to their MAC addresses. Let us know what you think and what you are doing with Dell and Microsoft Windows 2008 R2 Hyper-V.

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

DELL-Jeff S — Thu, 22 Oct 2009 21:13: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 16:09: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

All Quiet on the Virtualization Front

DELL-Kong Y — Fri, 16 Oct 2009 16:17:00 GMT

It has been a while since my last post; but there’s been good reasons for the delay. I’ve been working with Dell partners- Microsoft, VMware and Veeam on performance and usability related studies and Scalent to understand how they integrate into Dell’s solution stacks.

Areas encompassed include Microsoft Windows 2008 Server running Hyper-V R2 feature, running Microsoft Exchange and SAP VMs in a VMware vSphere environment, backup using Veeam’s Backup product, and dynamic infrastructure management using Scalent. All of this is built upon Dell 11G servers and Dell | EqualLogic PS series storage arrays. So continue to check the Dell TechCenter blog and the Dell TechCenter site for sneak peeks into study results and demo announcements.

16 Member Groups Available with Latest Dell EqualLogic Firmware

DELL-Jeff S — Tue, 13 Oct 2009 15:23: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.

Comparing Performance Between iSCSI, FCoE and FC.

DELL-Jeff S — Wed, 07 Oct 2009 19:49: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