| This note is intended to aid in the analysis of NetWorker
performance and sizing for your customers. It is intended for
use by those who are already familiar with NetWorker. This note
complements the presentation available at
ftp://www.zso.dec.com/pub/networker/product_info/presentations/nsrperf.ppt
This note and the presentation include a lot of "rule of thumb"
information. Feel free to use it in your analysis of customer
situations, but:
DO NOT GIVE THIS TO CUSTOMERS!!!
This is the first release of these guidelines, so if you have
comments or corrections, please email me. This note and the
presentation are subject to change at any time, so if you need to
do any sizing, check for an up-to-date document.
Regards,
Wes Ono
========================================================================
NetWorker Performance and Sizing Guidelines
Wes Ono, NetWorker Engineering
Digital Equipment Corporation
19 February 1997
DIGITAL INTERNAL USE ONLY
This document is a text analog to the NetWorker Performance
PowerPoint presentation located at: ftp://www.zso.dec.com/pub/
networker/product_info/presentations/nsrperf.ppt
Disclaimers
-----------
The information in this document is intended for the use of those
familiar with the NetWorker product.
Much of the information in this document is based on anecdotal
experience with the NetWorker product, not on rigorous
performance and capacity measurement.
Introduction
------------
This document covers the following topics:
- Why is backup performance so important?
- The basic NetWorker architecture
- Past and present NetWorker Performance
- Factors that influence Networker performance
- Future NetWorker Performance
Why is performance so important?
--------------------------------
Customers continually ask for better backup performance for two
major reasons:
- They are accumulating more data to backup.
- They want shorter backup time to minimize downtime.
NetWorker Architecture
----------------------
The basic NetWorker backup datapath consists of a save process on
the client system that reads data and ships it to the server.
The media multiplexor on the server takes the incoming data and
writes it to tape. The save process sends updates to the file
index daemon and the media multiplexor sends updates to the media
database daemon.
disk -> save process
\
-> media multiplexor -> tape
/
disk -> save process
This client-server architecture is well-suited to distributed,
multiplatform backup.
The flexibility of the architecture can allow things to get
complicated. For example,
- A single client system may generate multiple save streams,
subject to the client parallelism setting.
- The server can accept multiple incoming streams, subject to
the server parallelism setting.
- A media multiplexor can take data from multi8ple incoming
streams and multiplex them onto a single tape, subject to the
sessions per device setting.
- Multiple media multiplexors can be active, each writing to a
tape. The number is set by the active devices setting.
Raising the various settings can increase backup throughput, but
only to a point. If they are set too high, then client or server
can be overwhelmed. In addition, backing up lots of little files
can cause a bottleneck on the index daemon and its databases.
The Past (V3.2A)
----------------
In NetWorker V3.2A, backing up data involved the following
transfers:
1) Read data from disk into a buffer in the save process
2) Send the data via rpc to the agent daemon (two data copies)
3) Send the data via rpc to the media multiplexor (two copies)
4) Write it to tape.
The four data copies consume a lot of CPU, especially for local
system backup. In addition, multiple agent daemons consume a
lot of memory.
Oracle backup with DMO V1.0
---------------------------
Using DMO V1.0 to backup Oracle databases makes the V3.2A
situation worse by requiring the agent daemon and by adding an
additional DMO-specific process to the data path. This results
in two more data copies. All of the copying is the reason that
NetWorker V3.2A and DMO V1.0 delivered a maximum of 36 GB/hour
on a TurboLaser in early 1996.
The Present (V4.2x)
-------------------
With NetWorker V4.2x, the situation improved a bit. The agent
daemon is removed from the backup data path, resulting in:
1) Read data from disk into a buffer in the save process
2) Send the data via rpc to the media multiplexor (two copies)
3) Write it to tape.
Eliminating two data copies and the agent daemon saves CPU and
memory.
While detailed measurements have not been made, NetWorker V4.2x
may deliver 50-80 GB/hour, given sufficient system resources.
Factors that affect NetWorker performance
-----------------------------------------
Because of the distributed, multiprocess, client-server nature of
NetWorker, its performance is highly dependent on a wide variety
of factors. These include:
- CPU - for data movement and interprocess communication
- memory - for data buffers and processes
- Disk - both for backup source data and for index updates
- Tape - the data has to go somewhere
- I/O adapters - for data transfer to and from the devices
- Network - the most important factor for distributed backup
- Clients - if the clients are slow, they can't deliver the data
- Data type - lots of little files beat up the file index
The following sections cover each of these in more detail, and
give guidelines for performance and sizing.
CPU
---
NetWorker consumes CPU for:
Data movement - NetWorker moves data from place to place. As
described in a previous section, the number of data copies done
by older versions of NetWorker generate a heavy CPU load. More
recent versions reduce the number of data copies, lessening the
CPU load. Future versions will improve this further.
Interprocess communication - NetWorker has multiple processes,
and consumes CPU for communication between them. In some
versions of Digital UNIX, a bottleneck can be reached on the IP
stack. This appears as a rapid increase in the amount of CPU
used in system mode with little or no increase in NetWorker
throughput.
Network overhead - network communications consumes CPU.
Rough guidelines for V4.2x - approximately 1/3 of a 5/300 CPU
for one TZ88 delivering about 10 GB/hour.
Memory
------
The short story is that too little will slow you down.
A real rough guideline:
- 64 MB, single tape, few clients
- 128 MB, 2-3 tapes, some clients
- 256 MB, more tapes, lots of clients
Disk
----
NetWorker needs disk performance and capacity for:
- Source of backup data
- Index file performance
- Index file capacity
Disk performance for backup source data is not usually an issue
unless you have a very slow disk or bus.
NetWorker maintains online indexes of files that have been
backed up and of media that have been used. This generates a
load on the index disk. This load has not been well quantified.
However, one test generated a file index with 10 million files.
This took about 1.5 days on a single CPU 2100 4/200 with a
non-striped RZ28 volume set.
Each time a file is backed up, an entry is placed in the file
indes. These entries accumulate until their "browse period"
expires and the index space is reclaimed. Each file entry
takes about 240 bytes (roughly 4K files per 1 MB of index).
You can use this for approximate sizing of the indexes.
Tape
----
Tape drives have two performance numbers that you need to know.
The first is the native write rate, which is fixed for any
particular drive. The second is the compressed write rate,
which can vary depending on the compressibility of the data
and the ability of the drive to absorb the data stream.
For example, the TZ87 native write rate is 1.25 MB/s. The 2:1
compressed write rate is about 2.5 MB/s. I believe the TZ87 is
limited to 2.5 MB/s regardless of how well the data compresses.
However, that's hardware and I'm not certain of the details.
These numbers assume you can feed data to the tape quickly
enough to keep the tape streaming. If it doesn't stream, then
tape performance drops significantly (to about 750 KB/s).
Using fewer fast drives is a win for NetWorker. There is less
interprocess communication to soak up CPU cycles. However,
this can result is less flexibility in allocating activity
across drives (e.g. multiple backups in parallel with recovers).
Compression - If you don't use NetWorker's client-side
compression, then NetWorker should be able to drive the tapes
up to their compressed write rate. We have seen TZ87 writing
at 2.5 MB/s. If you do use client-side compression (which
is good for reducing network utilization), you'll be limited to
the native write rate because the tape drive won't be able to
further compress the data.
I/O adapters
------------
The general rule of thumb is to put no more than two tape drives
per SCSI bus.
Network
-------
When you do network backup, network throughput is the most
frequent bottleneck.
Ethernet - Suitable for small data volumes. The theoretical
bandwidth is 1.25 MB/s. Practical throughput is usually in the
800 KB/s range if the network is otherwise idle.
FDDI - Theoretical bandwidth is 12.5 MB/s. Practical throughput
is 7-8 MB/s with no other traffic. Full duplex doesn't help
because backup is unidirectional.
Multiple adapters - NetWorker can distribute multiple backup
streams across multiple network adapters. NetWorker cannot split
a single backup stream (usually a single file system) across
multiple interfaces.
Data Type
---------
If you are backing up lots of little files, then the index file
gets updated very frequently. This stresses the index file disk
and adapter.
If you're backing up large files, then data throughput is the
limiting factor, sinc you're not updating the indexes very often.
Client Performance
------------------
A slow client (e.g. 386/25 PC) will backup slowly. It won't have
the capability to push data quickly. Multiple slow clients may
be OK, since NetWorker can handle multiple incoming streams in
parallel.
You can compress data on the client before sending it to the
server. This reduces network throughput requirements. It can
also reduce the CPU requirements on the server, since the server
moves fewer bytes. However, client-side compression can use a
significant amount of client CPU.
What you can expect
-------------------
Given the requirements for CPU, memory, disk, tape, I/O adapters,
network, clients, data type -- the best NetWorker can deliver is
the slowest of these.
Futures
-------
In 1996, several vendors tested backup on a 8 CPU, 8 GB
TurboLaser with 15 StorageTek Redwood SD-3 tape drives at the
Database Technology Center in Palo Alto. Three vendors cracked
the 500 GB/hour backup mark. Note that the tape drives alone
would cost nearly $2.5 million.
In a near-term future version of NetWorker for Digital UNIX, the
plan is to greatly improve the throughput of NetWorker for
*local* system backup. This comes primarily from the
incorporation of a shared memory transport for rpc. The datapath
for local backup works like this:
- Save reads data from disk into a shared memory rpc buffer
- The buffer is sent (by passing an address) to the media
multiplexor (zero copies).
- The media multiplexor write the data from the shared memory
buffer to the tape.
The elimination of buffer copies greatly reduces CPU overhead and
greatly increases throughput.
Shared memory and a beta of DMO V2.0 were combined during
database backup tests in November 1996. The number of buffer
copies were reduced from six (with DMO V1.0) to one.
By incorporating these improvements, NetWorker was able to
deliver 420 GB/hour on the Palo Alto system.
Remember, you won't see this level of performance for network
backup, or on a small system using DLT. However, this test is an
illustration of where NetWorker can take you if you have the
hardware resources.
|
| This note is intended to aid in the analysis of NetWorker
performance and sizing for your customers. It is intended for
use by those who are already familiar with NetWorker. This note
complements the presentation available at
ftp://www.zso.dec.com/pub/networker/product_info/presentations/nsrperf2.ppt
This note and the presentation include a lot of "rule of thumb"
information. Feel free to use it in your analysis of customer
situations, but:
DO NOT GIVE THIS TO CUSTOMERS!!!
This is the second release of these guidelines, so if you have
comments or corrections, please email me. This note and the
presentation are subject to change at any time, so if you need to
do any sizing, check for an up-to-date document.
Regards,
Wes Ono
[email protected]
========================================================================
NetWorker Performance and Sizing Guidelines
Wes Ono, NetWorker Engineering
Digital Equipment Corporation
Rev 2
15 May 1997
DIGITAL INTERNAL USE ONLY
This document is a text analog to the NetWorker Performance
PowerPoint presentation located at: ftp://www.zso.dec.com/pub/
networker/product_info/presentations/nsrperf2.ppt
Disclaimers
-----------
The information in this document is intended for the use of those
familiar with the NetWorker product.
Much of the information in this document is based on anecdotal
experience with the NetWorker product, not on rigorous
performance and capacity measurement.
Introduction
------------
This document covers the following topics:
- Why is backup performance so important?
- The basic NetWorker architecture
- Past and present NetWorker Performance
- Factors that influence Networker performance
- Future NetWorker Performance
Why is performance so important?
--------------------------------
Customers continually ask for better backup performance for two
major reasons:
- They are accumulating more data to backup.
- They want shorter backup time to minimize downtime.
NetWorker Architecture
----------------------
The basic NetWorker backup datapath consists of two major
processes. The first is a save process on the client that reads
data from disk and ships it to the server. The other is the
media multiplexor on the server which takes the incoming data and
writes it to tape.
NetWorker provides a high degree of backup parallelism for
performance. Multiple clients, each generating multiple backup
streams, can be backed up to multiple tape drives, each accepting
multiple backup streams.
NetWorker's primary interprocess communication is IP-based RPC.
This works very well in a distributed multiclient environment,
but has some shorcomings in a local backup environment.
NetWorker network backup
------------------------
For network backup (and for local backup on NT) the network
backup datapath works like this:
1) Read data from disk into a buffer in the save process
2) Send the data via rpc to the media multiplexor
3) Write it to tape.
Step 2 entails copying every buffer twice, once from the save
memory buffer into an IP buffer, then from the IP buffer into the
media multiplexor buffer. While this is required for network
backup, it causes unnecessary overhead for local system backup.
Local backup for NetWorker for Digital UNIX V4.3
------------------------------------------------
NetWorker for Digital UNIX V4.3 greatly improves the throughput
of NetWorker for local system backup. This comes primarily from
the incorporation of an "immediate save" feature which utiliizes
shared memory buffers for local backups. The datapath for local
backup works like this:
1) The save process reads data from disk into a shared memory
buffer.
2) A buffer pointer is passed to the media multiplexor.
3) The media multiplexor writes the data from the shared memory
buffer to tape.
This results in zero memory copies, greatly reducint the CPU
overhead and increasing the performance capability of the
NetWorker software.
Note that this is for local backup only. Network backup for V4.3
works as described on the previous slide.
Saving Oracle databases with V4.3 and DMO V2.1
----------------------------------------------
Digital's release fo the NetWorker Data Module for Oracle V2.1
(due in July 1997) incorporates the use of the immediate save
feature. Performance for hot backup is greatly improved,
delivering hundreds of GB per hour on systems with sufficient I/O
configuration and capacity.
DMO V2.0 (available now) adds compatibility with NetWorker V4.2x
for Digital UNIX, but does not include the immediate save
feature. Performance is still significantly improved over V1.0.
Factors that affect NetWorker performance
-----------------------------------------
Because of the distributed, multiprocess, client-server nature of
NetWorker, its performance is highly dependent on a wide variety
of factors. These include:
- CPU - for data movement and interprocess communication
- memory - for data buffers and processes
- Disk - both for backup source data and for index updates
- Tape - the data has to go somewhere
- I/O adapters - for data transfer to and from the devices
- Network - the most important factor for distributed backup
- Clients - if the clients are slow, they can't deliver the data
- Data type - lots of little files beat up the file index
The following sections cover each of these in more detail, and
give guidelines for performance and sizing.
CPU
---
NetWorker consumes CPU for:
Data movement - Doing buffer copies is the primary consumer of
CPU for NetWorker.
Interprocess communication - NetWorker has multiple processes,
and requires CPU for interprocess communciation.
Network overhead - network communications, especially for FDDI,
consumes CPU.
Rough guidelines for NT and network UNIX backup - approximately
1/3 of a 5/300 CPU 10 GB/hour.
Rough guideline for local UNIX backup usuing V4.3 - approximately
1/3 of a 5/300 CPU for 100 GB/hour. Yes, 100 - this is not a
typo.
Memory
------
The short story is that too little will slow you down.
A real rough guideline:
- 64 MB, single tape, few clients
- 128 MB, 2-3 tapes, some clients
- 256 MB, more tapes, lots of clients
Disk
----
NetWorker needs disk performance and capacity for:
- Source of backup data
- Index file performance
- Index file capacity
Disk performance for backup source data is not usually an issue
unless you have a very slow disk or bus.
NetWorker maintains online indexes of files that have been
backed up and of media that have been used. This generates a
load on the index disk. This load has not been well quantified.
Each time a file is backed up, an entry is placed in the file
indes. These entries accumulate until their "browse period"
expires and the index space is reclaimed. Each file entry
takes about 240 bytes (roughly 4K files per 1 MB of index).
You can use this for approximate sizing of the indexes.
Tape
----
Write rate - Tape drives have two performance numbers that you
need to know. The first is the native write rate, which is fixed
for any particular drive. The second is the compressed write
rate, which can vary depending on the compressibility of the data
and the ability of the drive to absorb the data stream.
For example, the TZ89 native write rate is 5 MB/sec. The
realistic write rate is about 4.5 MB/sec uncompressed and 8
MB/sec for 2:1 compressible data.
These numbers assume you can feed data to the tape quickly
enough to keep the tape streaming. If it doesn't stream, then
tape performance drops significantly (to about 750 KB/s).
Tape paralellism - Multiplexing - To help keep tapes streaming,
NetWorker can take multiple streams and multiplex them onto a
single tape drive.
Tape parallelism - Multiple active tapes - NetWorker will use
multiple tape drives simultaneiously. Multiple backup streams
can be spread among the drives, but any single stream goes to a
single drive.
Fast drives - Using fewer fast drives is a win for NetWorker.
There is less interprocess communication to soak up CPU cycles.
However, this can result is less flexibility in allocating
activity across drives (e.g. multiple backups in parallel with
recovers).
Compression - If you don't use NetWorker's client-side
compression, then NetWorker should be able to drive the tapes
up to their compressed write rate. If you do use client-side
compression (which is good for reducing network utilization),
you'll be limited to the native write rate because the tape drive
won't be able to further compress the data.
I/O adapters
------------
The general rule of thumb is to put no more than two tape drives
per SCSI bus.
Network
-------
When you do network backup, network throughput is the most
frequent bottleneck.
Ethernet - Suitable for small data volumes. The theoretical
bandwidth is 1.25 MB/s. Practical throughput is usually in the
800 KB/s range if the network is otherwise idle.
FDDI - Theoretical bandwidth is 12.5 MB/s. Practical throughput
is 7-8 MB/s with no other traffic. Full duplex doesn't help
because backup is unidirectional.
Multiple adapters - NetWorker can distribute multiple backup
streams across multiple network adapters. NetWorker cannot split
a single backup stream (usually a single file system) across
multiple interfaces.
Data Type
---------
If you are backing up lots of little files, then the index file
gets updated very frequently. This stresses the index file disk
and adapter.
If you're backing up large files, then data throughput is the
limiting factor, sinc you're not updating the indexes very often.
Client Performance
------------------
Client speed - A slow client (e.g. 386/25 PC) will backup slowly.
It won't have the capability to push data quickly. Multiple
slow clients may be OK, since NetWorker can handle multiple
incoming streams in parallel.
Client-side compression - You can compress data on the client
before sending it to the server. This reduces network throughput
requirements. It can also reduce the CPU requirements on the
server, since the server moves fewer bytes. However, client-side
compression can use a significant amount of client CPU.
Parallelism - NetWorker provides parallelism to help achieve
performance:
- A single client system may generate multiple save streams,
subject to the client parallelism setting.
- The server can accept multiple incoming streams, subject to
the server parallelism setting.
What you can expect
-------------------
Given the requirements for CPU, memory, disk, tape, I/O adapters,
network, clients, data type -- the best NetWorker can deliver is
the slowest of these.
|
| This note is intended to aid in the analysis of NetWorker
performance and sizing for your customers. It is intended for
use by those who are already familiar with NetWorker. This note
complements the presentation available at
ftp://ftp.zso.dec.com/pub/networker/product_info/presentations/nsrperf2.ppt
This note and the presentation include a lot of "rule of thumb"
information. Feel free to use it in your analysis of customer
situations, but:
DO NOT GIVE THIS TO CUSTOMERS!!!
This is the second release of these guidelines, so if you have
comments or corrections, please email me. This note and the
presentation are subject to change at any time, so if you need to
do any sizing, check for an up-to-date document.
Regards,
Wes Ono
[email protected]
========================================================================
NetWorker Performance and Sizing Guidelines
Wes Ono, NetWorker Engineering
Digital Equipment Corporation
Rev 2A
23 May 1997
DIGITAL INTERNAL USE ONLY
This document is a text analog to the NetWorker Performance
PowerPoint presentation located at: ftp://www.zso.dec.com/pub/
networker/product_info/presentations/nsrperf2.ppt
Disclaimers
-----------
The information in this document is intended for the use of those
familiar with the NetWorker product.
Much of the information in this document is based on anecdotal
experience with the NetWorker product, not on rigorous
performance and capacity measurement.
Introduction
------------
This document covers the following topics:
- Why is backup performance so important?
- The basic NetWorker architecture
- Past and present NetWorker Performance
- Factors that influence Networker performance
- Future NetWorker Performance
Why is performance so important?
--------------------------------
Customers continually ask for better backup performance for two
major reasons:
- They are accumulating more data to backup.
- They want shorter backup time to minimize downtime.
NetWorker Architecture
----------------------
The basic NetWorker backup datapath consists of two major
processes. The first is a save process on the client that reads
data from disk and ships it to the server. The other is the
media multiplexor on the server which takes the incoming data and
writes it to tape.
NetWorker provides a high degree of backup parallelism for
performance. Multiple clients, each generating multiple backup
streams, can be backed up to multiple tape drives, each accepting
multiple backup streams.
NetWorker's primary interprocess communication is IP-based RPC.
This works very well in a distributed multiclient environment,
but has some shortcomings in a local backup environment.
NetWorker network backup
------------------------
For network backup (and for local backup on NT) the network
backup datapath works like this:
1) Read data from disk into a buffer in the save process
2) Send the data via rpc to the media multiplexor
3) Write it to tape.
Step 2 entails copying every buffer twice, once from the save
memory buffer into an IP buffer, then from the IP buffer into the
media multiplexor buffer. While this is required for network
backup, it causes unnecessary overhead for local system backup.
Local backup for NetWorker for Digital UNIX V4.3
------------------------------------------------
NetWorker for Digital UNIX V4.3 greatly improves the throughput
of NetWorker for local system backup. This comes primarily from
the incorporation of an "immediate save" feature which utilizes
shared memory buffers for local backups. The datapath for local
backup works like this:
1) The save process reads data from disk into a shared memory
buffer.
2) A buffer pointer is passed to the media multiplexor.
3) The media multiplexor writes the data from the shared memory
buffer to tape.
This results in zero memory copies, greatly reducing the CPU
overhead and increasing the performance capability of the
NetWorker software.
Note that this is for local backup only. Network backup for V4.3
works as described on the previous slide.
Saving Oracle databases with V4.3 and DMO V2.1
----------------------------------------------
Digital's release of the NetWorker Data Module for Oracle V2.1
(due in July 1997) incorporates the use of the immediate save
feature. Performance for hot backup is greatly improved,
delivering hundreds of GB per hour on systems with sufficient I/O
configuration and capacity.
DMO V2.0 (available now) adds compatibility with NetWorker V4.2x
for Digital UNIX, but does not include the immediate save
feature. Performance is still significantly improved over V1.0.
Factors that affect NetWorker performance
-----------------------------------------
Because of the distributed, multiprocess, client-server nature of
NetWorker, its performance is highly dependent on a wide variety
of factors. These include:
- CPU - for data movement and interprocess communication
- memory - for data buffers and processes
- Disk - both for backup source data and for index updates
- Tape - the data has to go somewhere
- I/O adapters - for data transfer to and from the devices
- Network - the most important factor for distributed backup
- Clients - if the clients are slow, they can't deliver the data
- Data type - lots of little files beat up the file index
The following sections cover each of these in more detail, and
give guidelines for performance and sizing.
CPU
---
NetWorker consumes CPU for:
Data movement - Doing buffer copies is the primary consumer of
CPU for NetWorker.
Interprocess communication - NetWorker has multiple processes,
and requires CPU for interprocess communication.
Network overhead - network communications, especially for FDDI,
consumes CPU.
Rough guidelines for NT and network UNIX backup - approximately
1/2 of a 5/300 CPU 25 GB/hour.
Rough guideline for local UNIX backup using V4.3 - approximately
1/2 of a 5/350 CPU for 100 GB/hour.
Memory
------
The short story is that too little will slow you down.
A real rough guideline:
- 64 MB, single tape, few clients
- 128 MB, 2-3 tapes, some clients
- 256 MB, more tapes, lots of clients
Disk
----
NetWorker needs disk performance and capacity for:
- Source of backup data
- Index file performance
- Index file capacity
Disk performance for backup source data is not usually an issue
unless you have a very slow disk or bus.
NetWorker maintains online indexes of files that have been
backed up and of media that have been used. This generates a
load on the index disk. This load has not been well quantified.
Each time a file is backed up, an entry is placed in the file
index. These entries accumulate until their "browse period"
expires and the index space is reclaimed. Each file entry
takes about 240 bytes (roughly 4K files per 1 MB of index).
You can use this for approximate sizing of the indexes.
Tape
----
Write rate - Tape drives have two performance numbers that you
need to know. The first is the native write rate, which is fixed
for any particular drive. The second is the compressed write
rate, which can vary depending on the compressibility of the data
and the ability of the drive to absorb the data stream.
For example, the TZ89 native write rate is 5 MB/sec. The
realistic write rate is about 4.5 MB/sec uncompressed and 8
MB/sec for 2:1 compressible data.
These numbers assume you can feed data to the tape quickly
enough to keep the tape streaming. If it doesn't stream, then
tape performance drops significantly (to about 750 KB/s).
Tape paralellism - Multiplexing - To help keep tapes streaming,
NetWorker can take multiple streams and multiplex them onto a
single tape drive.
Tape parallelism - Multiple active tapes - NetWorker will use
multiple tape drives simultaneously. Multiple backup streams
can be spread among the drives, but any single stream goes to a
single drive.
Fast drives - Using fewer fast drives is a win for NetWorker.
There is less interprocess communication to soak up CPU cycles.
However, this can result is less flexibility in allocating
activity across drives (e.g. multiple backups in parallel with
recovers).
Compression - If you don't use NetWorker's client-side
compression, then NetWorker should be able to drive the tapes
up to their compressed write rate. If you do use client-side
compression (which is good for reducing network utilization),
you'll be limited to the native write rate because the tape drive
won't be able to further compress the data.
I/O adapters
------------
The general rule of thumb is to put no more than two tape drives
per SCSI bus.
Network
-------
When you do network backup, network throughput is the most
frequent bottleneck.
Ethernet - Suitable for small data volumes. The theoretical
bandwidth is 1.25 MB/s. Practical throughput is usually in the
800 KB/s range if the network is otherwise idle.
FDDI - Theoretical bandwidth is 12.5 MB/s. Practical throughput
is 7-8 MB/s with no other traffic. Full duplex doesn't help
because backup is unidirectional.
Multiple adapters - NetWorker can distribute multiple backup
streams across multiple network adapters. NetWorker cannot split
a single backup stream (usually a single file system) across
multiple interfaces.
Data Type
---------
If you are backing up lots of little files, then the index file
gets updated very frequently. This stresses the index file disk
and adapter.
If you're backing up large files, then data throughput is the
limiting factor, since you're not updating the indexes very often.
Client Performance
------------------
Client speed - A slow client (e.g. 386/25 PC) will backup slowly.
It won't have the capability to push data quickly. Multiple
slow clients may be OK, since NetWorker can handle multiple
incoming streams in parallel.
Client-side compression - You can compress data on the client
before sending it to the server. This reduces network throughput
requirements. It can also reduce the CPU requirements on the
server, since the server moves fewer bytes. However, client-side
compression can use a significant amount of client CPU.
Parallelism - NetWorker provides parallelism to help achieve
performance:
- A single client system may generate multiple save streams,
subject to the client parallelism setting.
- The server can accept multiple incoming streams, subject to
the server parallelism setting.
What you can expect
-------------------
Given the requirements for CPU, memory, disk, tape, I/O adapters,
network, clients, data type -- the best NetWorker can deliver is
the slowest of these.
|