InformationOnResourceAallocationWithinNetBackupSeptember2011.doc

7/31/2019 InformationOnResourceAallocationWithinNetBackupSeptember2011.doc

1/17

1 | P a g e

Information on resource allocation within NetBackup.

Scope:

This document will outline how resources are allocated within NetBackup and

configuration options that are available to change the behavior of the NetBackupResource Broker (nbrb). In-depth behavior of nbrb will be outlined, as it is the

primary process responsible for resource allocation. Other processes will be covered

only as they affect resource allocation.

This document will not cover troubleshooting techniques. That will be covered in a

different document.

The areas of the application that will be covered as follows:

For the purpose of this document, resource allocation will be defined as the

point in time a job appears queued in the activity monitor, until the point that a

job has started writing.

The behavior outlined will apply to NetBackup versions 6.5.2 and later

releases.

The focus will be on a scheduled backup job.

The differences between bptm parent and child will not be covered.

The portion of the functional overview covered, is as follows:


2/17

2 | P a g e

Definitions:

bpcd: The NetBackup client daemon. This listens for connections on all NetBackupservers and clients. In 6.x, the default behavior is that connections from themaster/media server(s) are made through vnetd. The vnetd daemon then makes aconnection to bpcd to initiate whatever action needs to be completed.

bpcompatd: NetBackup compatibility daemon. Used by nbjm to initiate calls tomedia servers.

bpbrm: NetBackup backup and restore manager. This runs on media servers whenbackups or restores are running. The nbjm process will connect with bpbrm, viabpcompatd to vnetd to bpcd, to spawn the bptm process during backup and restores.

The bpbrm process will send job manger (bpjobd) updates via nbjm. For mpxbackups, bpbrm is started in MPX mode. A backup is then added to this mpx groupby sending the START BACKUP message to bpbrm.

bptm: NetBackup tape manager. This runs on media servers and is typically initiatedby bpbrm. Some of the many things this process is responsible for are: writing datato disk or tape, initiating tape actions such as load/unload, reporting drive states to


3/17

3 | P a g e

nbrb and establishing a pipe with the client bpbkar process in order to pass data tothe media.

nbemm: NetBackup Enterprise Media Manager. Originator ID (OID) 111 This processwill run on the entity that is known as the emm server, typically this is the masterserver. This process has several subcomponents, such as mds (media and deviceselection component, OID 143) and da (the device allocator for shared drives, OID144).

nbrb: NetBackup Resource Broker. Originator ID (OID) 118. This process isresponsible for allocating disk and tape resources to jobs requiring them. It interactswith the nbemm components such as mds (the media selection component of emm),da (device allocator) ,fsm (Fiber Transport service manager) and dsm (disk servicemanager) frequently to query and update allocation status within the database.

nbjm: NetBackup Job Manager. Originator ID (OID) 117. This process is responsiblefor passing job updates to the jobs database (bpjobd) and passing resource requeststo nbrb and resource updates to bptm.

vnetd: This daemon listens for connections on all NetBackup servers and clients.

PBX: Private Branch Exchange. Originator ID (OID 103), product ID 50936. PBXlistens on port 1556. It is responsible for establishing connections on the master andmedia servers for certain functions.

Specific examples of when each of the above processes/daemons are utilized will beoutlined later in this document. Neither the examples above, nor the ones outlinedlater on in this document are a full list of scenarios, but will cover many of the stepsand actions required to allow resource allocation to occur.


4/17

4 | P a g e

Process flow explained:

When a job is scheduled by the NetBackup Policy Execution Manager, Originator ID(OID) 116, and it appears in the activity monitor, the job has reached a state where ithas been passed to nbjm. The nbjm process will then add the request to the nbrbinbound queue, for resource allocation fulfillment. The job may appear in the activitymonitor before or after the request is sent to nbrb, depending on timing of the receiptof the job. Job attribute updates are sent to bpjobd from nbjm every 10 seconds.

The job will remain in the inbound queue until nbrb breaks from the current allocationcycle. Breaks in the evaluation cycle can occur for several reasons:

The nbrb process has reviewed all allocations that are waiting. The nbrb.conf file parameter SECONDS_FOR_EVAL_LOOP_RELEASE time has

