Appendix D: Disaster Recovery Planning Kit-From End to Beginning

---

Tuning is a topic that just about everyone wants to talk about, and tuning your backup and recovery application is no exception. Because backup and recovery touch so many areas of the system, and in fact, the enterprise, tuning becomes more difficult to define clearly. The backup servers need to be tuned for optimum I/O performance, as well as shared memory, message queues, and network performance. The clients need to be tuned to their network performance, plus they need to have good disk performance. With all the variables that must be considered, tuning becomes a large task that sometimes appears to be more an art than a science.

Generally, we leave the majority of the operating system tuning to the appropriate system administrators and the different operating system specialists. In this appendix, we discuss some of the tuning that can be done specifically for the application, using NetBackup, and some OS tuning that directly affects the application. We also list some tuning references that you can use. If you go to the VERITAS Software's support Web site, http://support.veritas.com, and select Knowledge Base Search, you can search for a specific phrase and limit it to a specific product. We searched for 'tuning' and the specific product 'NetBackup DataCenter.' We found several documents, but the two you really should concentrate on are 'NetBackup Performance Tuning Guide for UNIX Platforms' (http://seer.support .veritas.com/docs/240733.htm) and 'Tuning NetBackup on NT Systems for Optimal Performance' (http://seer.support.veritas.com/docs/248373.htm). These two documents contain a lot of the specific tuning steps for UNIX and Windows servers.

The key to tuning any of your backup servers is to understand what resources are being used and how they are being used. With a NetBackup media server, the primary function is to receive data from a client and move that data to tape. One of the first areas to tune is the size of the data buffers the application will be using as it moves the data to tape. You will generally get better performance if the application's write buffers more closely match the drive cache or are a function of the cache. After many tests, we have found that in most cases the best buffer size to use with NetBackup is 256 KB, or 262144. This value usually gives the best tape write performance.

There is another buffering parameter that controls how many of these write buffers the application is allowed to use. This is a little harder to quantify, but 8 or 16 seems to be a good starting number. If you do not manually set up these configuration files, the application uses default values. These values can change with the version of the application and also depend on the platform type (UNIX or Windows) and whether you are using multiplexing.

As mentioned, tuning is more art than science. The art portion of the equation comes when you want to establish the exact values for each of these configuration files. The values we mentioned are generally good, but depending on the configuration and type of data, you might want slightly different ones. The only way to determine the best settings is to test and measure, and then test and measure again. Tables C.1 and C.2 list the default values for the common tuning parameters at NetBackup 4.5.

Table C.1: Default Values -SIZE_DATA_BUFFERS

	MULTIPLEXED	NONMULTIPLEXED
UNIX	64K	32K
Windows	64K	64K

Table C.2: Default Values-NUMBER_DATA_BUFFERS

	MULTIPLEXED	NON-MULTIPLEXED
UNIX	4	8
Windows	8	16

The NetBackup master server is mostly dependent on system resources, so tuning is not as much an issue as just making sure enough resources are configured. The resources that can give a master server problems are message queues, semaphores, and shared memory. The NetBackup Release Notes give minimum values for these resources. In addition, documents on the support Web site are available that discuss minimum settings for all the most commonly configured operating system resource parameters. Table C.3 shows an example of the minimum values for Solaris.

*

set maxusers=32

*

set shmsys:shminfo_shmmin=1

set shmsys:shminfo_shmmni=220

set shmsys:shminfo_shmseg=100

set shmsys:shminfo_shmmax=8388608

*

set semsys:seminfo_semume=64

set semsys:seminfo_semmap=64

set semsys:seminfo_semopm=32

set semsys:seminfo_semmni=1024

set semsys:seminfo_semmns=1024

set semsys:seminfo_semmnu=1024

set semsys:seminfo_semmsl=60

*

set msgsys:msginfo_msgmap=512

set msgsys:msginfo_msgmax=8192

set msgsys:msginfo_msgmnb=65536

set msgsys:msginfo_msgmni=256

set msgsys:msginfo_msgssz=8

set msgsys:msginfo_msgtql=512

set msgsys:msginfo_msgseg=8192

The tuning that we do for a client usually involves dealing with the way the client uses the network. There are settings on the client that will affect the buffer size used for network communications during backup. These are different for UNIX and Windows clients but are mentioned in the tuning documents cited earlier.

In addition, some operating system network parameters then sometimes are tuned. These are also mentioned in detail in the tuning documents. One of the most common things that can cause performance issues with network client backups is the duplex setting. To get the best performance, all networks should be set to FULL DUPLEX. Sometimes we see a mismatch where some settings are FULL DUPLEX and some are HALF DUPLEX, but the most common mistake is to set the duplex to AUTOMATIC. This very often results in a mismatch. Each OS has its own way to check the duplex setting. For example, on HP UNIX systems, you check this with the lanadmin command, whereas on Solaris, you use ndd.

---