Traditional storage architectures for embedded, high-reliability applications require physically separate, application-specific sub- networks. iSCSI offers freedom from direct attachment to storage devices, opening distributed systems to a much wider variety of architectures.
As mobile devices become more powerful, continuous network connectivity is increasingly prevalent in military, enterprise and consumer environments. Consequently, access to mass storage by large numbers of highly distributed clients will lead the way to a new class of applications where lower cost, ease of management, expandability and unlimited connectivity will be key performance requirements.
The rise of mezzanine-led architectures such as ATCA and MicroTCA presents an excellent opportunity for Internet Protocol (IP)-based storage. Ethernet is the dominant backplane architecture for the current generation of ATCA deployments, which tend to center on control-plane applications. The Internet Small Computer System Interface (iSCSI) is a good match for IP-over-Ethernet from blade or mezzanine module clients reaching across the backplane to in-chassis, blade-based storage, as well as out-of-chassis network-based storage. Additionally, embedded iSCSI target implementations that “virtualize” external storage for intra-chassis use may be deployed as mezzanine-based storage adapters for bridging to legacy storage deployments.
iSCSI in Distributed Storage Applications
High-end embedded applications can benefit from using iSCSI for linking data storage systems. By carrying SCSI commands over IP networks, iSCSI helps facilitate data transfers over intranets and manage storage over long distances. Embedded devices can access “virtually local” storage via arbitrary network connections, without expensive or specialized host adapter hardware.
iSCSI is designed to transport block I/O via an IP network rather than files from a filesystem. The client-side handler for the iSCSI protocol is called an initiator, while the server-side handler is called a target. Session management and other communication between client and server endpoints are handled via well-known SCSI command sets, which are carried across the intervening TCP/IP network.
Embedded within the interactions between iSCSI initiators and targets are a number of important considerations. These issues arise directly from the session-oriented nature of the protocol sets, the general unreliability and insecurity of IP networks and the application scenarios that result from this powerful, new distributed storage paradigm.
iSCSI vs. Other Storage Architectures
iSCSI differs from other storage architectures in several ways (Figure 1). In direct-attached storage (DAS), a storage device is directly attached to a host node via a local bus. Embedded systems often use DAS to store OS images and local data, while using SCSI or Serial Attached SCSI (SAS) storage protocols to access the data.
Network-attached storage (NAS) refers to a host that provides network-based access to some local storage, possibly DAS, via a client/server paradigm such as Network File System (NFS). Typically, NAS-based approaches lack scalability and experience serious performance bottlenecks due to the layering of filesystem and application-level structures on top of the storage transport layer.
A storage area network (SAN) consists of dedicated storage devices on a private storage-optimized network, or fabric, which share access to media via an arbitration scheme. Fibre Channel (FC) is arguably the most common form of SAN. Like FC, iSCSI uses the SCSI storage protocol to access media. Unlike FC, iSCSI is agnostic of the network transport layer and has no distance limitations.
Embedding iSCSI in Different Application Scenarios
Most application scenarios for iSCSI deployment focus on simplified access to aggregated storage. The initiator/target architecture of the protocol lends itself to a form of highly scalable disk virtualization. Highly portable iSCSI software solutions allow system designers to easily embed this storage architecture into any hardware device—ASIC, mezzanine card, blade or server—running under any OS.
Many functions in telephony networks require access to storage. These requirements are typically codified in industry standards such as the IP Multimedia Subsystem of next-generation core telephony networks: 3GPP IP Multimedia Subnetwork (IMS) (Figure 2). Here, user devices access pre-stored multimedia data, including on-demand audio and video streams. Network elements, such as the media resource function (MRF) and media gateway (MGW), must access large amounts of storage to feed media streams to client devices, source media streams for re-encoding and delivery, process audio streams for voice recognition or pattern matching and evaluate subscriber profiles or record session statistics. iSCSI provides a highly scalable, cost-effective interface between these network elements and virtual disks that contain media data, legacy subscriber data or accounting information.
As a cost-effective enabling technology, an iSCSI initiator embedded in the OS of mobile devices provides interesting possibilities for distributed system architectures.
Military and distributed signal intelligence applications typically involve read/write access to massive quantities of data, including multi-spectral imagery, elevation profiles, template data for target recognition or other application-specific files for pre- or post-processing. In these cases, iSCSI simplifies system administration for client devices since the location, description and capabilities of the virtualized disk are centralized and completely hidden from the local configuration on the distributed endpoints.
The session management inherent in the iSCSI protocol and network transports provides a wide variety of fault-tolerant mechanisms for mission-critical applications. These characteristics make iSCSI a good match for environments where network topology changes rapidly—such as mobile, peer-to-peer or mesh networks—or for environments where large amounts of data must be centrally stored but accessed by distributed clients with limited local facilities.
iSCSI can be used here for high-resolution video monitoring for building security and remote, unattended cameras used for automobile traffic management. It may also be useful as a replacement storage technology for the analog videocassette-based dashboard cameras often used in law enforcement or for portable personal entertainment and gaming systems.
Incorporating legacy storage devices into an iSCSI paradigm is a matter of front-ending the legacy systems with an iSCSI target or target portal. This architecture can be used to simplify and virtualize heterogeneous storage devices into a single manageable, scalable and distributed disk farm with centralized, network-based control.
A number of enterprise-class SAN routers are already available with an iSCSI upstream interface layered over multiple 1 Gbyte Ethernet links. On their downstream sides, these gateway devices use FC, SCSI, SAS, SATA or other DAS interfaces.
Deployments that don’t require internetworking with legacy storage systems can already take advantage of embedded iSCSI target implementations in array controllers. It is only a matter of time before generic target implementations appear in embeddable board-level subsystems as well as silicon systems-on-chip.
Deployment Considerations
When direct dependence on IP-based networking is involved, the usual issues related to network architecture, security and availability must be considered, not only in the machine-to-machine communication model but also in the highly distributed nature of the initiator/target architecture.
One of the primary arguments against storage-over-IP architectures is that general-purpose networks and computers cannot properly handle the unique needs of storage traffic. The non-deterministic end-to-end behavior of IP networks and TCP/IP stacks can create serious problems when introduced into communication channels that need deterministic performance.
This results in a strong need for implementing complete iSCSI stacks via embedded system paradigms. Dedicated, single-focus, storage-specific implementations based on iSCSI will relieve the performance limitations inherent in multi-user systems with overworked network interfaces.
Although scalability through distribution is the primary strength of IP-based network architectures, this benefit often comes at the expense of throughput and latency. Transporting storage traffic over IP networks requires some network engineering to accommodate application-specific latency and throughput requirements. Fortunately, several technologies at the link layer and above can be effective in guaranteeing certain types of service for iSCSI traffic. In some cases, physical segregation may be required, such as is anticipated by the multiple physical links of an ATCA Fabric Channel via PICMG 3.1, option 3.
In either the local area or wide area case, the use of a parallel, physically segregated network path always results in better performance due to the higher expense of duplicated facilities. However, in either case the use of iSCSI as the storage transport protocol provides flexibility, which is not available via conventional SAN or DAS paradigms.
With DAS and SAN architectures, traffic between hosts and storage devices is not typically at risk from external entities. With iSCSI storage, however, the intervening IP network becomes a significant security concern, since it may be accessible by potentially malicious users.
A primary issue concerning iSCSI sessions and endpoints is weaknesses in authentication approaches. Many iSCSI implementations allow for deployment without any form of security measures. Although native iSCSI security mechanisms may prevent some forms of unauthorized activity, they provide no significant protection for ongoing validation of session integrity.
Consequently, two options exist for the secure transport of iSCSI session interactions: physical isolation of the storage subnetworks, or transporting iSCSI packets via encrypted tunnels. The first involves redundant, application-specific networks, which negates much of a converged network infrastructure’s value. For encrypting storage traffic, the most likely candidate is the IP security framework (IPsec).
Availability of network endpoints is based on two primary concepts: the ability to detect when a command or other data has not been accurately delivered and the sequence of steps taken in reaction to a detected failure.
Detection of failed communication is typically straightforward, particularly for packet-based networks. Approaches to detection tend to be limited to well-defined classes based on channel characteristics and related to such factors as acknowledgments, timeouts and data-corruption mechanisms.
iSCSI differentiates error recovery tasks between initiator and target. The initiator maintains enough outstanding history so that it can re-issue garbled commands or re-transmit lost data. The target maintains history for unacknowledged data and status responses.
In general, the distinction between iSCSI error recovery levels (ERLs) (Figure 3) is based on how much effort is expended to shield the native SCSI command set from awareness of network errors. The most basic case, ERL0, simply aborts all iSCSI activity at the first sign of a network error and leverages existing SCSI-level error recovery mechanisms. Higher error recovery levels, ERL1 and ERL2, attempt to respond to network-related errors using application-specific per-packet checksum and timeout mechanisms. In the most complex case, ERL2, which is supported by SBE’s iSCSI software (Figure 4), alternate TCP sessions are used to “silently” reconstruct command context within an existing session.
In high-availability systems or scenarios where latency is critical, it is especially important to make the same content or function available via more than one access path, which is achievable via multipathing. iSCSI multipathing can be particularly useful for deployment environments where network connectivity between client and server is not always guaranteed or does not have deterministic latencies, such as wireless. When used in conjunction with ERL facilities, multipathed iSCSI deployments can achieve very high reliability.
Evaluating iSCSI Performance
Storage is such a fundamental requirement that it appears in a wide variety of forms in different system architectures. To characterize system performance, SBE conducted benchmarks of an iSCSI storage system in two different contexts: a stand-alone enterprise-class storage appliance and an embedded, ruggedized storage gateway.
In these tests, the 1 GHz PowerPC CPU of the embedded target device and the 2.2 GHz Intel-based CPU of the enterprise-class system achieved greater than 73 Mbytes/s of throughput per GHz of CPU. This normalized performance was consistent regardless of the number of disks in use, the nature of the operations, such as READ and WRITE, or the type of disk technology, such as SAS and SATA.
Depending on system characteristics, hardware acceleration of both iSCSI and TCP may improve performance by more than 20%. These normalized measurements describe consistent, robust iSCSI system performance regardless of significant variations in system architecture.
The Attraction of iSCSI
The tradeoffs among simplified application architecture, flexibility of network connections and benefits of virtually local storage make iSCSI an attractive technology for high-reliability embedded systems. Traditional storage architectures have required physically separate, application-specific subnetworks for storage devices. These are characterized by strict distance limitations and high cost, including the costs of specialized management technologies and specialized interfaces for client devices.
In contrast, iSCSI utilizes an industry-standard, off-the-shelf network paradigm, IP-over-Ethernet, for both data and storage traffic. This IP network transport method can extend over arbitrary distances and network infrastructures, leveraging existing investments in management tools, technologies and strategies. Additionally, the simplified application architecture allows client devices with any type of network connectivity to address unlimited data via the virtual storage model.
SBE
San Ramon, CA.
(925) 355-2000.
[www.sbei.com].
SBE
San Ramon, CA.
(925) 355-2000.
[www.sbei.com].
0 comments:
Post a Comment