been met (the default is 180 seconds at 6.5.4 and later versions). If a high priority request [span request, subsequent requests of a dup job, and

requests with a pending condition] is received and the nbrb.conf parameterBREAK_EVAL_ON_DEMAND is set to 1 (enabled.)If nbrb is not currently in the middle of an evaluation cycle, an evaluation cycle willstart as soon as nbjm places the job in the inbound queue.

Once nbrb reads the request from the inbound queue, it is placed on the nbrb queueof requests that it is currently reviewing. The process will review specific resourcerequirements for the job. Resource allocations will be reviewed and an allocationassigned for each of the following:

A client allocation, after reviewing the maximum number of jobs allowed perclient.

A policy allocation, after reviewing the maximum of jobs allowed per policy.

One or more storage unit allocations (which include media and driveinformation) based on the request type.o First checks if it can join an existing MPX group. If it can, the request is

satisfied internally without going to MDS. Other checks may be made toMDS at this time outside of the allocation.

o If the request cannot join an existing MPX group, nbrb checks its cacheto see if it is worth sending the request to MDS. If nbrb's cache indicatesthat all the drives in the storage unit are in use, MDS is also going toreturn 'retry later'. Why to send it to MDS then?

o If, as per nbrb cache, it is okay to send the request to MDS, nbrb willsend the request to nbrb.

Each of the above are separate allocations and if a limit is exceeded or otherwise not

available (such as if all the drives are busy or down), the resource allocation will notsucceed and will be retried at a later time.

Once nbrb has successfully allocated resources for a backup job, the resourceallocations are passed to nbjm via the nbrb outbound queue.


5/17

5 | P a g e

The nbjm process reads the information from the nbrb outbound queue the job willappear as active in the activity monitor within a short period of time. The nbjmprocess will initiate a connection to the bpbrm process on the media server, typicallyvia vnetd to bpcd communication, and bpbrm in turn will initiate the bptm process.

When bptm is started, it initiates a connection to the nbjm process on the masterserver in order to get the media and drive information for the backup job. Thiscommunication is initiated through PBX, and an ORB connection will be establishedbetween the bptm and nbjm processes.

At the time that nbjm receives the request from bptm, it will add the media/driveinformation to the outbound Callback queue.*** Note: There is only one nbjm Callback queue used for this purpose, all resourcesrequests are passed to the media server bptm processes in a first-in-first-out order.

The activity monitor will now show the drive as mounting, positioning and eventuallywriting.

If the backup encounters an end of media (EOM) during the course of writing thebackup, bptm will notify nbjm via PBX, and will wait for additional resource and driveinformation to be allocated. The current drive resource will not be releasedcompletely until a new drive/media is allocated. This ensures that the if no otherdrives are available, the current backup job should be able to use the same drive.

At the end of a backup job, bptm will send an update to nbjm via PBX, that it isfinished writing. The media server bpbrm process will send a job end message tonbjm. The nbjm process will send an update to nbrb to free the resources and unloadthe drive

The unloading of drives will always take place at the end of an evaluation cycle. Therelease of resources will take place at the beginning of each cycle. The nbrb processwill update nbemm as drives become available, are unloaded, etc.

An in-depth look at the nbrb process

The nbrb, or NetBackup Resource Broker, is the daemon/service responsible forhandling resource requests for NetBackup.

The nbrb process runs through an evaluation cycle periodically to review requests,unload media, release resources, etc.

When the allocation cycle starts, nbrb sorts the list of jobs waiting for allocations, andlooks at each item in the list sequentially. It either:

Allocates the resources and crosses it off the list Or marks it for later evaluation.

The resource broker (nbrb) maintains a set of queues for the requests and allocations: A queue for requests it receives, referred to as the inbound queue. A queue for requests it is currently evaluating. A queue for requests processed that need to be transferred to the media

server, referred to as the outbound queue.


6/17

6 | P a g e

The process exposes a CORBA interface to nbjm and it uses nbemm's exposed CORBAinterfaces for the purposes of passing resource requests and updates.It may be helpful to note that nbjm is nbrbs client, and nbrb is emm(mds)s client.

It uses a timer to schedule tasks to include the start of an evaluation cycle, realreleases, bptm report drives process, etc. The default timers are as follows:

Every 300 seconds nbrb will wake up and look for entities that requireservicing, such as releases, new requests, etc. We haven't seen a need tochange this ever.

Every 10 minutes nbrb will initiate a bptm report drives process.o Reports the actual status of the drives. Failure can cause media servers

to be marked offline in emm.

