What do you think are the pros and cons of this approach? It provides the switch vendor with a proprietary way...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
of locking in customers. It will be much more expensive as a switch and as an application platform, with no better application integration. The application SAN switch does not provide tighter integration of the server platform with the switch. It merely eliminates the cabling of the platform to the switch for a significant cost. A less expensive switch with fabric-connected application servers will cost less, scale better, and have a much lower TCO. Creating a highly [reliable, available and serviceable] environment for those switches will be somewhat complex and cost more. Switches and directors make good switches and lousy application platforms. What is your take on the trend toward putting 'intelligence' on the network in the form of applications on a fabric switch? It's a vendor trend, not a user requirement. I can see no compelling value proposition to the end user or the OEM in integrating a server or servers into the switch architecture. What are the dangers of putting applications on a fabric switch? What problems could occur? It depends on the application and the fabric switch architecture. Making the application highly [reliable, available and serviceable] can be both complex and expensive. In some cases, making the application on the SAN switch highly reliable, available and serviceable between multiple switches is potentially not viable.
The application switch architecture, if proprietary, could force the ISVs into difficult and lengthy ports. This means that the application switch platform will most likely be the last platform for software updates and upgrades and may in fact skip generations of features.
Not all ISVs will support the application switch and, in fact, many will not. Volumes will not justify the support. Not all application switches will be supported either. Most ISVs will support general purpose servers running Linux and/or Windows. You've said that putting applications on the fabric is not necessarily a bad idea, but that putting them on a switch is. Can you elaborate on this statement? Does this mean that a dedicated appliance in the fabric is the way to go?
It is one way to go. I see a more compelling value proposition for the general purpose server that happens to run SAN or storage applications on the fabric. It's open. It uses standard OS and server hardware. It will continually get more powerful and faster as servers become more powerful and faster. It can be clustered for high [reliability, availability and serviceability]. It can be implemented in new form factors, such as blade servers, PCI-express, InfiniBand, etc. And most importantly, it leverages both vendor and end-user investment. The application does not have to be platform aware and is highly portable. One final point, the general purpose server can have standardized 'purpose-built' cards that accelerate the application functions and the data movement. Some switch makers claim that putting some host and target applications on a fabric switch will give customers cheaper options when it comes to choosing a storage array. Do you agree or disagree?
That's the long-term potential and, odds are, it will not be 'cheaper.' To truly be 'cheaper,' the applications they are talking about will have to provide not just some, but most of the storage array functionality [such as RAID 0, 1, 0+1, 3, replication, proactive storage maintenance and management, and policy-based management and provisioning]. It will also have to be, minimally, as easy as their current storage architecture and preferably much simpler.
The software on the enterprise-level controllers [from companies like EMC Corp., Hitachi Data Systems and IBM Corp.] is far more mature and tested than any ISV software. It is also more tightly integrated with the back-end hard disk drives. This is another area where the application switch misses the boat. The target storage is already getting very inexpensive and continues to decline in price. As newer back-end technologies become integrated into the array, prices will drop even further. The significant increase in cost in the fabric will actually increase the total cost of ownership of storage versus decrease it. Do you think all of the major storage switch makers -- Brocade, Cisco, McData, QLogic and Inrange -- will move toward 'intelligent' switching platforms? Do you think that, if they do, the customers will follow?
Yes to Brocade and Cisco, no to McData, QLogic and Inrange. I do not believe that either the storage OEMs or the end-user customers will follow until there is a compelling value proposition. Inrange and McData are taking a hybrid approach, where they put hardware-assist capabilities in their switches that are slaved to the target controllers or storage application servers or appliances. In other words, they are in the data path, not the control path. This allows the switch to do what it does best, and the application servers or target controllers to do what they do best. This approach leverages what the switch/director does best in conjunction with the application. It appears to be a better price-performance solution that may ultimately solve end-user and OEM problems more intelligently. Let us know what you think about the story, e-mail Kevin Komiega, News Writer
FOR MORE INFORMATION:Brocade recruits partners for new switching platform Experts offer dos and don'ts on networked storage SAN topologies, part 1: Know your switch options Comment on this article in the SearchStorage Discussion forums