At some point the technical boundaries for increasing the performance of backup are reached. When talking about technical boundaries, we should differentiate between application-specific boundaries (Section 7.6.1) and those that are determined by server-centric IT architecture (Section 7.6.2).
7.6.1 Application-specific performance bottlenecks
Application-specific performance bottlenecks are all those bottlenecks that can be traced back to the 'network backup' application. These performance bottlenecks play no role for other applications.
The main candidate for application-specific performance bottlenecks is the metadata
database. A great deal is demanded of this. Almost every action in the network backup
system is associated with one or more operations in the metadata database. If, for example, several versions of a file are backed up, an entry is made in the metadata database for each version. The backup of a file system with several hundreds of thousands of files can thus be associated with a whole range of database operations.
A further candidate for application-specific performance bottlenecks is the storage hierarchy: when copying the data from hard disk to tape the media manager has to load the data from the hard disk into the main memory via the I/O bus and the internal buses, only to forward it from there to the tape drive via the internal buses and I/O bus. This means that the buses can get clogged up during the copying of the data from hard disk to tape. The same applies to tape reclamation.
7.6.2 Performance bottlenecks due to server-centric IT architecture
In addition to these two application-specific performance bottlenecks, some problems
crop up in network backup that are typical of a server-centric IT architecture. Let us
mention once again as a reminder the fact that in a server-centric IT architecture storage
devices only exist in relation to servers; access to storage devices always takes place via
the computer to which the storage devices are connected. The performance bottlenecks
described in the following apply for all applications that are operated in a server-centric
IT architecture.
Let us assume that a backup client wants to back data up to the backup server
(Figure 7.3). The backup client loads the data to be backed up from the hard disk into
the main memory of the application server via the SCSI bus, the PCI bus and the system
bus, only to forward it from there to the network card via the system bus and the PCI
bus. On the backup server the data must once again be passed through the buses twice.
In backup, large quantities of data are generally backed up in one go. During backup,
therefore, the buses of the participating computers can become a bottleneck, particularly
if the application server also has to bear the I/O load of the application or the backup
server is supposed to support several simultaneous backup operations.
The network card transfers the data to the backup server via TCP/IP and Ethernet.
Previously the data exchange via TCP/IP was associated with a high CPU load. However,
the CPU load caused by TCP/IP data traffic can be disregarded with the increasing use of
TCP/IP offload engines (TOE) (Section 3.5.2 'TCP/IP and Ethernet as an I/O technology').
Figure 7.3 In network backup, all data to be backed up must be passed through both computers. Possible performance bottlenecks are: internal buses, CPU and the LAN
Use the following table of contents to navigate to chapter excerpts or click here to view Network Backup in its entirety.
| ABOUT THE BOOK: |
|
| Storage networks will become a basic technology like databases or local area networks. According to market research, 70% of external storage devices will be connected via storage networks in 2003. The authors have hands-on experience of network storage hardware and software, they teach customers about concrete network storage products, they understand the concepts behind storage networks, and show customers how storage networks address their business needs. This book explains how to use storage networks to fix malfunctioning business processes, covering the technologies as well as applications -- a hot topic that will become increasingly important in the coming years.Purchase the book from Wiley Publishing |
| ABOUT THE AUTHOR: |
|
| Authors Ulf Troppens and Rainer Erkens are both employed at IBM TotalStorage Interoperability Center in Mainz, Germany a testing, development and demonstration laboratory for storage products and storage networks. Both authors work at the interface between technology and customers. Wolfgang Müller is currently working as a software architect in the Storage Software Development Department at IBM in Mainz, Germany, where the focus is on software development projects supporting open standards such as SMI-S/CIM/WBEM and IEEE 1244. |
Home: 