For each evaluation cycle, nbrb completes the following, in this order: Read in the nbrb.conf file or configuration settings contained in the emm

database (depending on version).

Add new jobs from the inbound job queue. Release allocations: These are allocations that are already marked to be

released for jobs that have completed. Mark released drives as available. Build the drive/stu/stugrp cache (the evaluation loop timer is started here). Evaluate requests in prioritized areas:

o span requests and subsequent resource requests for duplication jobsalready active and requests that are allocated but have a pendingcondition associated with them.

these are known as high priority requestso Everything else.

User type backup jobs will be sorted to the top of the lists after

the high priority requests. Look for drives to unload [the drives that are released and are not used for

MEDIA_UNLOAD_DELAY seconds], start unloading drives.

Common items that impact the evaluation cycle:There are many variables that will impact the time it takes nbrb to allocate resourcesfor a specific job. The most common of those items, along with very basic detailsabout them are listed below:

Tuning parameters specific to nbrb.o This will be discussed in detail in the next topic.

Tuning parameters specific to emm.o There is only one write DB connection.

Tuning parameters implemented in emm.conf will not increasethe number of threads allowed to write

More read/update threads are not better in many circumstances.

High numbers of threads configured in emm.conf will nothelp performance of allocations and may hinder them aseach emm thread may consume 200 to 400 MB of memoryeach.


7/17

7 | P a g e

The storage unit group configuration may slow down the allocation cycle. Howmuch of an impact will depend on the algorithm used and the number ofstorage units within the group and their availability. In general:

o The more storage units in a group the longer the allocation will take.

It is not recommended to have more than 5 storage units within agroup.o The algorithm selected will also impact the time it takes to allocate

resources.* For more information on the algorithms available for storage units, , see the NetBackupAdministration Guide, for 6.5, volume 1, Chapter 5 Storage units, unit groups, and lifecycle policies.

Duplication jobs, such as vault, SLP and disk staging jobs will take longer toallocate due to the requirement of more than one physical resource.

Policy configuration variables that impact allocations:o The number of backups allowed per policy and cliento The number of copies.o The type of backupo Application backups such as oracle will spawn a dummy allocation prior

to starting the backup.o Schedules that have a variety of different mpx and retention level

settings.

This can cause drives to not be used at full capacity as one offbackups consume drive resources.

Poor disk i/o.o The nbrb process uses SQL database heavily for storing its state

(allocations, drive info, and other stuff). If the disk I/O is slow, theallocation cycle will slow down.

If logging levels are set to a high level, and there are many logsbeing generated, this may slow down the allocation cycle as theprocesses cache data to be written to the logs. In general the loglevel should be set to the default level which is 1. If the customeris facing any issue and symptoms show that this is because of RB,the debug log level should be set to 4. In some extreme cases,where we think that the problem could be because of slow SQLoperations, the debug level should be set to 5.

nbjm updates bpjobd via bpcompatd connection every 10seconds. The bpjobd process is single threaded; if bpjobdupdates are slow, job updates will not get populated to theactivity monitor in a timely manner and jobs may appear to be

queued, but actually have resources and be active. Hardware issues

o Library or drive issues cause problems with allocations.

If a robot is down or having sporadic communication issues,mounts/unmounts may take substantially longer or may have tobe retried many times before succeeding.

If a drive is unavailable, nbrb will need confirmation that thedrive has been unloaded prior to allowing it to be reallocated. Attimes this may take a substantial amount of time.


8/17

8 | P a g e

Media servers being marked offline.o Media servers can be marked offline for several reasons:

EMM does not get heartbeat from the media server (vmd/ltid).

bpstsupdate is spawned every 5 minutes to poll any disk drives.If this fails, disk allocations will not occur until a status is received.

Nbrb polls drives every 10 minutes from the media servers to getcurrent status. If nbrb doesnt receive a response or the report drivesfails, the media server will be marked offline.

Communication issues.o Corba transient errors can occur if media and master servers are unable

to communicate effectively. This can slow down unloads, updates and avariety of other issues.

Home grown scripts that are passing invalid parameters can cause load onthe system and emm database. This can cause delays if there are enoughemm update or queries being run.

Insufficient resources, such as available memory. Unneeded entries in bp.conf that will trigger host name lookups.

o CONNECT_OPTIONS

These are only for media server related connections. Clientsystems should not be listed. They should be configured in the

