Backup is a resource-intensive application that places great demands upon storage devices, CPU, main memory, network capacity, internal buses and I/O buses. The enormous amount of resources required for backup is not always sufficiently taken into account during the planning of IT systems. A frequent comment is 'the backup is responsible for the slow network' or 'the slow network is responsible for the restore operation taking so long'. The truth is that the network is inadequately dimensioned for end user data traffic and backup data traffic. Often, data protection is the application that requires the most network capacity. Therefore, it is often sensible to view backup as the primary application for which the IT infrastructure in general and the network in particular must be dimensioned.
In every IT environment, most computers can be adequately protected by a network backup system. In almost every IT environment, however, there are computers – usually only a few – for which additional measures are necessary in order to back them up quickly enough or, if necessary, to restore them. In the server-centric IT architecture there are three approaches to taming such data monsters: the installation of a separate LAN for the network backup between backup client and backup server (Section 7.7.1), the installation of several backup servers (Section 7.7.2) and the installation of backup client and backup server on the same physical computer (Section 7.7.3).
7.7.1 Separate LAN for network backup
The simplest measure to increase backup performance more of heavy weight backup clients is to install a further LAN between backup client and backup server in addition to the existing LAN and to use this exclusively for backup (Figure 7.4). An expensive, but powerful, transmission technology such as ATM, FDDI or Gigabit Ethernet can also help here.
The concept of installing a further network for backup in addition to the existing LAN is comparable to the basic idea of storage networks. In contrast to storage networks, however, in this case only computers are connected together; direct access to all storage devices is not possible. All data thus continues to be passed via TCP/IP and through application server and backup server which leads to a blockage of the internal bus and the I/O buses.
Figure 7.4 Approach 1: the throughput of the network backup can be increased by the installation of a second LAN. Normal clients are still backed up via the User LAN (1). Only heavyweight clients are backed up via the second LAN (2)
Individual backup clients can thus benefit from the installation of a separate LAN for network backup. This approach is, however, not scalable at will: due to the heavy load on the backup server this cannot back up any further computers in addition to the backup of one individual heavyweight client.
Despite its limitations, the installation of a separate backup LAN is sufficient in many environments. With Fast-Ethernet you can still achieve a throughput of over 10 MByte/s. The LAN technique is made even more attractive by Gigabit Ethernet, 10Gigabit Ethernet and the above-mentioned TCP/IP offload engines that free up the server CPU significantly with regard to the TCP/IP data traffic.
7.7.2 Several backup servers
Installing multiple backup servers distributes the load of the backup server over more hardware. For example, it would be possible to assign every heavyweight backup client a special backup server installed exclusively for the backup of this client (Figure 7.5). Furthermore, a further backup server is required for the backup of all other backup clients. This approach is worthwhile in the event of performance bottlenecks in the metadata database or in combination with the first measure, the installation of a separate LAN between the heavyweight backup client and backup server.
The performance of the backup server can be significantly increased by the installation of multiple backup servers and a separate LAN for backup. However, from the point of view of the heavyweight backup client the problem remains that all data to be backed up must be passed from the hard disk into the main memory via the buses and from there must again be passed through the buses to the network card. This means that backup still heavily loads the application server. The resource requirement for backup could be in conflict with the resource requirement for the actual application.
Figure 7.5 Approach 2: dedicated backup servers can be installed for heavyweight backup clients. Normal clients continue to be backed up on the first backup server (1). Only the heavyweight client is backed up on its own backup server over the separate LAN (2)
A further problem is the realization of the storage hierarchy within the individual backup server since every backup server now requires its own tape library. Many small tape libraries are more expensive and less flexible than one large tape library. Therefore, it would actually be better to buy a large tape library that is used by all servers. In a server-centric IT architecture it is, however, only possible to connect multiple computers to the same tape library to a very limited degree.
7.7.3 Backup server and application server on the same physical computer
The third possible way of increasing performance is to install the backup server and application server on the same physical computer (Figure 7.6). This results in the backup client also having to run on this computer. Backup server and backup client communicate over Shared Memory (Unix), Named Pipe or TCP/IP Loopback (Windows) instead of via LAN. Shared Memory has an infinite bandwidth in comparison to the buses, which means that the communication between backup server and backup client is no longer the limiting factor.
Figure 7.6 Approach 3: application server, backup server and backup client are installed on one computer. Normal clients continue to be backed up on the first backup server (1). Only the heavyweight client is backed up within the same computer (2)
However, the internal buses continue to get clogged up: the backup client now loads the data to be backed up from the hard disk into the main memory via the buses. The backup server takes the data from the main memory and writes it, again via the buses, to the backup medium. The data is thus once again driven through the internal bus twice. Tape reclamation and any copying operations within the storage hierarchy of the backup server could place an additional load on the buses.
Without further information we cannot more precisely determine the change to the CPU load. Shared Memory communication (or Named Pipe or TCP/IP Loopback) dispenses with the CPU-intensive operation of the network card. On the other hand, a single computer must now bear the load of the application, the backup server and the backup client. This computer must incidentally possess sufficient main memory for all three applications.
One problem with this approach is the proximity of production data and copies on the backup server. SCSI permits a maximum cable length of 25 m. Since application and backup server run on the same physical computer, the copies are a maximum of 50 m away from the production data. In the event of a fire or comparable damage, this is disastrous. Therefore, either a SCSI extender should be used or the tapes taken from the tape library every day and placed in an off-site store. The latter goes against the requirement of largely automating data protection.
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.|