December 3, 2010 – In more good news for the rebounding storage industry, revenues from external disk systems grew 19% in Q3 2010 vs. Q3 2009, topping the $5 billion mark, according to a report from IDC. Revenues for the total (external and internal) disk systems market grew to almost $7 billion, representing an 18.5% year-over-year growth rate.
Total capacity shipped grew 65.2%.
In the external array market, EMC held on to its #1 spot by a wide margin, with $1.35 billion in Q3 revenue and a 26.1% market share. IBM was a distant second with $667 million in revenue and a 12.9% market share.
But the real race is for the #3 position, where NetApp and HP are in a virtual dead heat. (Even dead heats are virtual these days.) NetApp had an 11.6% market share in Q3, followed closely by HP with an 11.1% slice. IDC considers it to be a statistical tie when less than a one percent revenue difference separates two vendors.
Dell finished fifth, with a 9.1% market share on revenue of $471 million.
All of the top five vendors had healthy, double-digit revenue growth (ranging from 11.3% for HP to 28.3% for EMC), but it was NetApp that busted the charts with a whopping 54.9% growth rate.
Looking at the leader board trends over the past few quarters, it would seem safe to say that NetApp has blown past HP and is closing in on Big Blue, except for HP’s 3PAR acquisition. With HP’s marketing muscle behind the 3PAR product line, revenue could crank up pretty quickly. For now, however, 3PAR had a market share of only 0.83% in the third quarter. (Isilon’s slice was 0.75%.)
Other highlights from the IDC report: The NAS market was the fastest-growing segment of the overall storage systems market, posting 49.8% growth in Q3 2010 vs. Q3 2009. EMC led the NAS market with a 46.6% share, followed by NetApp with a 28.9% share.
The iSCSI segment of the overall market also did well, posting 41.4% revenue growth, with Dell/EqualLogic in the top spot (33.8% share) followed by EMC and HP in a tie for second place.
For more details, read the IDC press release: “External Disk Storage Systems Market Records Fourth-Highest Quarterly Revenue in Third Quarter”
Showing posts with label iSCSI. Show all posts
Showing posts with label iSCSI. Show all posts
Friday, December 3, 2010
Thursday, November 4, 2010
Intel’s card play in unified networking (10GbE+iSCSI+FCoE)
November 3, 2010 – InfoStor has been covering converged, or unified, networks and the Fibre Channel over Ethernet (FcoE) protocol for years, but most of our product-oriented coverage has been centered on adapters from vendors such as Emulex and QLogic. Those vendors are clearly out in front in this space, both from a time-to-market and market share perspective, but there are other vendors with host adapters for converged networks, and we’ve been remiss in not covering a little player called Intel.
First, a note on terminology: Vendors such as QLogic and Emulex use the term converged network adapter (CNA) to describe cards that support protocols such as 10GbE, Data Center Bridging (DCB), iSCSI and FCoE. Other vendors, such as Broadcom, are expected to use the term Converged Network Interface Card, or C-NIC.
Intel doesn’t use either of those terms, referring to the technology in general as “unified networking” or just referring to its Ethernet X520 Server Adapter card.
Intel’s approach to unified network cards is architecturally different from the CNA approach taken by vendors such as Emulex and QLogic. With CNAs, protocols (and protocol offload functionality) are implemented on the CNA, which architecturally is similar to a host bus adapter (HBA).
In contrast, Intel uses native initiators for FCoE and iSCSI that are implemented in the host operating system (Windows and Linux) kernel. Thus Intel’s use of the term “open FCoE.”
“We rely on native protocols in the OS kernel, so it’s free and easy to implement and use,” says Sunil Ahluwalia, senior manager of product marketing in Intel’s LAN Access Division. “CNAs are special-purpose adapters that are more complex and costly.”
Intel’s Ethernet X520 Server Adapter has an MSRP of $799 (and often sells for considerably less), which is about half the price of CNAs.
Rather than implementing hardware-based full offload of the storage-over-Ethernet protocols, Intel offloads only the data path part of the protocol.
“We have what we call ‘intelligent offload,’” says Ahluwalia. “We don’t offload the full protocol because we don’t think that’s required, and full offload adds complexity and cost to the cards because you need processing engines, memory, etc. on the card, which also adds power requirements.”
Performance
CNA vendors have historically claimed that the native initiator approach (a) lacked full support for protocols such as FCoE (which is no longer the case) and (b) had relatively poor performance.
Intel begs to differ. However, it’s important to note that all vendors in this space can point to internal or third-party testing that shows superior performance for their products. As always, benchmark results should be taken with a grain of salt.
“Intel and Microsoft demonstrated one million IOPS with native iSCSI earlier this year, but the question was: Who needs that level of performance in real-life applications?,” says Ahluwalia, “so we performed some tests [with Demartek] running applications such as Exchange and SQL and we found little difference in performance between a CNA and an initiator approach.”
For full info on the testing procedures and results, see Demartek’s “Intel 10GbE Adapter Performance Evaluation for FCoE and iSCSI.” (Demartek’s site has a lot of other interesting FCoE-related content).
“We found that the performance of the Intel X520 adapter was comparable to competitive 10Gb FCoE adapters for a broad spectrum of tests,” said Dennis Martin, Demartek’s president. “Because the adapter performance was reasonably close in most of these tests, IT professionals need to consider the cost of these adapters, especially in environments where many adapters are required.”
Intel’s Ahluwalia also claims that the native initiator approach does not consume a lot of CPU cycles (another criticism of this approach).
To take one example from the Demartek tests: In a Microsoft Exchange Jetstress benchmark with 5,000 mailboxes, Intel’s card/initiator consumed only about 2% CPU utilization.
But you really have to take a close look at the Demartek tests, as well as testing of CNAs conducted by other vendors and third parties, to get to the bottom of the performance claims in the unified, or converged, network adapter market.
Related article: QLogic announces 10GbE NICs, CNAs
First, a note on terminology: Vendors such as QLogic and Emulex use the term converged network adapter (CNA) to describe cards that support protocols such as 10GbE, Data Center Bridging (DCB), iSCSI and FCoE. Other vendors, such as Broadcom, are expected to use the term Converged Network Interface Card, or C-NIC.
Intel doesn’t use either of those terms, referring to the technology in general as “unified networking” or just referring to its Ethernet X520 Server Adapter card.
Intel’s approach to unified network cards is architecturally different from the CNA approach taken by vendors such as Emulex and QLogic. With CNAs, protocols (and protocol offload functionality) are implemented on the CNA, which architecturally is similar to a host bus adapter (HBA).
In contrast, Intel uses native initiators for FCoE and iSCSI that are implemented in the host operating system (Windows and Linux) kernel. Thus Intel’s use of the term “open FCoE.”
“We rely on native protocols in the OS kernel, so it’s free and easy to implement and use,” says Sunil Ahluwalia, senior manager of product marketing in Intel’s LAN Access Division. “CNAs are special-purpose adapters that are more complex and costly.”
Intel’s Ethernet X520 Server Adapter has an MSRP of $799 (and often sells for considerably less), which is about half the price of CNAs.
Rather than implementing hardware-based full offload of the storage-over-Ethernet protocols, Intel offloads only the data path part of the protocol.
“We have what we call ‘intelligent offload,’” says Ahluwalia. “We don’t offload the full protocol because we don’t think that’s required, and full offload adds complexity and cost to the cards because you need processing engines, memory, etc. on the card, which also adds power requirements.”
Performance
CNA vendors have historically claimed that the native initiator approach (a) lacked full support for protocols such as FCoE (which is no longer the case) and (b) had relatively poor performance.
Intel begs to differ. However, it’s important to note that all vendors in this space can point to internal or third-party testing that shows superior performance for their products. As always, benchmark results should be taken with a grain of salt.
“Intel and Microsoft demonstrated one million IOPS with native iSCSI earlier this year, but the question was: Who needs that level of performance in real-life applications?,” says Ahluwalia, “so we performed some tests [with Demartek] running applications such as Exchange and SQL and we found little difference in performance between a CNA and an initiator approach.”
For full info on the testing procedures and results, see Demartek’s “Intel 10GbE Adapter Performance Evaluation for FCoE and iSCSI.” (Demartek’s site has a lot of other interesting FCoE-related content).
“We found that the performance of the Intel X520 adapter was comparable to competitive 10Gb FCoE adapters for a broad spectrum of tests,” said Dennis Martin, Demartek’s president. “Because the adapter performance was reasonably close in most of these tests, IT professionals need to consider the cost of these adapters, especially in environments where many adapters are required.”
Intel’s Ahluwalia also claims that the native initiator approach does not consume a lot of CPU cycles (another criticism of this approach).
To take one example from the Demartek tests: In a Microsoft Exchange Jetstress benchmark with 5,000 mailboxes, Intel’s card/initiator consumed only about 2% CPU utilization.
But you really have to take a close look at the Demartek tests, as well as testing of CNAs conducted by other vendors and third parties, to get to the bottom of the performance claims in the unified, or converged, network adapter market.
Related article: QLogic announces 10GbE NICs, CNAs
Thursday, May 13, 2010
iSCSI vs. FCoE, part deux
May 14, 2010 – It’s an age-old debate – iSCSI vs. Fibre Channel – but in light of all the hubbub around Fibre Channel over Ethernet (FCoE), the debate is heating up again.
If you follow the FCoE news, you’d think that converged networks based on FCoE are an IT inevitability. Eventually (it’s going to be a very slow adoption curve) that may be true, but I think it will be more in the Fortune 1000 space – where the benefits of FCoE will be most apparent – rather than in the SMB space, where low cost is still king.
FCoE provides the ability to run storage traffic over Ethernet (although you have to upgrade to 10GbE and Converged Enhanced Ethernet, or Data Center Bridging), but iSCSI also enables storage traffic over Ethernet – at a much lower cost. And, as with FCoE, you can preserve existing investments.
Running storage traffic over Ethernet is a no-brainer, but it doesn’t require FCoE. Cost-conscious SMBs may find iSCSI more palatable. And if part of your convergence and cost cutting revolves around virtualization, iSCSI (or NAS) may make even more sense. Plus, it’s a simpler and faster route to a converged network.
Of course, the old argument against iSCSI was, in part, related to performance. But that was when the argument centered on 1Gbps Ethernet vs. 4Gbps Fibre Channel. Now that iSCSI can run on 10Gbps Ethernet (as can Fibre Channel via FCoE), those performance-oriented arguments are crumbling.
But don’t take my word for it.
openBench Labs (which contributes lab reviews to InfoStor), recently set up an interesting test case by building a modest, inexpensive 10GbE iSCSI storage network that turned in some impressive performance results.
You’ll have to read the full review to put some perspective on the performance numbers, but openBench Labs CTO Jack Fegreus clocked average throughput of 5,000 I/Os per second (IOPS) with one virtual machine (VM), which was in line with what openBench Labs achieved with direct Fibre Channel access to the same disk array in previous tests. With two VMs, throughput scaled to about 8,200 IOPS.
Jack concludes his review with this observation: “Given these results, our 10GbE iSCSI configuration with QLogic Intelligent Ethernet Adapters should be able to support the installation of Microsoft Exchange Server on a VM with upwards of 5,000 mail boxes.” Quite sufficient for most SMBs. “The simplest and most immediate strategy for IT to begin leveraging 10GbE in a data center, especially when dealing with a virtual environment, is to begin implementing iSCSI.”
Jack’s 10GbE iSCSI network consisted of three Dell PowerEdge servers running Windows Server 2008 R2 and VMware ESX Server 4; iSCSI software from StarWind; dual-port 10GbE Ethernet adapters and 4Gbps Fibre Channel HBAs from QLogic; and a Xiotech Emprise 5000 disk array with two 4Gbps Fibre Channel ports. Performance was measured with Intel’s Iometer benchmark.
Check out the full review: “How to jumpstart SAN + LAN convergence.”
Related blog posts:
Virtual server SANs: FC vs. iSCSI vs. NAS
Intel, Microsoft top 1,000,000 IOPS in iSCSI tests
Video surveillance is a real sweet spot for iSCSI
NAS gains in virtual server environments
And you might want to consider attending this upcoming (May 26) SNIA Webcast: “iSCSI and New Approaches to Backup and Recovery.”
If you follow the FCoE news, you’d think that converged networks based on FCoE are an IT inevitability. Eventually (it’s going to be a very slow adoption curve) that may be true, but I think it will be more in the Fortune 1000 space – where the benefits of FCoE will be most apparent – rather than in the SMB space, where low cost is still king.
FCoE provides the ability to run storage traffic over Ethernet (although you have to upgrade to 10GbE and Converged Enhanced Ethernet, or Data Center Bridging), but iSCSI also enables storage traffic over Ethernet – at a much lower cost. And, as with FCoE, you can preserve existing investments.
Running storage traffic over Ethernet is a no-brainer, but it doesn’t require FCoE. Cost-conscious SMBs may find iSCSI more palatable. And if part of your convergence and cost cutting revolves around virtualization, iSCSI (or NAS) may make even more sense. Plus, it’s a simpler and faster route to a converged network.
Of course, the old argument against iSCSI was, in part, related to performance. But that was when the argument centered on 1Gbps Ethernet vs. 4Gbps Fibre Channel. Now that iSCSI can run on 10Gbps Ethernet (as can Fibre Channel via FCoE), those performance-oriented arguments are crumbling.
But don’t take my word for it.
openBench Labs (which contributes lab reviews to InfoStor), recently set up an interesting test case by building a modest, inexpensive 10GbE iSCSI storage network that turned in some impressive performance results.
You’ll have to read the full review to put some perspective on the performance numbers, but openBench Labs CTO Jack Fegreus clocked average throughput of 5,000 I/Os per second (IOPS) with one virtual machine (VM), which was in line with what openBench Labs achieved with direct Fibre Channel access to the same disk array in previous tests. With two VMs, throughput scaled to about 8,200 IOPS.
Jack concludes his review with this observation: “Given these results, our 10GbE iSCSI configuration with QLogic Intelligent Ethernet Adapters should be able to support the installation of Microsoft Exchange Server on a VM with upwards of 5,000 mail boxes.” Quite sufficient for most SMBs. “The simplest and most immediate strategy for IT to begin leveraging 10GbE in a data center, especially when dealing with a virtual environment, is to begin implementing iSCSI.”
Jack’s 10GbE iSCSI network consisted of three Dell PowerEdge servers running Windows Server 2008 R2 and VMware ESX Server 4; iSCSI software from StarWind; dual-port 10GbE Ethernet adapters and 4Gbps Fibre Channel HBAs from QLogic; and a Xiotech Emprise 5000 disk array with two 4Gbps Fibre Channel ports. Performance was measured with Intel’s Iometer benchmark.
Check out the full review: “How to jumpstart SAN + LAN convergence.”
Related blog posts:
Virtual server SANs: FC vs. iSCSI vs. NAS
Intel, Microsoft top 1,000,000 IOPS in iSCSI tests
Video surveillance is a real sweet spot for iSCSI
NAS gains in virtual server environments
And you might want to consider attending this upcoming (May 26) SNIA Webcast: “iSCSI and New Approaches to Backup and Recovery.”
Wednesday, April 28, 2010
Video surveillance is a real sweet spot for iSCSI IP SANs
April 28, 2010 – According to an end-user survey conducted by the Enterprise Strategy Group (ESG) late last year, 28% of the surveyed companies already use iSCSI. And if you factor in the companies that plan to use iSCSI, that number jumps to 52%.
As ESG analyst Mark Peters said in a blog post (see “iSCSI Adoption Continues its Upward Path”): “Not bad for a storage protocol that was dismissed by some as the equivalent of the poor kid from the IT housing projects a few years back.”
(ESG surveyed 1,488 companies ranging from 100 to more than 20,000 employees.)
According to Peters, adoption of iSCSI-based IP SANs is being driven largely by the surge in server virtualization deployments and IT budget pressures. But it’s also due to a widening of the use cases for iSCSI.
One of the hottest spots for IP SANs is in video surveillance. IMS Research recently completed a report, The World Market for Enterprise and IP Storage used for Video Surveillance, which predicts that the IP SAN market for video surveillance will grow at a CAGR of 66.7% between 2008 and 2013.
Drawing from the report (because I don’t know squat about video surveillance), IP video has traditionally been recorded on commercial off-the-shelf (COTS) servers, digital video recorders (DVRs) or network video recorders (NVRs).
NVRs are optimized for video surveillance, but they don’t work well in environments with lots of cameras. Same with digital video recorders (DVRs).
The COTS server approach is inexpensive and reasonably scalable, but the servers aren’t optimized for video surveillance.
IMS Research analyst William Rhodes says that the three key reasons why IP SANs will take over in the video surveillance market are:
--IP SANs go beyond COTS servers with feature such as RAID, failover and virtualization.
--iSCSI is less expensive than Fibre Channel SANs.
--IP SANs can be used to replace COTS servers and NVRs because storage suppliers have recently incorporated the server running the video management software (VMS), creating a single boxed appliance.
Most RAID vendors are going after the video surveillance market, but Rhodes cites the following vendors as examples of storage suppliers that are particularly focused on the video surveillance space, both of which offer “server-less” IP SANs: Intransa and Pivot3.
For more information on the report or the video surveillance storage market, contact William Rhodes or visit the IMS Research web site.
As ESG analyst Mark Peters said in a blog post (see “iSCSI Adoption Continues its Upward Path”): “Not bad for a storage protocol that was dismissed by some as the equivalent of the poor kid from the IT housing projects a few years back.”
(ESG surveyed 1,488 companies ranging from 100 to more than 20,000 employees.)
According to Peters, adoption of iSCSI-based IP SANs is being driven largely by the surge in server virtualization deployments and IT budget pressures. But it’s also due to a widening of the use cases for iSCSI.
One of the hottest spots for IP SANs is in video surveillance. IMS Research recently completed a report, The World Market for Enterprise and IP Storage used for Video Surveillance, which predicts that the IP SAN market for video surveillance will grow at a CAGR of 66.7% between 2008 and 2013.
Drawing from the report (because I don’t know squat about video surveillance), IP video has traditionally been recorded on commercial off-the-shelf (COTS) servers, digital video recorders (DVRs) or network video recorders (NVRs).
NVRs are optimized for video surveillance, but they don’t work well in environments with lots of cameras. Same with digital video recorders (DVRs).
The COTS server approach is inexpensive and reasonably scalable, but the servers aren’t optimized for video surveillance.
IMS Research analyst William Rhodes says that the three key reasons why IP SANs will take over in the video surveillance market are:
--IP SANs go beyond COTS servers with feature such as RAID, failover and virtualization.
--iSCSI is less expensive than Fibre Channel SANs.
--IP SANs can be used to replace COTS servers and NVRs because storage suppliers have recently incorporated the server running the video management software (VMS), creating a single boxed appliance.
Most RAID vendors are going after the video surveillance market, but Rhodes cites the following vendors as examples of storage suppliers that are particularly focused on the video surveillance space, both of which offer “server-less” IP SANs: Intransa and Pivot3.
For more information on the report or the video surveillance storage market, contact William Rhodes or visit the IMS Research web site.
Monday, February 8, 2010
Virtual server SANs: FC vs. iSCSI vs. NAS
February 8, 2010 – In the beginning, most virtual server environments relied on either Fibre Channel SANs or direct-attached storage (DAS). As the virtual environments grew, end users quickly found out that DAS wasn’t going to cut it. Fibre Channel remained king for awhile (and still is), but iSCSI – and NAS – appear to be coming on strong.
In mid-2009, we polled infostor.com visitors regarding what type of storage network protocol they were using in their virtual server environments:
The question: “If you have virtual servers, what is your primary storage configuration? (check one)”
The results: 53% cited Fibre Channel SAN; 28% iSCSI SAN; 10% NAS; and 9% DAS.
A recent report from Forrester Consulting, based on a survey commissioned by Dell (no doubt the EqualLogic crew), suggests that iSCSI – as well as NAS -- is narrowing the gap with Fibre Channel. Forrester surveyed 200 IT storage decision-makers.
The question: “What storage network protocol(s) are you using (or plan to use) for your virtual server environment? (select all that apply)”
The results: 59% Fibre Channel, 57% iSCSI, and 52% NFS [NAS]. Almost a dead heat. (3% of the respondents are using non-networked storage; e.g., DAS.)
In addition to the impressive showing of both iSCSI and NAS, a key conclusion here is that end users are obviously using a mix of storage protocols in their virtual server environments.
There was, however, one seeming inexplicable anomaly in the results to that Forrester survey question: 33% cited FCoE. I’m at a loss to explain that, but here’s the explanation from the report’s authors:
“FCoE interest appears very high. There may well be some confusion regarding the adoption of FCoE, as anecdotal evidence suggests that the 34% current usage number [referring to another question] is very high for this emerging protocol. Products are just now coming onto the market and are usable only for the server side of storage networking, aggregating traffic in top-of-rack and edge switches. The reality here is likely that respondents have interest in or plans to move forward with FCoE, but have not yet implemented FCoE in such high numbers.
Confusion with FCIP, used to carry FC traffic over the WAN for distance replication, may also be increasing the adoption rates reported in this survey.
Another area of confusion relates to the adoption of 10GbE. Respondents who stated that they currently have FCoE in place in the quantitative survey revealed in interviews that they actually have 10GbE for file data traffic but are not using FCoE equipment. Suffice it to say that interest in FCoE is high at this point, but confusion about what really constitutes FCoE is clouding the adoption picture.”
Back to Fibre Channel, iSCSI and NAS: Not surprisingly, use of these protocols in virtual server environments varies by the size of the organization. For example, 70% of large enterprises (1,000 or more employees) cited Fibre Channel, compared to 50% of the SMBs.
66% of the SMBs cited iSCSI, compared to 47% of the large enterprises. And 49% of the SMBs cited NFS, compared to 57% of large enterprises.
The full report is posted on Dell’s site: “Benefits Of SAN/LAN Convergence: Evaluating Interest In And Readiness For Unified Fabric,” is posted on Dell’s site.
If you’re struggling with the storage challenges associated with rapidly growing virtual server environments, consider attending our Webcast, “Managing VM Sprawl and Reducing Costs with Disk Archiving,” tomorrow (Tuesday), February 9 at 10:00 PST, 1:00 EST.
You can get a description of the Webcast and register HERE.
In mid-2009, we polled infostor.com visitors regarding what type of storage network protocol they were using in their virtual server environments:
The question: “If you have virtual servers, what is your primary storage configuration? (check one)”
The results: 53% cited Fibre Channel SAN; 28% iSCSI SAN; 10% NAS; and 9% DAS.
A recent report from Forrester Consulting, based on a survey commissioned by Dell (no doubt the EqualLogic crew), suggests that iSCSI – as well as NAS -- is narrowing the gap with Fibre Channel. Forrester surveyed 200 IT storage decision-makers.
The question: “What storage network protocol(s) are you using (or plan to use) for your virtual server environment? (select all that apply)”
The results: 59% Fibre Channel, 57% iSCSI, and 52% NFS [NAS]. Almost a dead heat. (3% of the respondents are using non-networked storage; e.g., DAS.)
In addition to the impressive showing of both iSCSI and NAS, a key conclusion here is that end users are obviously using a mix of storage protocols in their virtual server environments.
There was, however, one seeming inexplicable anomaly in the results to that Forrester survey question: 33% cited FCoE. I’m at a loss to explain that, but here’s the explanation from the report’s authors:
“FCoE interest appears very high. There may well be some confusion regarding the adoption of FCoE, as anecdotal evidence suggests that the 34% current usage number [referring to another question] is very high for this emerging protocol. Products are just now coming onto the market and are usable only for the server side of storage networking, aggregating traffic in top-of-rack and edge switches. The reality here is likely that respondents have interest in or plans to move forward with FCoE, but have not yet implemented FCoE in such high numbers.
Confusion with FCIP, used to carry FC traffic over the WAN for distance replication, may also be increasing the adoption rates reported in this survey.
Another area of confusion relates to the adoption of 10GbE. Respondents who stated that they currently have FCoE in place in the quantitative survey revealed in interviews that they actually have 10GbE for file data traffic but are not using FCoE equipment. Suffice it to say that interest in FCoE is high at this point, but confusion about what really constitutes FCoE is clouding the adoption picture.”
Back to Fibre Channel, iSCSI and NAS: Not surprisingly, use of these protocols in virtual server environments varies by the size of the organization. For example, 70% of large enterprises (1,000 or more employees) cited Fibre Channel, compared to 50% of the SMBs.
66% of the SMBs cited iSCSI, compared to 47% of the large enterprises. And 49% of the SMBs cited NFS, compared to 57% of large enterprises.
The full report is posted on Dell’s site: “Benefits Of SAN/LAN Convergence: Evaluating Interest In And Readiness For Unified Fabric,” is posted on Dell’s site.
If you’re struggling with the storage challenges associated with rapidly growing virtual server environments, consider attending our Webcast, “Managing VM Sprawl and Reducing Costs with Disk Archiving,” tomorrow (Tuesday), February 9 at 10:00 PST, 1:00 EST.
You can get a description of the Webcast and register HERE.
Wednesday, January 20, 2010
Intel, Microsoft top 1,000,000 IOPS in iSCSI tests
January 21, 2010 – In conjunction with Microsoft, Intel recently announced that it surpassed one million I/Os per second (IOPS) in an iSCSI performance test. See the Webcast link near the bottom of this post if you want detailed information on the tests and configurations, but basically the test configuration included a standard server with one Intel 10 Gigabit Ethernet (10GbE) server adapter (model X520-2), a quad-core Xeon 5500-series CPU, Windows Server 2008 R2, Microsoft’s iSCSI initiator software, and Hyper-V.
Other test elements included Cisco’s 10GbE Nexus 5020 switch connected to ten iSCSI soft targets.
Specifically, Intel and Microsoft clocked 1,030,000 IOPS (with 512-byte blocks), and more than 2,250MBps with large block sizes (16KB to 256KB) using the Iometer benchmark, which is waaaay beyond any iSCSI performance specs that I’ve seen.
It’s stuff like this that might bring back the old iSCSI vs. FC/FCoE controversy.
Of course, one million IOPS is overkill for most of today’s applications, so I queried Microsoft and Intel representatives about what these tests results really prove.
“These tests negate skepticism about iSCSI performance and its ability to be deployed in an enterprise environment,” says Sunil Ahluwalia, Intel’s product line manager, data center products. “They also demonstrate the head room you have with 10GbE and iSCSI.”
“From a virtualization perspective, heavily transaction-intensive applications such as databases tend to be the last applications to be virtualized, and these tests are a proof point for being able to use iSCSI in virtual environments with those types of applications,” says Dai Vu, Microsoft’s director of virtualization products and solutions marketing.
It was also a chance for Microsoft to show off some of the iSCSI and storage enhancements in the R2 version of Windows Server 2008, including iSCSI multi-core and NUMA I/O, DPC redirection, dynamic load balancing, storage I/O monitoring, CRC digest offload, and support for 32 paths at boot time.
For details on the iSCSI tests, see
the archived Microsoft-Intel Webcast
Intel’s blog
And in other one-million-IOPS news, Emulex recently announced that its FCoE-based OneConnect converged network adapters (CNAs) hit 919,000 IOPS in tests conducted by IT Brand Pulse. You can read the press release here.
Other test elements included Cisco’s 10GbE Nexus 5020 switch connected to ten iSCSI soft targets.
Specifically, Intel and Microsoft clocked 1,030,000 IOPS (with 512-byte blocks), and more than 2,250MBps with large block sizes (16KB to 256KB) using the Iometer benchmark, which is waaaay beyond any iSCSI performance specs that I’ve seen.
It’s stuff like this that might bring back the old iSCSI vs. FC/FCoE controversy.
Of course, one million IOPS is overkill for most of today’s applications, so I queried Microsoft and Intel representatives about what these tests results really prove.
“These tests negate skepticism about iSCSI performance and its ability to be deployed in an enterprise environment,” says Sunil Ahluwalia, Intel’s product line manager, data center products. “They also demonstrate the head room you have with 10GbE and iSCSI.”
“From a virtualization perspective, heavily transaction-intensive applications such as databases tend to be the last applications to be virtualized, and these tests are a proof point for being able to use iSCSI in virtual environments with those types of applications,” says Dai Vu, Microsoft’s director of virtualization products and solutions marketing.
It was also a chance for Microsoft to show off some of the iSCSI and storage enhancements in the R2 version of Windows Server 2008, including iSCSI multi-core and NUMA I/O, DPC redirection, dynamic load balancing, storage I/O monitoring, CRC digest offload, and support for 32 paths at boot time.
For details on the iSCSI tests, see
the archived Microsoft-Intel Webcast
Intel’s blog
And in other one-million-IOPS news, Emulex recently announced that its FCoE-based OneConnect converged network adapters (CNAs) hit 919,000 IOPS in tests conducted by IT Brand Pulse. You can read the press release here.
Monday, October 5, 2009
iSCSI + NAS for virtual servers?
October 8, 2009 – When end users first started the mass migration to virtual servers, the majority did so with direct-attached storage (DAS) as the underlying storage architecture. They quickly found out that virtualization required networked storage, and the incumbent SAN protocol – Fibre Channel – became the front runner in the race toward dominance in server virtualization storage architectures.
Fibre Channel SANs are still the dominant storage architectures in virtual operating environments, but iSCSI – and also NAS – are coming on strong.
In an infostor.com QuickVote poll (conducted last year), we asked virtual server users what their primary storage configuration was. More than half (53%) cited Fibre Channel SANs, 28% were relying primarily on iSCSI, 10% on NAS, and only 9% on DAS. Since then, I’m sure the percentages for iSCSI and NAS have shifted upward.
That survey didn’t ask whether users were combining different storage architectures to support their burgeoning virtual server implementations. However, combining SANs and NAS appears to be a strong trend.
In an end-user survey, Enterprise Strategy Group (ESG) posed the following question:
Does your organization have plans to consolidate NAS and SAN storage resources into a unified storage architecture that supports both file-based NAS and block-based SAN storage?
With the caveat that the question was not posed in a virtual server context, it’s interesting to note that well over half of the respondents (67%) planned to pursue a “unified storage” (SAN+NAS) strategy. In fact, 18% were already underway – and the ESG survey was conducted late last year.
Among those that are moving to unified storage architectures, 41% plan to rely primarily on NAS gateways to front-end SANs; 18% plan to rely primarily on unified NAS-SAN storage systems; and 40% plan to use both approaches.
If you’re among the growing group of users that are deploying iSCSI + NAS architectures – particularly if you have virtual servers – check out our Webcast, “Unified Storage for Virtual Servers: iSCSI SANs and NAS.” If you missed the "live" version earlier this week, you can view the archived version here.
ESG analyst Terri McClure presents interesting data from ESG’s end-user surveys and discusses trends in the context of unified storage and virtual servers. And John McArthur, president and co-founder of Walden Technology Partners, discusses solutions that enable you to combine iSCSI SANs and NAS to optimize efficiencies in virtual server environments – at a low cost and with minimal management overhead.
Choosing the right storage architecture for your virtual server environment is not an either-or decision.
Fibre Channel SANs are still the dominant storage architectures in virtual operating environments, but iSCSI – and also NAS – are coming on strong.
In an infostor.com QuickVote poll (conducted last year), we asked virtual server users what their primary storage configuration was. More than half (53%) cited Fibre Channel SANs, 28% were relying primarily on iSCSI, 10% on NAS, and only 9% on DAS. Since then, I’m sure the percentages for iSCSI and NAS have shifted upward.
That survey didn’t ask whether users were combining different storage architectures to support their burgeoning virtual server implementations. However, combining SANs and NAS appears to be a strong trend.
In an end-user survey, Enterprise Strategy Group (ESG) posed the following question:
Does your organization have plans to consolidate NAS and SAN storage resources into a unified storage architecture that supports both file-based NAS and block-based SAN storage?
With the caveat that the question was not posed in a virtual server context, it’s interesting to note that well over half of the respondents (67%) planned to pursue a “unified storage” (SAN+NAS) strategy. In fact, 18% were already underway – and the ESG survey was conducted late last year.
Among those that are moving to unified storage architectures, 41% plan to rely primarily on NAS gateways to front-end SANs; 18% plan to rely primarily on unified NAS-SAN storage systems; and 40% plan to use both approaches.
If you’re among the growing group of users that are deploying iSCSI + NAS architectures – particularly if you have virtual servers – check out our Webcast, “Unified Storage for Virtual Servers: iSCSI SANs and NAS.” If you missed the "live" version earlier this week, you can view the archived version here.
ESG analyst Terri McClure presents interesting data from ESG’s end-user surveys and discusses trends in the context of unified storage and virtual servers. And John McArthur, president and co-founder of Walden Technology Partners, discusses solutions that enable you to combine iSCSI SANs and NAS to optimize efficiencies in virtual server environments – at a low cost and with minimal management overhead.
Choosing the right storage architecture for your virtual server environment is not an either-or decision.
Wednesday, May 20, 2009
StarWind offers free iSCSI software
May 21, 2009 – iSCSI’s value proposition has always been lower cost than Fibre Channel SANs. StarWind Software is taking that value proposition to new levels with a free version of its iSCSI target software.
Free iSCSI isn’t new. Most of the iSCSI initiators are free (including Microsoft’s) and a few vendors offer free iSCSI target software. However, most of those are limited in the number of iSCSI connections you can have and/or the amount of capacity supported.
In contrast, StarWind’s free iSCSI target software supports an unlimited number of iSCSI connections and an impressive 2TB of capacity.
Of course, you don’t get StarWind’s thin provisioning, CDP, snapshots, mirroring or replication functionality for free, but unlimited connections and support for 2TB is a great deal. The software installs on any 32-bit or 64-bit Windows server, and turns the server into a shared storage SAN device.
But wait, there’s more. The software supports virtual server environments such as VMware ESX and ESXi (and can run inside a VM) and Microsoft’s Hyper-V, as well as server clustering.
To grab a copy of the software, visit the StarWind iSCSI Target Free Version Download Site.
For those not familiar with StarWind: The company has been selling its iSCSI software since 2003, and claims to have more than 1,000 customers that paid for its software and more than 15,000 that have downloaded a previous free version (which only supported 2GB of capacity).
Free iSCSI isn’t new. Most of the iSCSI initiators are free (including Microsoft’s) and a few vendors offer free iSCSI target software. However, most of those are limited in the number of iSCSI connections you can have and/or the amount of capacity supported.
In contrast, StarWind’s free iSCSI target software supports an unlimited number of iSCSI connections and an impressive 2TB of capacity.
Of course, you don’t get StarWind’s thin provisioning, CDP, snapshots, mirroring or replication functionality for free, but unlimited connections and support for 2TB is a great deal. The software installs on any 32-bit or 64-bit Windows server, and turns the server into a shared storage SAN device.
But wait, there’s more. The software supports virtual server environments such as VMware ESX and ESXi (and can run inside a VM) and Microsoft’s Hyper-V, as well as server clustering.
To grab a copy of the software, visit the StarWind iSCSI Target Free Version Download Site.
For those not familiar with StarWind: The company has been selling its iSCSI software since 2003, and claims to have more than 1,000 customers that paid for its software and more than 15,000 that have downloaded a previous free version (which only supported 2GB of capacity).
Wednesday, October 22, 2008
FCoE vs. iSCSI, take 1
The emerging Fibre Channel over Ethernet (FCoE) standard promises to bring back the good old days of the raging Fibre Channel vs. iSCSI debates. Or does it?
First, a little history. When the FCoE concept was first hatched about two years ago, naysayers -- and sometimes the press -- jumped all over it: FCoE was a "last ditch ploy" by Fibre Channel "bigots" to stem the "inevitable tide of Ethernet" taking over all types of data center traffic, including storage via the iSCSI protocol. The rhetoric ran rampant, but then it died down into more politically correct statements such as "Fibre Channel and iSCSI are complementary, not competitive."
I actually bought that for awhile, in part because I (and many others) didn't think that iSCSI would ever be considered for enterprise data centers (which is where FCoE would play). As such, iSCSI would eventually dominate at the departmental level and at SMBs while Fibre Channel, or FCoE, would dominate in data centers as companies moved to converged networks, or whatever you want to call them.
Then along came 10GbE (10Gbps Ethernet) which, once it gets cheaper, all of a sudden makes iSCSI seem feasible as the kingpin storage protocol for data centers. Then again, I don't see data-center managers (or at least the storage managers) giving up on all the Fibre Channel equipment, software, and expertise they've accumulated.
It does seem clear that data-center managers will eventually have to make a choice between FCoE and iSCSI, assuming they're moving to converged networks. Hence the controversy and all the early promotional activity from the FCoE camp.
Another possibility is that FCoE will be used as an interim "stepping stone" technology on the path to a true converged network with one physical layer transport for all traffic.
Yet another possibility: The real competitor for FCoE is not iSCSI but, rather, the status quo. In this scenario, data centers keep their Fibre Channel SANs for storage and their Ethernet LANs for everything else -- and never the twain shall meet.
Maybe I just have FCoE on the brain because of some of the company I kept at last week's Storage Networking World show -- which included Brocade, Emulex, and QLogic -- but in my next blog I'll look at some of the lingering questions/issues surrounding this nascent technology.
First, a little history. When the FCoE concept was first hatched about two years ago, naysayers -- and sometimes the press -- jumped all over it: FCoE was a "last ditch ploy" by Fibre Channel "bigots" to stem the "inevitable tide of Ethernet" taking over all types of data center traffic, including storage via the iSCSI protocol. The rhetoric ran rampant, but then it died down into more politically correct statements such as "Fibre Channel and iSCSI are complementary, not competitive."
I actually bought that for awhile, in part because I (and many others) didn't think that iSCSI would ever be considered for enterprise data centers (which is where FCoE would play). As such, iSCSI would eventually dominate at the departmental level and at SMBs while Fibre Channel, or FCoE, would dominate in data centers as companies moved to converged networks, or whatever you want to call them.
Then along came 10GbE (10Gbps Ethernet) which, once it gets cheaper, all of a sudden makes iSCSI seem feasible as the kingpin storage protocol for data centers. Then again, I don't see data-center managers (or at least the storage managers) giving up on all the Fibre Channel equipment, software, and expertise they've accumulated.
It does seem clear that data-center managers will eventually have to make a choice between FCoE and iSCSI, assuming they're moving to converged networks. Hence the controversy and all the early promotional activity from the FCoE camp.
Another possibility is that FCoE will be used as an interim "stepping stone" technology on the path to a true converged network with one physical layer transport for all traffic.
Yet another possibility: The real competitor for FCoE is not iSCSI but, rather, the status quo. In this scenario, data centers keep their Fibre Channel SANs for storage and their Ethernet LANs for everything else -- and never the twain shall meet.
Maybe I just have FCoE on the brain because of some of the company I kept at last week's Storage Networking World show -- which included Brocade, Emulex, and QLogic -- but in my next blog I'll look at some of the lingering questions/issues surrounding this nascent technology.
Subscribe to:
Posts (Atom)