Master Server Host properties Client attributes tab and NOT

the Master Server Host properties Firewall tab. *o Invalid SERVER or MEDIA server entries.

Clients listed in the Master Server Host properties Client attributes tab

that are not resolvable.**For more information on the Client attributes and Firewall tabs in Master Server Hostproperties, see the NetBackup Administration Guide, for 6.5, volume 1, Chapter 7, HostProperties.

SQL DB, legacy catalogs and logs can get pretty big. It is highly recommendedto keep them on separate disk spindles. Often these files are kept on fancySAN disks enclosures. If that is the case, please make sure they are configuredproperly. To measure the performance, focus on both read and write to thedisks. We have seen at least two cases where these files were on a fancy SANdisk. The read operations were super fast but the writes were very slow.

A large emm transaction log (NBDB.log file). Sizes of the NBDB.log will varybased on the number of transactions that occur in the period since the last

backup. If the transaction log grows to large (too large is qualified as 1 to 2GBin size), allocations will slow down.If that occurs, one of two things must be done immediately to eliminate theproblem.

o A) A hot catalog backup which will truncate the transaction log.Unfortunately sometimes the allocations have slowed down so muchthat the catalog backup cant get resources. Then Item B MUST BECOMPLETED in order alleviate the issue.

o B) Use the /usr/openv/db/bin/dbadm (Unix) or ProgramFiles\Veritas\NetBackup\bin\NbDbAdmin.exe (Windows) tool to manuallytruncate the log.


9/17

9 | P a g e

Old files in /usr/openv/netbackup/db/media/drives (UNIX) / ProgramFiles\Veritas\NetBackup\db\media\drives (Windows) on the media servers.

These files contain information about the current drive status such as drivename, o/s path, pid, etc. If any information in those files matches anything inemm or nbrb the drive will not be allocated again. By default, these files arecleaned up when bptm exits. Files may be left in the directory if a poweroutage occurs or if administrators kill the bptm processes.

O/S or application bugs impacting the systems ability to process i/o functions. Insufficient O/S file descriptors. A minimum of 8000 is required.

Tuning parameters available in nbrbThere are many tuning parameters available that impact how the evaluation cycleruns. The full list is not provided in this document, only the nbrb.conf file (versions6.5.2 through 6.5.6, 7.0 and 7.0.1) and nbrbutil command options (version 7.1 andlater) will be addressed as this is the most frequently tuned.

The nbrb.conf file was introduced in the NetBackup version 6.5.2 release and isapplicable to every release of the software until the 7.1 release when the tuningparameters were moved into the emm database. At version 7.1, the nbrbutilcommand is used to manipulate the settings.

The nbrb.conf file in versions 6.5.2 through 6.5.6, 7.0 and 7.0.1:This file can be added to a master server in the following paths:

UNIX: /usr/openv/var/globalWindows: \Veritas\var\global

The file can contain the following variables:**The behavior changes somewhat at different patches and releases. See theexamples for additional details for each specific version.

SECONDS_FOR_EVAL_LOOP_RELEASEo If this value is set, nbrb will stop every N seconds specified by this conf.

RESPECT_REQUEST_PRIORITYo This parameter will control the behavior of how nbrb will break out of a

cycle. This is set to 1 (true) or 0 (false)

For 1/true, nbrb will consider jobs waiting in the inbound requestqueue.

For 0/false, nbrb will NOT consider jobs waiting in the inboundrequest queue.

o If RESPECT_REQUEST_PRIORITY is set to 1, or true, then nbrb will stop,perform cleanup and restart the evaluation cycle from the top of the list.

NOTE that the total time of the evaluation cycle will not includereleasing of resources and drives the evaluation cycle.

When nbrb breaks out of an evaluation cycle and start from thetop of the list, it does two things which may be an advantage:

New requests are picked up.

High priority jobs (in the normal queue), which are at thetop of the queue, gets a higher chance of running.

o In patch 6.5.5, we always evaluate high priorityqueue when we break.


10/17

10 | P a g e

If RESPECT_REQUEST_PRIORITY is set to 0, or false, nbrb will NOTadd more requests to the list during breakout.

The purpose of tuning theSECONDS_FOR_EVAL_LOOP_RELEASE and not enablingRESPECT_REQUEST_PRIORITY is to release the resources

for the completed jobs, rebuild the cache list of drivesavailable which may allow allocations to be serviced morerapidly.

