Slashdot Mirror
Broadcom Gets Green Light From Feds To Buy San Jose's Brocade For $5.9 billion (bizjournals.com)
Chipmaker Broadcom on Monday won approval from the U.S. Federal Trade Commission to purchase San Jose-based Brocade Communications Systems for $5.9 billion. From a report: To land U.S. approval, Broadcom had to promise federal regulators not to use information from the acquisition to hurt Cisco Systems. At issue with U.S. regulators was possible impacts on Cisco, since Cisco buys chips from Broadcom, but competes with Brocade. On the flip side, regulators worried Broadcom might use its position as supplier and competitor to raise the prices on fiber channel switches, a niche networking segment that's owned completely by Brocade and Cisco. To assuage those concerns, Broadcom agreed to set up an operations "firewall" internally, so that competitive information that might hurt Cisco won't be shared internally. It also agreed to submit to regulatory oversight for five years after the deal is completed.
iSCSI and other IP-addressable storage technologies are fine for hobbyist computing, backup targets and of course is required for IAAS beyond a certain scale.
In the middle, where most businesses of 30 users plus live, application level redundancy is brittle and expensive, many interactive services have tight performance requirements (ie: XenApp/XenDesktop/RDS) and iSCSI is complete trash. It's not like webapps where you can scale resources up/down without much user impact and backend IOPS isn't a huge concern. Even with proper storage hardware (3PAR, EMC, NetApp) the difference in performance is noticeable. Trying to fix some of the issues by bringing storage-grade IP switching in is often more expensive than simply using FC (don't even get started on FCoE). NFS has some reasonable supporters (eg, NetApp) where it works well and exposes a lot of cool features, but it still suffers from network-layer problems unless you have deep pockets. Every L2 segment is a point of failure, every L3 hop adds latency and complexity, and failover when you need it, often doesn't. FC on reasonable kit is easy to deterministically validate or test and delivers hard performance guarantees in the connectivity layer.
I'm not sure what you're talking about with NAS vs SAN - you're not running any databases over a network share. But you are correct, I haven't seen a lot of raw LUNs used by DBs for a while. Block storage presented to the OS and used by it as a local disk means you've got a SAN. If you're using iSCSI, it's a SAN. If you're mounting disk images over NFS, kind of a hybrid SAN - it's just using NFS for block-storage access. A NetApp with a Filer attached is a NAS sitting on top of a SAN.
Once you hit large IAAS or cloud clusters, you're either enjoying extremely poor I/O performance or there's some local I/O caching in compute nodes, reducing the amount of IOPS having to head across the datacentre to the storage clusters. Here, iSCSI and related technologies are brilliant, you can just keep packing in storage and spreading load across compute resources.
Except that iSCSI sucks compared to fibre channel. There is a reason why FCoE required data centre bridging and if you don't understand why they you are not qualified to comment on the issue.
The price of a DCB capable network is around the same price as a FC network.