A Design and Implementation of a Virtual File Management System for a
Distributed Video Server
Nobuyuki ENOKI, Masaya MIYAZAKI,Hideyuki OKA and Masashi YAMAGUCHI
Matsushita Electric Industrial Co., Ltd.
1006, Kadoma, Kadoma-shi, Osaka, 571, Japan
Phone: +81-6-900-9651, Fax: +81-6-904-7169
E-mail:{enoki, miyazaki, oka, yamagu}@isl.mei.co.jp}
Abstract
This paper describes a Virtual File Management System for a distributed
video server. Our concept is to show distributed video data files in
several video servers as they are in a single video server. To realize
the concept, we propose the Virtual Network Tree mechanism. We also
propose the Access History Recording mechanism to give information for
relocating the distributed video data.
Keywords
distributed server, video server, Network
Filesystem(NFS), access history, UNIX, local area network(LAN)
1 Introduction
Rapid advances in computing, storage, and network technologies have
made possible a Video-on-demand system for delivering digital video data
through computer networks. The video server for this system has a large
number of disks for distributing many video streams to many clients
simultaneously. When the performance or the storage capacity of the
server becomes short as video data increases, an administrator may
replace the server with a higher performance one with a more storage
capacity. Another possible way is that he introduces another video
server on the same network and manages these servers as a distributed
video server system. In general, the distributed video server system
consists of several medium performance servers is more cost effective
than a single high performance server system. However, the distributed
video server system causes some difficulties for applications or users.
Users or application software should always know the physical location
of the video data that they would like to access. To solve the problem,
there are two approaches, (1)to adopt a physical location query system
of the video data[3], and (2)to adopt a virtual file management system
of distributed video data, which forwards access requests from clients
to real servers.
In this paper, we assume Sun's Network Filesystem (NFS)[1] based video
servers[2]. Their great advantage is that there is no need to change
existing video applications that use the file abstraction interface to
access video data on local disks. We propose to add a new mechanism to
this video server system, a Virtual File Management System (VFM). It
shows distributed video data stored in several NFS-based video servers
as it stored in a single virtual server. We describe how VFM manages
the distributed video data and allows users to access it without knowing
its physical location.
Figure 1 shows the distributed video server system that we
assume. It
consists of several NFS-based video servers and a server on which VFM is
running, a Virtual File Server (VFS). These servers and some clients are
connected by a LAN; the clients use the NFS protocol over the UDP/IP
protocol to retrieve video data from the servers and playback it.
Figure 1: The distributed video server system.
This system works as follows:
- A client sends a read request to VFS.
- VFM identifies the Video Server(VS) that stores the requested data.
- VFM forwards the read request to the VS.
- The VS directly sends the requested data to the client.
The remainder of this paper is structured as follows. We describe the
features of VFS in section 2. Section 3 presents the implementation of
VFM. In Section 4, we show the evaluation result. Section 5 concludes
the paper.
2 Virtual File Management System (VFM)
In this section, we describe the problems of NFS-based distributed video
server systems and propose the capabilities that will solve the
problems.
2.1 Virtual Network Tree
As we stated in the previous section, when video titles are stored in
several servers, users or applications should distinguish servers to
access the data using the NFS protocol. It is very inconvenient for
users. In addition, if an application depends on the server's name or
address, it will not work without modification after a new server is
introduced, or data is moved between servers.
We have designed the Virtual Network Tree service to solve the problem
above. Figure 2 illustrates an example of the Virtual Network Tree.
"ServerX" means a real video server, "fileX" means a file, and "dirX"
means a directory. In this case, users or applications on clients can
see the Virtual Network Tree in VFS although real data is stored in
"ServerA" and "ServerB". They only mount VFS and do not need to know
where the real data is stored. Even if "file2" in "ServerA" is moved to
"dirA" in "ServerB", the Virtual Network Tree will not change at all.
Figure 2: An example of the Virtual Network Tree.
Please note that the Virtual Network Tree is different from a network
directory service illustrated in Figure 3. In this case, the directory
tree in each server is shown as a sub-directory in the network
directory. Therefore, if "file2" in "ServerA" is moved to "dirA" in
"ServerB", the directory path in the network directory will change.
Figure 3: An example of the Network Tree.
2.2 Access History Recording
Another important issue is efficient video data distribution. For
instance, a distributed video server consists of servers with an equal
performance and storage capacity, works most efficiently when clients
access all the servers by the equal frequency. To realize this
condition, popular video titles are equally distributed to all the
servers. If many popular titles are stored in one of the servers, its
performance would be the performance bottleneck in the whole system.
Another approach for a cost-effective system is a hierarchical
distributed video system. In this approach, popular titles are stored in
high performance servers based on hard disks, and other titles are
stored in servers that do not have so high performance, but has a large
storage capacity, such as servers with optical jukeboxes.
For both the approaches, we should know the access frequency of each
video title. However, it is not easy to get it in the NFS-based video
server because clients do not send open/close or start/stop requests to
servers explicitly. We have designed an access history recording
mechanism by monitoring all NFS read requests to VFS.
3 Implementation}
In this section, we describe the implementation of VFM.
3.1 Software Structure
We have implemented the proposed VFM on a UNIX workstation. Figure 4
describes the software structure of VFM. VFM mainly consists of the
following three modules:
Figure 4: Software structure.
1. VFM Redirector
It sits between the network device driver and the IP protocol module,
and steals NFS read request packets and forwards them to video servers
that stores the requested data. It also manages the redirector cache
described below to realize the high speed packet forwarding and to
collect access history records.
2. VFM Daemon
It manages the Virtual Network Tree database. It holds the real location
of each files in the Virtual Network Tree, where the real data is
stored. It holds the access history record of each file as well.
3. Redirector Cache
It caches a part of the real location of files in the Virtual Network
Tree. The VFM Redirector forwards read requests to the video server
without communicating with the VFM daemon when it finds the real
location in the Redirector cache. It holds the first accessed time and
the latest accessed time to the file as well.
3.2 Detail of Virtual Network Tree
We explain how the modules above work to provide the Virtual Network Tree
service.
Before describing the implementation of the Virtual Network Tree
service, we explain a data read sequence by the NFS protocol. When a
client retrieves data from a NFS-based server, the client and the server
work as follows:
- A client requests a file location identifier, File Handle (FH), to
a server.
- The server returns the FH to the client.
- The client sends an NFS read request consists of the FH, an offset
from the beginning of the file and a data size to the server.
- The server sends the requested data to the client.
- The client and the server repeat the steps 3 and 4.
We make a new identifier, Virtual File Handle (VFH) to provide the
Virtual Network Tree service. A VFH is a location identifier in the
Virtual Network Tree, and is translated into a Real FH (RFH) in the real
NFS-based server by the VFM daemon. The clients can access files in the
Virtual Network Tree by the same way as they access to NFS-based servers
because VFH has the same structure as the structure of NFS FH. Users
need not change client applications at all.
A client retrieves video data as follows:
- A client requests a FH to VFS.
- VFS returns a VFH to the client.
- The client sends an NFS read request consists of the VFH, an offset
and a size to VFS.
- The VFM redirector steals the read request and passes it to the VFM
daemon.
- The VFM daemon find the IP address of the VS and the RFH
corresponding to the VFH, and return them to the VFM redirector.
- The VFM redirector replaces the VFH in the read request with the
RFH, then forwards it to the VS.
- The VS sends the requested data to the client directly.
The above implementation of VFM enables clients to retrieve video data
without knowing where the real data is stored. However, it is not fast
enough to playback video smoothly if the VFM redirector gets the
corresponding IP address and RFH from the VFM daemon every time it
forwards read request. We have solved this problem by introducing the
redirector cache.
Figure 5 illustrates the structure of the redirector cache entry. When a
client sends the first read request, the VFM redirector gets the IP
address and the RFH from the VFM daemon and store them in the cache
entry with the VFH. The client sends the second read request consists of
the same VFH, the incremented offset and a data size. This time, the VFM
redirector finds the IP address and RFH corresponding to the VFH in the
redirector cache and forward the read request immediately.
Figure 5: Redirector cache entry.
3.3 Detail of Access History Record
Another feature of VFM is the capability of recording the access history
of each file in the Virtual Network Tree. We have implemented it using
the redirector cache described above.
- When a client sends the first read request, the VFM redirector
stores the current time in the start time field and the last time
field in the cache entry.
- While the client is sending read requests, the VFM redirector
updates the last time field with the current time.
- When a certain amount of time, for example, 10 seconds, has past
after the client stop sending read requests, the VFM redirector
considers that the file has been closed. It reports the start time
and the last time in the cache entry to the VFM daemon, then clear
the entry.
- The VFM daemon records the times in the Virtual Network Tree
database.
Users can store video data efficiently by processing the access history
records.
4 Evaluation
This section reports the evaluation results. We have evaluated the VFM
overhead by the two points, (1) video delivery throughput and (2)
response time. In other words, (1) how many video streams VFM can
deliver without any breaks and (2) how long does it take a client
receives the first video data after sending the first read request.
We did the evaluation using the following two NFS-based video servers, a
VFS, a real client and a client simulator:
NFS-based video server 1
Hardware:SPARCstation20
Throughput:40 X 1.5[Mbps] video streams
NFS-based video server 2
Hardware:SPARC Ultra1
Throughput:50 X 1.5[Mbps] video streams
VFS
Hardware: PC(Pentium 200MHz, 32MB Memory)
Real Client
Hardware: UNIX WS(Panasonic P3100)
Function: check breaks in the video streams
Client simulator
Hardware: UNIX WS(SPARC Ultra2)
Function: retrieve specified number of video streams
We observed that there was no break in the video streams, and the CPU
load average was 32 percents when we made the client simulator retrieve
90 X 1.5[Mpbs] video streams stored in the two real servers via VFS. We
also made several tests as changing the number of video streams. As the
results of these tests, we observed that a CPU load average increases in
proportion to increase of the number of video streams, and there is no
other bottle neck in VFS. Therefore, we expect that the maximum
throughput of VFS is over 150 X 1.5[Mbps] video streams.
We measured two response times, (1) a response time when a client
retrieves video data via VFS, and (2) a response time when a client
directly retrieves video data from a video server. We observed that the
response time increase 0.6[sec] when we use VFS.
In this configuration, VFS causes no throughput decrease and seems to
handle more video streams. Users observe 0.6[sec] more delay when they
start video playback, but we do not think it causes a significant
problem in the man-machine interaction. Therefore, we consider that the
overhead of VFM is small enough to use.
5 Conclusion
We have proposed the new distributed server management mechanism, VFM
and have described its implementation. VFM allows users to access
distributed video data stored in several servers without knowing its
physical location. It also provides the access history record. Users
may also improve the total performance of their VOD system by storing
video data using it. We also proved the overhead of VFM is quite small
to use in real systems.
References
[1] R. Sandberg, D. Goldberg, S. Kleiman, D. Walsh, B. Lyon,
Design and Implementation of the Sun Network Filesystem. USENIX
Summer 1985 Conference Proceedings, pp.119-130, 1985.
[2] M. Nakanishi, H. Oka, T. Ohmura, A Multimedia Server Based on NFS
Protocol. ISDL 1995, pp.275-276, 1995.
[3] ISO/IEC DIS 13818-6, generic coding of moving pictures and
associated audio information -- Part 6: Extensions for DSM-CC.