o Additional considerations for RESPECT_REQUEST_PRIORITY

If set to 1, the time reported in msec should be close to the timespecified in the SECONDS_FOR_EVAL_LOOP until revision 6.5.5with nbrb EEB from ET 1924099 and 6.5.6. This is outlined inmore detail later.

If set to 0, the evaluation cycle will still be interrupted. But we willcontinue from where we left off. The msec reported in the logfiles will be the entire time it takes for nbrb to make it through thelist of jobs its currently reviewing.

If set to 0, and BREAK_EVAL_ON_DEMAND = 1 is set, the cycle willbe interrupted to satisfy the high priority requests for spanrequests and subsequent images of a duplication job.

If set to 1, and and BREAK_EVAL_ON_DEMAND = 1 is set, thecycle will be interrupted to satisfy the high priority requests forspan requests and subsequent images of a duplication job, AND

THE SECONDS_FOR_EVAL_LOOP timer will be reset withoutreviewing the jobs waiting in the inbound queue.

DO_INTERMITTENT_UNLOADSo This will impact whether or not nbrb will unload drives after the

SECONDS_FOR_EVAL_LOOP_RELEASE timer has been met. This is set to

1 (true) or 0 (false) 1/true, nbrb will initiate drive unloads as needed.

0/false, nbrb will not unload drives.

MAX_HIGH_PRIORITY_QUEUE_SIZE (NetBackup versions 6.5.4 with laterrevisions of ET1747025 and 6.5.5)

o Maximum number of HIGH priority request to consider (after this theyare treated as regular request). This is represented by an actualnumber.

o As stated previously, nbrb high priority requests are span requests andsubsequent images of a duplication jobs.

BREAK_EVAL_ON_DEMAND (NetBackup versions 6.5.4 with later revisions ofET1747025 and 6.5.5)

o Break the evaluation loop to when a new high priority request comes inor the timer expires. This is set to 1 (true) or 0 (false)

The nbrbutil options at version 7.1 and later.The nbrbutil command can be used to manipulate the configuration settings that arenow stored in the emm database.

The options that impact these settings are the following:


11/17

11 | P a g e

-changeSettings [,name=value] -- Add or change the NBRBconfiguration settings-deleteSetting -- Delete a NBRB configuration

setting-listSettings -- List the NBRB configuration

settings

To list the current configuration settings, the following command can be used:nbrbutil listSettings

The output will vary depending on the current configuration. If no options have beenset, and the default options used, no output will be returned.

To add or change a setting, the changeSetting flag will need to be used. The nameparameters that replace the nbrb.conf file settings are as follows:

nbrbutil changeSetting name nbrb.conf file settingRB_RELEASE_PERIOD SECONDS_FOR_EVAL_LOOP_RELEASERB_RESPECT_REQUEST_PRIORITY RESPECT_REQUEST_PRIORITYRB_DO_INTERMITTENT_UNLOADS DO_INTERMITTENT_UNLOADSRB_MAX_HIGH_PRIORITY_QUEUE_SIZE MAX_HIGH_PRIORITY_QUEUE_SIZERB_BREAK_EVAL_ON_DEMAND BREAK_EVAL_ON_DEMAND

*** true and false should be used instead of 1 and 0 when running nbrbutil-changeSettings

Other tuning options for nbrb.

Additional options are available for tuning nbrb. The following items were addressedas bp.conf file parameters in earlier versions of NetBackup and are also available asflags that can be used with nbrbutil changeSettings.

These settings will not be covered in-depth in this document as they are not asfrequently utilized as the other options.

nbrbutil changeSetting name bp.conf file settingRB_ENABLE_OPTIMIZATION NBRB_ENABLE_OPTIMIZATIONRB_CLEANUP_OBSOLETE_DBINFO NBRB_CLEANUP_OBSOLETE_DBINFORB_MPX_GROUP_UNLOAD_DELAY NBRB_MPX_GROUP_UNLOAD_DELAY

RB_RETRY_DELAY_AFTER_EMM_ERR NBRB_RETRY_DELAY_AFTER_EMM_ERRRB_REEVAL_PENDING NBRB_REEVAL_PENDINGRB_REEVAL_PERIOD NBRB_REEVAL_PERIOD

Additional information on nbrbutil and options available with this command arelocated in the Symantec NetBackup Commands Reference Guide for UNIX, Windowsand Linux, Release 7.1


