TIGER-SHARK Architecture
To date, most multimedia application programs run on stand-alone personal computers, with digitized video and audio coming from local hard disks and CD-ROMs. Increasingly, there has been a demand for file servers for multimedia data. The reasons for this include those that motivate the use of file servers for conventional data: sharing, security, and centralized administration.
It is difficult for a conventional file server to handle multimedia data. When a conventional file server becomes overloaded, all users experience lower throughput and greater response time. For multimedia, the file server must deliver digitized video and/or audio data at a rate that allows it to be presented to the user in a smooth, continuous stream (this is called continuous-time, or isochronous, presentation). Any nontrivial delay by the server results in stream starvation, which appears to the user as an annoying interruption in the presentation. Stream starvation can be avoided by buffering data and/or underloading the file server, but either of these alternatives can increase cost prohibitively. A video server differs from a conventional file server by incorporating an admission control mechanism to prevent overloading and a scheduling mechanism to ensure that data is supplied in a continuous manner.
In large-scale multimedia applications, like video on demand (VOD), interactive television (ITV)1, and browsers for the World Wide Web, the difficulty of providing continuous-time presentation is exacerbated by the sheer magnitude of the systems. A single video stream requires between 1.5 and 6 Mb/s of bandwidth.2 At the 6 Mb/s typically required for ITV, even the 100-stream servers that have been deployed in a number of small-scale ITV trials must support a throughput of 75 MB/s, yet most conventional network file servers are limited to well under 10 MB/s. A 1000-stream server, which is the minimum considered for production ITV systems, requires at least a 19-node SP23 system, with all nodes accessing the same video data simultaneously, making the need for scalability obvious.
The need for high availability and manageability in a large-scale VOD or ITV server is obvious as well. Failure of a 1000-stream ITV system presenting two-hour movies at $5 each costs $2500 an hour. Failure of a digital video-broadcast server can put a cable TV system, broadcast station, or broadcast network off the air..
Tiger Shark runs on a cluster of processors (file-system nodes) that share a pool of disks. File-system nodes can access the disks directly over a switching network or via other processors (storage nodes) to which the disks are physically attached. A single node can serve as both a file-system node and a storage node, but for simplicity, our discussion treats the two types of nodes as if they were distinct. Each file-system node can read from and write to all of the disks. A single RS/6000 processor can be considered to be a single-node cluster. In the SP2 system, Tiger Shark file-system nodes use a software component called Virtual Shared Disk (VSD) to send disk block-read and block-write requests to storage nodes over the high-speed switch.
Tiger Shark supports multiple, separately mountable file systems. In Tiger Shark, each mountable file system is striped across a collection of disks called a stripe group and can be accessed in parallel from all file-system nodes. Tiger Shark presents a single-system image to its clients–programs on separate file-system nodes see a globally consistent view of each mounted file system.
From Tiger Shark’s point of view, a video-server component that streams video to external users, such as an ATM stream driver or the Network File System daemon, is simply an application program running on file-system nodes. Other programs can run simultaneously and share data with video-server components. For example, a tape-archive manager running on one file-system node can begin retrieving a movie from a tape library and, slightly later, an ATM stream driver on another node can start streaming the movie to a viewer.
Tiger Shark makes files available through the AIX virtual file system [3] interface, which makes Tiger Shark compatible with the AIX native file system. Programs do not have to be modified to use Tiger Shark unless they make use of the functions that control its multimedia features.
RECENT COMMENTS