|
|
|
|
 |
| Tech Update
|
|
Why SAN and NAS will converge
Why SAN and NAS will converge (continued)
|
By Sean Derrington
Meta Group
March 14, 2002
| Provided by |  |
|
|
|
|
Auspex is attempting to broaden its market opportunities by separating the once tightly coupled disk subsystem and NAS heads, and is prospecting for OEMs and resellers to deliver the new architecture. Although Auspex is not broadening into the SAN market (FC as a host interconnect for general-purpose servers), it is taking an important step in decoupling the fixed-storage appliance model and working with multiple storage vendors for its NAS head connectivity and file-sharing services. Although SAN vendors have many benefits to offer, there is a price for certifying channel connectivity to general-purpose servers that becomes complex quickly, resulting in significant dedicated engineering resources. NAS vendors that venture into the SAN (block/channel-attached) market will be required to go through similar complex certification (as the competition has been doing since 1995). Consequently, the value/add (and differentiation) of the often proprietary file system used in the NAS products will not migrate to the SAN products beyond the file-sharing capability of clients accessing information through the NAS heads.
| [an error occurred while processing this directive] |
Truly combining NAS and SAN or just smoke and mirrors?
One of the major problems vendors have been trying to solve is how to implement a network file system (scaling both in storage capacity and number of servers/clients) that has the same, if not superior, performance/reliability characteristics as channel-attached storage by simply eliminating the latency and unreliability of TCP/IP. Veritas (CFS), Sun (QFS), and Network Appliance (DAFS [Direct Access File System] and VI [Virtual Interface Architecture]) are the incumbent vendors (not necessarily the file systems) and Tricord (with Lunar Flare) and other startups are the challengers. However, ITOs should realize DAFS and VI are not file systems, but rather techniques for low-latency direct memory access (e.g., memory access across computer nodes) that require specific application and database versions (which are currently not generally available), which we believe will limit the adoption of these techniques through 2004. However, regardless of the aforementioned approaches, there is a reliance and dependence on file systems. Many will be proprietary, and ITOs should consider how they interact with general-purpose servers (particularly if it is a file system on dedicated appliances sitting in the data path) and storage operations (e.g., backup/recovery, replication).
iSCSI, FCIP, iFCP, and SoIP--What does it all mean?
iSCSI (Internet SCSI), FCIP (Fibre Channel over IP), iFCP (Internet Fibre Channel Protocol), and SoIP (Storage over IP) are proposals (none are standards) by which vendors are trying to extend channel-based networks while exploiting ubiquitous Ethernet local-area networks and inter-data center wide-area network connectivity. Despite the lofty goals, many challenges exist with these approaches as a replacement for FC as the network for continuous data access of servers and storage in the data center. Contrary to the common transport (Ethernet), storage vendors that utilize iSCSI or SoIP for direct-server-to-storage-subsystem connectivity should be compared and evaluated as SAN vendors where the file to block translation happens at the general-purpose server. ITOs should not confuse the network transport (Fibre Channel Protocol or Ethernet) with CIFS/NFS (file) or SCSI-3 (block) commands. NAS vendors offering iSCSI connectivity are now SAN vendors and will suffer all the limitations of IP SANs, and more than likely loose the tight coupling with the proprietary file systems in the NAS appliance. Moreover, we believe vendors that try to differentiate themselves via networking protocols (e.g., iSCSI) will not add any value. The value is in the storage software and management on either end of the wire - not the wire transport itself.
Business impact: Business and application requirements will be satisfied by various evolving storage architectures, but lines of business should be concerned with service levels, not underlying technologies.
Bottom line: Through 2005, network-attached storage and storage-area network architectures will continue to converge. The convergence will primarily be from a functional, not a technology, perspective, and servers will still fundamentally access storage resources via file or block services, yet the satisfaction of those requests is the area of convergence.
 |
|
|
|
[an error occurred while processing this directive]
![]() |
|
[an error occurred while processing this directive] |
![]() |
|
![]() |
[an error occurred while processing this directive]
|
|
[an error occurred while processing this directive]
|
[an error occurred while processing this directive] |
|
[an error occurred while processing this directive]
|
|
|
|