12/17

12 | P a g e

Examples of nbrb behavior with common configuration settings,at various versions of NetBackup:

The impact of the above parameters will vary depending upon the patch revision of

NetBackup. Major changes to the behavior are outlined below:

NetBackup version 6.5.2 (6.5.1 with EEBs): First availability of the nbrb.conf. If thefile was not present, nbrb would not break an evaluation cycle. Upon start of theevaluation cycle, nbrb builds the list of jobs that require allocations. Once this listwas generated, nbrb would sequentially read through the list of items requiringallocations until each item was reviewed without unloading drives or adding waiting

jobs.

NetBackup version 6.5.4: Introduced default parameters for nbrb without thepresence of nbrb.conf. Those defaults are:

SECONDS_FOR_EVAL_LOOP_RELEASE = 180

RESPECT_REQUEST_PRIORITY = 0

DO_INTERMITTENT_UNLOADS = 1


13/17

13 | P a g e

NetBackup version 6.5.4 with the latest nbrb cumulative binary from ET 1747025 and6.5.5: This version introduced the following settings and their defaults:

MAX_HIGH_PRIORITY_QUEUE_SIZE = 100 BREAK_EVAL_ON_DEMAND = 1The above would cause nbrb to break when a high priority request (span requestor subsequent image of a duplication job) would be received.


14/17

14 | P a g e


15/17

15 | P a g e

NetBackup version 6.5.5 with the nbrb binary (EEB3) from ET 1924099, 6.5.6 and allversions of 7.0 and 7.1:Note: The nbrbutil changeSettings flags and nbrb.conf parameters areinterchangeable. For this example the nbrb.conf file setting names are used.

At this version of NetBackup RESPECT_REQUEST_PRIORITY = 1 would no longertrigger an automatic restart of the evaluation cycle once theSECONDS_FOR_EVAL_LOOP was met or exceeded.

At these versions, nbrb is aware of job priority and will only break completely out ofthe evaluation cycle if the policy priority of jobs waiting in the inbound queue ishigher than the policy priority of the job nbrb is currently reviewing.

With RESPECT_REQUEST_PRIORITY is set to 1, when theSECONDS_FOR_EVAL_LOOP_RELEASE is met/exceeded:

If there is a job with a higher priority job waiting, nbrb will break and restart theevaluation cycle from the beginning to read in the new jobs.

If there are no jobs of a higher priority, then nbrb will unload drives, releaseresources, rebuild the mds cache and then start evaluating the jobs from thepoint in the list where it left off.

With RESPECT_REQUEST_PRIORITY is set to 0, when theSECONDS_FOR_EVAL_LOOP_RELEASE is met/exceeded:

Nbrb does not review waiting jobs. It unloades drives (IF DO_INTERMITTENT_UNLOADS = 1). Releases resources. Rebuilds the cache

Resumes reviewing jobs where it left off.

With BREAK_EVAL_ON_DEMAND = 1 This will trigger interrupts of the evaluation cycle for events. Those events are

limited to the arrival of a high priority request (NOT to be confused with a highpriority job) such as a span request or a subsequent request of a duplication

job.o With RESPECT_REQUEST_PRIORITY = 0, when interrupted, nbrb will

evaluate the high priority request(s) and then proceed from where it leftoff () .

o With RESPECT_REQUEST_PRIORITY = 1, when interrupted, nbrb willcheck if there are any waiting requests with a priority higher than the

last evaluated. IF YES, nbrb starts at the beginning after it adds the newjobs. IF NO, then nbrb starts where it left off. It will cause the SECONDS_FOR_EVAL_LOOP timer to be reset.


16/17

16 | P a g e

Example 6.5.5 with EEB3, 6.5.6, 7.0, 7.0.1, 7.1 with Respect Request

priority = 1

Given the following configuration values:SECONDS_FOR_EVAL_LOOP_RELEASE = 180RESPECT_REQUEST_PRIORITY = 1DO_INTERMITTENT_UNLOADS = 1BREAK_EVAL_ON_DEMAND = 1MAX_HIGH_PRIORITY_QUEUE_SIZE = 100

v

NOTE: AT THESE VERSIONS nbrbseval cycle can be interrupted by anevent (the event being the arrival of ahigh priority request [span orsubsequent request of a duplicationjob]).

