1 / 27

An Active Networking Testbed for Storage

People. Mel Tsai Anshi Liang Paul Huang Perry Dong and Tal Lavian. An Active Networking Testbed for Storage. Presenter Mel Tsai mtsai@eecs.berkeley.edu. Outline. Motivation The Testbed The Alteon-iSD Application Driver: Storage Networks Early Experiments with iSCSI

vidor
Download Presentation

An Active Networking Testbed for Storage

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. People Mel Tsai Anshi Liang Paul Huang Perry Dong and Tal Lavian An Active NetworkingTestbed for Storage Presenter Mel Tsai mtsai@eecs.berkeley.edu

  2. Outline • Motivation • The Testbed • The Alteon-iSD • Application Driver: Storage Networks • Early Experiments with iSCSI • Discussion & Results • Next Steps

  3. Motivation • Faster silicon enables increased processing and strong filtering in the network fabric • Emergence of high-speed programmable network processors • L5+ processing ability • Per-flow classification and routing • Traditionally, routers excel at L2-L3 classification and forwarding, servers must do L5-L7 computation • Neither can do both with high performance

  4. A New Platform L5-L7 Compute Processor(s) User Flows Servers Router++ L2-L7 classification, QoS, load balancing, & more…

  5. Platform Characteristics • A new approach towards network programmability • Programming model: separate forwarding and compute planes • High performance can be achieved when • Most packets take the fast path: # of packets sent to compute processor << total packet rate • Average latency of computation is low enough

  6. The Testbed • Goals • Develop a useful research platform based on this approach • Understand the performance, programming model, and versatility of this approach

  7. Enabling device: The Alteon-iSD A combination “router/server” • Alteon 184 Web Switch • 9-port load-balancing switch withL2-HTTP filtering • Integrated Services Director (iSD) • A dual-processor 1U PC withGbE interfaces Low-level control/data protocol: NAAP

  8. Testbed Setup • 8 PCs • 4 Alteon Web Switches • 2 iSDs • 2 Passport 8600 Routers • 10 Bay Networks L2/L3 switches • GbE connections between many points

  9. Basic Alteon-iSD Operation Server(s) Client(s)

  10. Basic Alteon-iSD Operation 1 Current filter 2: sip 10.0.0.1 255.255.255.255 dip 10.10.140.102 255.255.255.255 proto tcp vlan any action redir, group 1, rport 23 ack_or_reset disabled BW Contract 1024 Write TCP/IP or HTTP filters for redirection to iSD Server(s) Client(s)

  11. Basic Alteon-iSD Operation On the iSD, open control & data tunnels to the Alteon 2 Server(s) Client(s)

  12. Basic Alteon-iSD Operation 3 Begin forwarding matching packets to the iSD via a datagram tunnel Server(s) Client(s)

  13. Basic Alteon-iSD Operation Received packets are examined and possibly modified by software on the iSD 4 Server(s) Client(s)

  14. Basic Alteon-iSD Operation Packets are returned to Alteon. Status and table/filter updates are sent via a control tunnel. 5 Server(s) Client(s)

  15. Basic Alteon-iSD Operation 6 Alteon forwards packet to (possibly new) destination. Alteon’s configuration, filters, and routing tables are updated if instructed by the iSD. Server(s) Client(s)

  16. Application Driver • We want to evaluate the performance, versatility, and programming model of our testbed • Where are the performance bottlenecks? • What is the right programming model? • We have chosen storage networks as a new application driver • Recent convergence of storage networks with IP networks: iFCP, FCIP, iSCSI • New crop of intelligent “storage directors” with Alteon-iSD-like properties

  17. The Alteon-iSD as a Storage Building Block Large Storage Array or FC SAN (EMC, IBM, etc.) Clients Commodity storage devices (PCs, RAIDs, disks) Clients  versatile, low cost, IP-based, redundant, wide-area

  18. An IP Storage Protocol: iSCSI Ethernet IP TCP A standard point-to-point iSCSI session: iSCSI SCSI Cmd Data SCSI-over-TCP/IP connection iSCSI Initiator (“client”) iSCSI Target (“server”)

  19. An IP Storage Protocol: iSCSI A standard point-to-point iSCSI session: /dev/sdb iSCSI Initiator (“client”) iSCSI Target (“server”)

  20. Alteon-iSD Overhead (1) For a single point-to-point iSCSI session: MB/sec when copying a 650MB file No iSD involvement iSD intercepts pkts, no computation iSD intercepts pkts, recomputes IP cksum

  21. Alteon-iSD Overhead (2) For a single point-to-point iSCSI session: MB/sec when copying 10,000 small 18KB files No iSD involvement iSD intercepts pkts, no computation iSD intercepts pkts, recomputes IP cksum

  22. A Work in Progress:iSCSI Synchronous Mirroring 10.0.0.1: 3260 “The Alteon-iSD Storage Director” iSCSITargetDisk Objective: Synchronously and transparently mirror operations sent to the iSCSI Target on a backup iSCSI disk Backup Disk iSCSI Client 10.0.0.2: 3260

  23. Implementation on the Alteon-iSD • Alteon’s role: just a basic TCP/IP redirection filter • TCP dest port 3260 • IP addresses matching client or target • iSD’s role: inspects incoming packets, copies iSCSI requests to the backup disk, merges responses

  24. Testbed Discussion • Need access to Alteon firmware to perform useful filtering on iSCSI packets • The Alteon cannot do simple packet modification beyond simple TCP/IP header updates • Desirable to perform some computation in the fast path • Breaks the clean separation between forwarding vs. computation

  25. Testbed “Wish List” • Arbitrary L2-L7 pattern matching with fine-grained tagging • Fast-path L2-L7 packet modification • Hardware acceleration in both planes • FPGAs or some other hardware mechanism is required when simple operations must be performed on every packet • What is the right abstraction for the programmer?

  26. Some Next Steps • Understand the fundamental trade-offs when separating forwarding vs. computation • Understand where the system-level bottlenecks exist • Implement some more complex benchmarks • Striping, clustering and virtualization, disk-disk backup, asynchronous mirroring, FC-to-iSCSI gateway • Compare & contrast our testbed to existing storage directors

  27. Conclusion • This testbed is general enough to implement IP storage applications, but… • The Alteon-iSD was not designed for storage, and in some respects it shows • Need better filtering & packet modification • There is probably no “ideal” programming model for applications that benefit from L2-L7 filtering and increased computation in the network • Application-specific, high-level approaches may be the best

More Related