At this version of NetBackup, when nbrb starts anevaluation cycle the first steps are the same as inprevious versions. The behavior is the same UNTILEITHER a) a high priority request is received or b)

When the 180 second timer is met/exceeded, thenbrb process pauses, checks the inbound queue for

jobs with a higher priority than the one it is currentlyreviewing. If no jobs are present in the queue, nbrbcontinues where it left off after unloading drives,

Cycle is started and runs for 180 seconds,reviewing jobids 1 30.

No jobs of higher priority present, resumeevaluation at jobid 31.

High priority job is received (jobid 72). Thetimer is now reset. Jobid 72 is evaluated, then

nbrb will start where it left off prior to beinginterrupted.

High priority job is received (jobid 85). Thetimer is again reset. Jobid 85 is evaluated, nbrb

again starts where it left off.

180 second timer met/exceeded. There are jobsare waiting in the inbound queue, but they are

NOT a higher priority than the current job.NBRB does not read the jobs in.

End of list. Nbrb restarts the evaluation cycleincluding reading in waiting jobs.

Prior to the 180 second break, a high priority job isreceived, nbrb will break out of the current cycle,unload drives, release resources and rebuild themds cache prior to reviewing the high priority job.

Again, prior to the 180 second break, a high priorityjob is received, nbrb will break out of the currentcycle, unload drives, release resources and rebuildthe mds cache prior to reviewing the high priority

180 second timer met/exceeded, nbrb unloadsdrives, releases resources, checks the inboundqueue for jobs that are a higher priority than the jobit last reviewed. IF a higher priority job is waiting,nbrb will read the new jobs in; if not, it resumes

The nbrb process now reaches the end of the list.Finally new jobs waiting in the inbound queue areread into the list of items nbrb is evaluating.


17/17

17 | P a g e

References:TECH52801: Veritas NetBackup 6.5 Administrator's Guide for UNIX and Linux,Volume 1 http://www.symantec.com/docs/TECH52801

TECH52803: Veritas NetBackup 6.5 Administrator's Guide for Windows, Volume 1http://www.symantec.com/docs/TECH52803

TECH52859: Veritas NetBackup 6.5 Troubleshooting Guide for UNIX, Linux, andWindowshttp://www.symantec.com/docs/TECH 52829

DOC3684: Symantec NetBackup 7.1 Commands Reference Guidehttp://www.symantec.com/docs/DOC3684DOC3653: Symantec NetBackup Administrator's Guide for Windows, Volume 1http://www.symantec.com/docs/DOC3653

DOC4483: Symantec NetBackup 7.0 - 7.1 Backup Planning and Performance TuningGuidehttp://www.symantec.com/docs/DOC4483

TECH64845: Storage unit group considerations:http://www.symantec.com/docs/TECH64845

TECH164638: BUG REPORT: The nbrb allocation cycle doesn't break properly when

the evaluation loop timer is met, which causes delays in allocating resources.http://www.symantec.com/docs/TECH164638

TECH158713: Netbackup jobs queue even though sufficient resources are availablehttp://www.symantec.com/docs/TECH158713

HOWTO33588: About the Transaction Log Management menu optionshttp://www.symantec.com/docs/HOWTO33588

TECH168846: Insufficient system file descriptors can cause the EMM_DATA.db file togrow very large.http://www.symantec.com/docs/TECH168846
http://www.symantec.com/docs/TECH52801http://www.symantec.com/docs/TECH52803http://www.symantec.com/docs/TECH52829http://www.symantec.com/docs/DOC3684http://www.symantec.com/docs/DOC3653http://www.symantec.com/docs/DOC4483http://www.symantec.com/docs/TECH64845http://www.symantec.com/docs/TECH164638http://www.symantec.com/docs/TECH158713http://www.symantec.com/docs/HOWTO33588http://www.symantec.com/docs/TECH168846http://www.symantec.com/docs/TECH52801http://www.symantec.com/docs/TECH52803http://www.symantec.com/docs/TECH52829http://www.symantec.com/docs/DOC3684http://www.symantec.com/docs/DOC3653http://www.symantec.com/docs/DOC4483http://www.symantec.com/docs/TECH64845http://www.symantec.com/docs/TECH164638http://www.symantec.com/docs/TECH158713http://www.symantec.com/docs/HOWTO33588http://www.symantec.com/docs/TECH168846

Documents

InformationOnResourceAallocationWithinNetBackupSeptember2011.doc