Before configuring DIVAnet services, see Chapter 2 for a description of the DIVAnet services and how they interact with DIVArchive and each other.
Configuring the ClientAdapter service involves configuring how clients connect to DIVAnet. It also involves configuring how DIVAnet connects to DIVArchive.
A DIVAnet site is defined to be one DIVArchive System, and one or more of the DIVAnet services (ManagerAdapter, ClientAdapter, DbSync). Each site is assigned a unique sitename. The site names must be configured in the DIVAnet Database (use either DIVAnetAdmin or the addSites utility) before configuring the ClientAdapter. You should create sitenames that are easy to read and reflect either the physical location, or the function of the site. These sitenames will be used on each site.
Note:
Sitenames are case sensitive.DIVAnet allows configuration of the socket ports that client API applications use to connect to DIVAnet. The ClientAdapter allows multiple API ports to be configured. Each API port is configured in one of two modes: Direct mode or MultiDiva mode. Each port can be assigned a Workflow Profile.
Direct Mode — In Direct mode, an incoming API connection is routed directly to an individual DIVArchive system with little added processing. The particular site that DIVAnet routes to is configured in the ClientAdapter on a per-port basis. This functionality allows local clients to connect to a remote DIVArchive system as if it were local. The DIVA site to route messages to must be configured in the DivaManagers section of the ClientAdapter configuration file. Note also that a site can be configured to operate in Direct Mode only (see Configuring the DIVArchive Sitename for more information).
Requests in Direct mode will not be displayed in DIVAnetUI, and can only be monitored at the DIVA site where the requests are being routed.
Some DIVAnet workflows do not require a DIVAnet database, DIVAnet UI, or MultiDiva mode processing. To configure a ClientAdapter service for Direct Mode only, insure that only Direct Mode ports are defined, and that a WebServicePort is not defined. This effectively disables use of the DIVAnet UI. An example configuration can be found in the file found here:
Program/conf/divanet/templates/ClientAdapterConfig.xml.ProxyOnly.ini
MultiDiva Mode — In MultiDiva mode, DIVAnet makes all DIVA sites appear to be one big archive system. In this mode, an incoming API request is routed directly to DIVAnet. DIVAnet satisfies the high-level request by consulting other DIVArchive systems as needed. This functionality allows (for example) copying of content from one site to another, restores without needing to know which particular site has the content, and retries on other sites when content on the first site is inaccessible. In addition, it provides a global view of content on all sites.
The progress of a request executed in MultiDiva mode can be monitored in the DIVAnetUI. DIVAnet will create its own request-level events that inform the user of:
How DIVAnet will process the request
Requests that are made of DIVA sites
Any errors or warnings encountered along the way
The DIVAnetUI application and the DIVAnetAdmin tool both make web connections to the ClientAdapter. You can configure the port that is made available for these connections in the ClientAdapter configuration file.
A Workflow Profile is a set of parameters that defines how incoming requests will be processed by DIVAnet. Workflow Profiles provide a way to logically group users and systems that use DIVAnet in a similar manner.
DIVAnet allows one or more profiles to be created within the ClientAdapter. These profiles contain parameters that are needed by a particular set of users, or set of applications. Workflow Profiles are assigned based on where the request was received (the port where it was received - see the following section).
In the Workflow Profile you can customize information such as the list of accepted valid messages, retry parameters, site-to-site copy methods, and other attributes.
In the API Ports section, each defined port can be assigned a Workflow Profile Name. Requests received on the API port are processed using the assigned Workflow Profile. If no name is defined, the profile default is assumed. Ports in MultiDiva mode can have Workflow Profile Names that refer to a Workflow Profile body section further down in the ClientAdapter configuration.
If the port is in Direct mode, the Workflow Profile Name is a label only - there is no Workflow Profile body for Direct mode connections. This name, however, can be useful in Access Rules (see the following section).
In both MultiDiva mode and Direct mode, if you do not assign a name, the connection uses a Workflow Profile named default. Each workflow profile body section is configured in the ClientAdapterConfig.xml. The following sections list the types of information configurable in each Workflow Profile.
Some commands within DIVAnet can be retried (for example, Restore, Copy, and Delete requests). The parameters for the retries, including how long to retry and the retry interval are configurable here. Many commands have their own retry settings (for example, the Copy command retry parameters are completely distinct from the Delete command retry parameters). Message timeouts and connection limits can also be configured in the Workflow Profile. The retry and timeout settings are specific to the Workflow Profile in which they are defined.
In each Workflow Profile, a list of messages is configured. This represents the list of valid API messages that can be accepted by this Workflow Profile. For example, if the Archive message does not appear in the list, then Archive messages cannot be sent to DIVAnet through the API (at least for this Workflow Profile).
DIVAnet provides a flexible way to configure how Site-to-Site transfers are performed. In each Workflow Profile, you configure mapping parameters for each transfer path (one path would be transfers from site A to site B, another would be from site A to site C, and so on). This table is consulted when Copy, Restore, or Partial File Restore commands are received.
It is useful to define the Site-To-Site mappings in the default Workflow Profile, as other Workflow Profiles can load their mappings from the default Workflow Profile. This can reduce the number of mappings in the configuration.
Parameters — DIVAnet supports several different transfer types. Site-to-Site Transfer Methods describes the different types. RestoreAndArchive is the default transfer type. RestoreAndMonitor requires Drop Folder Monitor (DFM), or another application that performs a similar function. Other parameters include:
Source/Destination — the common storage location for transfer (accessible at both the source and target sites).
Default Media — the default archive media to use when archiving on the target site. Default Media can be used when either a temporary copy was initiated (such as by a restore), or a user launched a copy and indicated that DIVAnet should select the media.
Options — the parameters to use in the restore, archive, and transfer requests.
FilePathRoot — the parent directory to store the content
Directory Location — DIVAnet constructs a directory path to store the files that is relative to the Source/Destination chosen. This relative path is constructed as follows:
{FilePathRoot} / {Media} / {UniqueDirName} /
The FilePathRoot is specified in the Site-To-Site mappings. Media will be embedded in the path only if the AppendMediaToPath option is set to true in the mappings (the default is false). Finally, DIVAnet generates a unique directory name that is included as part of the path. This unique name has the sitename that initiated the request prepended to it.
Parameters specified in the Workflow Profile can be changed and reloaded without restarting the ClientAdapter. Restarting the ClientAdapter service should be avoided, because it will stop all executing requests and close all client connections. The reload can be performed within the DIVAnetAdmin tool (Chapter 6, "DIVAnet Administration" for more information on DIVAnetAdmin).
Note:
The reload updates not only all of the Workflow Profiles, but also all of the Access Rules and AutoCopy configuration.The following tables describe the parameters that can appear in a ClientAdapter configuration file. The file is in XML format. The default value column indicates the value that the parameter will have if the parameter is not specified in the configuration file. The column also indicates whether the parameter is required or optional.
To create a new configuration file:
Navigate to the DIVAnet home directory (where DIVAnet is installed).
Navigate to the Program/conf/divanet/templates folder.
Copy the ClientAdapterConfig.xml.ini to the parent directory, but leave out the .ini extension (../ClientAdapterConfig.xml).
Using the tables below as a reference, edit the parameters in the ClientAdapterConfig.xml file to configure the ClientAdapter.
See Appendix A for a sample ClientAdapter configuration file.
Table 4-1 ClientAdapter Top Level Parameters
| Parameter | Description | Default Value |
|---|---|---|
|
|
The sitename of the Local DIVAnet site. |
None (required) |
|
|
The folder where the log files will be produced. |
The |
|
|
The detail level at which trace file logging takes place (ERROR, WARN, INFO, DEBUG, TRACE). |
INFO |
|
|
The number of seconds to wait for an object to synchronize. |
60 |
|
|
The number of worker threads in DIVAnet thread pools. Used for tuning large configurations. If you are unsure, do not set this value. |
25 |
|
|
Stop all incomplete DIVAnet requests when DIVAnet starts - even if the request has completed at the DIVArchive level. New requests are not affected. |
false |
|
|
The maximum total number of API connections allowed. |
200 |
|
|
The maximum number of pending or running DIVAnet requests that can be accepted into the system. When this limit is reached, DIVAnet will start rejecting new requests. |
5000 |
|
|
The base rate at which sites are polled for information. Change this parameter only if slow networks and (or) systems are encountered. |
4000 |
|
|
The port used to send management messages to the ClientAdapter. |
None (optional) |
|
|
True if SSL should be enforced for web service requests. |
true |
|
|
Workflow profile to be used for web requests (including DIVAnetUI). |
The default profile |
|
|
The maximum number of network addresses per user |
2 |
|
|
If true, all DIVAnet UI users are authenticated against user info in the database |
false |
|
|
The name of the AutoCopy rules configuration file |
None (AutoCopy disabled) |
|
|
The access rules file name. This file name is relative to the directory where the client adapter configuration file exists. |
None (if not configured, no access rules will be applied). |
Inside of the ApiPorts tag, multiple ApiPort definitions can appear. Table 4-2 shows the parameters that can appear as part of an ApiPort definition.
| Parameter | Description | Default Value |
|---|---|---|
|
|
This is the port socket to listen on. |
None (required) |
|
|
This identifies how to route requests (Direct or MultiDiva).
|
MultiDiva |
|
|
The site to route to if using Direct Mode. Sites are defined in the |
None (required in Direct Mode) |
|
|
The local address used to send to this Manager (typically which network card to use). Do not specify this if you're not sure. |
None (optional) |
|
|
Enables SSL encryption on the API socket connection (requires DIVA API 7.6 to use). |
False |
|
|
The Workflow Profile Name to use for requests traveling through this port (see the Workflow Profile section). If it is not supplied, the default Workflow Profile will be used. |
default (the default profile in MultiDiva Mode). |
Inside of the DivaManagers tag, multiple DivaManager definitions can appear. Table 4-3 shows the parameters that can appear as part of an DivaManager definition.
Table 4-3 DivaManagers Configuration Parameters
| Parameter | Description | Default Value |
|---|---|---|
|
|
The name of the site where the Manager is installed. The sitename listed must match what was configured in the DIVAnet database and what is configured the |
None (required) |
|
|
This identifies how to connect to the Manager (valid values: Socket, WebService). |
Socket |
|
|
The Network Address (IP or internet name) of the Manager |
localhost |
|
|
The port where clients connect to the Manager. |
None (required) |
|
|
The local address used to send to this Manager (typically which network card to use). Do not specify this if you're not sure. |
None (optional) |
|
|
The local port used. Do not specify this if you're not sure. |
0 |
|
|
The url of the ManagerAdapter if the ConnectionType is set to WebService; required. |
None (optional) |
|
|
DIVAnet will wait until the total number of Manager requests falls below this limit before sending more requests. This is used when the ConnectionType is set to Socket. When the Manager exceeds the number of running requests regardless of source (for example, DIVAnet, SPM, local API connection) DIVAnet will not send any more requests until the number of running requests on the Manager is below this threshold value. |
400 |
|
|
DIVAnet will wait until the number of requests DIVAnet itself has running on a Manager falls below this limit before sending more requests. When the Manager exceeds the number of running requests sent solely from DIVAnet itself, DIVAnet will not send any more requests until the number of running requests on the Manager sent only from DIVAnet is below this threshold value. Zero is a valid value, causing all messages to be queued internally within DIVAnet. The value -1 indicates there is no limit. |
100 |
Table 4-4 shows the parameters that can appear within the DivanetDatabase section.
Table 4-4 DIVAnetDatabase Parameters
| Parameter | Description | Default Value |
|---|---|---|
|
|
The IP Address of the database. |
localhost |
|
|
The port used to access the database. |
1521 |
|
|
The user name of the schema. |
None (required) |
|
|
The password of the schema. |
None |
|
|
The Oracle SID. This value is deprecated in favor of |
lib5 |
|
|
The Oracle Service Name. Can be supplied instead of |
None (optional) |
|
|
A value of "1" enables SSL encryption of the database connection. |
None (optional) |
|
|
Contains the encrypted database credentials generated by DIVAnetAdmin. This parameter cannot appear when |
None (optional) |
Table 4-5 shows the parameters that can appear within a WorkflowProfile section.
Table 4-5 WorkflowProfile Parameters
| Parameter | Description | Default Value |
|---|---|---|
|
|
The name of the Workflow Profile |
default |
|
|
Allow direct transfers (to Source/Destinations) from remote DIVAs. Set this to false to always create a local copy of content before restoring. |
true |
|
|
The default timeout for messages sent to Managers. |
15000 (15 seconds) |
|
|
How long to keep requests before timing them out (in hours). |
72 |
|
|
Prevent new Archive requests if the object exists on any site. If set to true, and the object exists on any site, requests to archive that object will be rejected (even if the object is not present on the site you are archiving to). |
true |
|
|
The interval between retries for the Delete Workflow |
5 minutes |
|
|
The total number of minutes for which Delete Workflow retries will continue. Delete retries will be attempted every |
0 minutes (do not retry) |
|
|
The total number of minutes to wait for a delete operation to complete. Set this value low for real-time deletes, and higher for batch operations. |
2 minutes |
|
|
How long to wait before retrying a copy request. This parameter applies only for Copy requests. |
5 minutes |
|
|
Keep retrying copies until this total time limit is reached (or they succeed). This parameter applies only for Copy requests. |
0 minutes (do not retry) |
|
|
In the case of failure, the maximum number of retries that should be attempted (commonly, retrying with content that exists on another site). |
3 times |
|
|
The interval between retries when DIVAnet performs a retry with the same site. |
5 minutes |
|
|
(Advanced) Maximum time a site is down before routing queued requests to another site. Deletes are also governed by the |
20 |
|
|
If the local site is down for an extended period (configured in |
None (no backup site) |
|
|
Converts a global delete request to a site delete at the specified site. |
None (optional) |
|
|
If true, users with this profile can only view requests issued by a user with this profile. |
False |
|
|
One or more Message Lists, each having a list of valid messages for the Workflow Profile. |
NA |
|
|
One or more valid Message Names:
At least one
|
None (one required) |
|
|
True if the Workflow Profile should include all of the mappings defined in the default Workflow Profile. |
False |
The Mappings tag contains multiple Site-To-Site Transfer mappings. A Site-To-Site Mapping defines how an object is copied from one site to another. Each mapping contains FromSitename and ToSitename parameters. Each mapping defines how copies are performed from FromSitename to ToSitename.
Each mapping contains a Type parameter that indicates the method used to perform the transfers (see Restore Workflow for more information). The other parameters are defaults that are used in the process of executing the intersite copy.
DIVAnet will use the FromSrcDest as a temporary storage area, and will optionally push to the target DIVA using the ToSrcDest. When storing the content DIVAnet provides a unique folder name that is appended to the FilePathRoot. After storing the content in the FromSrcDest, DIVAnet will (based on the Type parameter) either:
Archive the content into the target site
Wait until the content is archived successfully at the target site
Complete with no further action
Note:
To avoid specifying the same mappings multiple times in the configuration, you can set the Workflow Profile parameterUseDefaultMappings. The Workflow Profile will use mappings from the default Workflow Profile.Table 4-6 SitetoSiteTransfer Workflow Profile Parameters
| Parameter | Description | Default Value |
|---|---|---|
|
|
Origin sitename where objects are copied from. The value entered must match one of the sitenames defined in the |
None (required) |
|
|
Destination sitename where objects are copied to. The value entered must match one of the sitenames defined in the |
None (required) |
|
|
The type of transfer:
|
RestoreAndArchive |
|
|
The Source/Destination to use in the Restore step of the Copy. Note: Oracle recommends not using the default. |
MISSING_MAPPING_TO + |
|
|
The Source/Destination to use in the Archive step of the Copy. |
MISSING_MAPPING_TO + |
|
|
The target media to assign when making a temporary or transient copy of the object (performed on some Restore operations). The value is also used (depending on configuration) when API or UI users want DIVAnet to decide which media to use (the any keyword is used as the media). When RestoreAndMonitor is used with this variable, decide if the |
None (required for RestoreAndArchive) |
|
|
A path segment relative to the Source/Destination root. Prefixed to the unique folder name generated by DIVAnet. |
Remote |
|
|
DIVA Options to use in the Restore/Archive operations. |
-axf 1.0 -rm -delete_fpr -allow_delete_on_source |
|
|
The strategy to use when API or UI users decide to let DIVAnet choose which media to use for copies. This is invoked when the any keyword is used as the media. StoragePlan — Use the Storage Plan name of the source object as the default media. StoragePlanAndSitename — Prepend Source Sitename to the Storage Plan (separated by an underscore). TempMedia — Use the value of |
TempMedia |
|
|
True if the target media should be appended, as a subdirectory, after the
This option is useful when using the RestoreAndMonitor type with DFM, as DFM can parse the media name passed in this way. |
false |
|
|
Rate this transfer path against other transfer paths based on performance, preference. Used in choosing sites for Copy and Restore. Valid range is 0-40. Be careful in using values above 20, as you will start to override other factors such as disk versus tape, site status, and so on. Misuse of this option can cause performance issues on Restore operations, and can contribute to WAN network congestion. |
Default is 10, local gets increased by 10. |
When DIVAnet calculates which site to use for Restore operations, DIVAnet typically prefers the local site, provided the Source/Destination is reachable using the local site. However, there are some cases where another site may be preferable.
The Mappings tag can contain a SrcDest tag. Within the SrcDest tag, a Name tag defines a Source/Destination name. The PreferredSitename tag indicates the preferred site to use when the Source/Destination is requested in a Restore operation. Multiple SrcDest sections can be present.
The ManagerAdapterConfig.xml configuration file contains the configuration for the ManagerAdapter Service. Use the following steps along with the description of each parameter in the ManagerAdapter configuration (each of the following tables has this information) to configure the ManagerAdapter Service.
DIVAnet can place a filter on object information that is pulled by the DIVAnet DbSync service. This filter enables a site to select the subset of object records to be synchronized with downstream DIVAnet systems. The filtering is configured in, and performed by, the ManagerAdapter service.
Note:
Object Filters and Category Prefix Substitution are advanced features that require careful testing to implement in production workflows. Do not add or change object filters indiscriminately.For example, DIVAnet system in New York is configured to use and store assets from a site in Los Angeles. The Los Angeles site administrator wants to ensure that users in New York will only see objects that match one of three categories, AVID, POST1, and POST2. Implementing the following filter through the Los Angeles site's ManagerAdapter configuration file accomplishes this:
<LocalSitename>LosAngeles</LocalSitename>
<ObjFilter>
<RequestingSitename>NewYork</RequestingSitename>
<Category>AVID</Category>
<Category>POST1</Category>
<Category>POST2</Category>
</ObjFilter>
With this filter, objects matching the specified categories will be synchronized to the DIVAnet database in New York. Objects with other categories will not be synchronized. From the perspective of a New York site user, the only object records that exist on Los Angeles are the objects matching the configured category filter. Multiple ObjFilter tags may appear in the ManagerAdapter, each with a set of categories specific to a requesting site.
Note:
Category Object Filters do not automatically prevent the ManagerAdapter from accepting requests for objects not matching the filter. ManagerAdapter Access Rules prevent operations on objects that do not have certain categories.To prevent operations on objects not matching the filter, create the following access rule in the ManagerAdapter Access Rules file:
<Include>
<SourceSitename>NewYork</SourceSitename>
<Operation>*</Operation>
<ReqObjectCategory>AVID</ReqObjectCategory>
<ReqObjectCategory>POST1</ReqObjectCategory>
<ReqObjectCategory>POST2</ReqObjectCategory>
</Include>
This rule will only permit requests from New York for objects that match one of three categories, AVID, POST1, and POST2. Other categories are denied if no other Include Rules are specified. If you define access rules in the ManagerAdapter, ensure that the ClientAdapter is configured to communicate with the site in WebService mode.
There is a potential problem when using sync filtering by category. Continuing with the example, if New York creates an object with a category that is not present in the filter, and copies this object to Los Angeles, a naming conflict could occur. An object with that name could already exist on Los Angeles because the DIVAnet system in New York does not know about those objects. One solution is providing Access Rules in New York that limit the potential categories that can be archived.
You can achieve a more flexible solution using category prefix substitution. This feature not only filters the entries that are synced, but adds a category prefix to each incoming request. This provides a namespace-like feature for archived objects at a site.
In some DIVAnet workflows, a single site must accept objects copied from multiple sites. This can make it difficult to establish a set of unique categories for all objects in the system. Use category prefix substitution to address this situation. The following ManagerAdapter object filter will ensure that only objects in Los Angeles with categories beginning with NY001. are synchronized to New York's DIVAnet database.
<LocalSitename>LosAngeles</LocalSitename>
<ObjFilter>
<RequestingSitename>NewYork</RequestingSitename>
<CategoryPrefix>NY001.</CategoryPrefix>
</ObjFilter>
After applying the filter, but before the object reaches the destination (New York), the prefix is stripped – the remaining characters serve as the category in the New York DIVAnet database. For example, if the category of an object in Los Angeles is NY001.POST1, the resulting category sent to New York will be POST1. Similarly, any time the New York DIVAnet ClientAdapter sends commands to Los Angeles, the prefix is added back.
This allows Los Angeles to store copies of all of the objects from New York without naming conflicts. This technique allows Los Angeles to serve as a Disaster Recovery site for multiple sites. New York does not need to change its naming policy. New York references objects the same way that it always has, therefore no renaming on New York is necessary. Only one category prefix is allowed for each requesting site.
For this to work, the DIVAnet ClientAdapter service must be configured to connect to the remote site in WebService mode. Because objects are essentially renamed when copied to the site with a prefix substitution enabled, objects that were copied to the site previously will not have the prefix, which can present an issue. One solution involves providing a list of additional categories that are not translated. Another solution involves having Oracle DIVA installation specialists rename a subset of objects in the filtered site (that is, adding the category prefix to the category of each affected object in the DIVA database). If you use Category Prefix Substitution, you (will likely need to) disable Category checking in the DIVArchive Actor configuration (contact Oracle Support for instructions).
Note:
If you change an Object Filter, it will almost always be necessary for the downstream DIVAnet system to perform a resync of the site. That system can accomplish this by using the DIVAnetAdmin tool (refer to Chapter 6).The two types of category filtering can be mixed together. The following second filter (to Dallas) performs category prefix substitution (using DAL01) on all categories except the categories POST2 or POST3. Only object records that have the category prefix or have a category of POST2 or POST3 will be synchronized to Dallas.
<LocalSitename>LosAngeles</LocalSitename>
<ObjFilter>
<RequestingSitename>NewYork</RequestingSitename>
<CategoryPrefix>NY001.</CategoryPrefix>
</ObjFilter>
<ObjFilter>
<RequestingSitename>Dallas</RequestingSitename>
<CategoryPrefix>DAL01.</CategoryPrefix>
<Category>POST2</Category>
<Category>POST3</Category>
<ObjFilter>
If you use this hybrid approach, ensure that object names with categories appearing on the list (for example POST2) are not added again with the prefix (for example NY001.POST2). This policy can be enforced through Access Rules.
The following tables describe the parameters that can appear in a ManagerAdapter configuration file. The file is in XML format. The default value column indicates the value that the parameter will have if the parameter is not specified in the configuration file. The column also indicates whether the parameter is required or optional.
To create a new configuration file:
Navigate to the DIVAnet home directory (where DIVAnet is installed).
Navigate to the Program/conf/divanet/templates folder, copy the ManagerAdapterConfig.xml.ini to the parent directory, but leave out the .ini extension (../ManagerAdapterConfig.xml).
Using the tables below as a reference, edit the parameters in the ManagerAdapterConfig.xml file to configure the ManagerAdapter.
A sample ManagerAdapter configuration file appears in Appendix A.
Table 4-7 Top Level ManagerAdapter Parameters
| Parameter | Description | Default Value |
|---|---|---|
|
|
The name of the local site. The sitename listed must match what has been configured in the DIVAnet databases (local and remote), and must match what was configured in both the |
None (required) |
|
|
The network address (IP or internet name) of the DIVArchive Manager. |
localhost |
|
|
The port where clients connect to the DIVArchive Manager. |
None (required) |
|
|
The port used to receive web messages. |
None (optional) |
|
|
True if SSL should be enforced on incoming web service connections. |
True |
|
|
True if SSL should be used to connect to the DIVA Manager (DIVA 7.6 or greater is required). |
False |
|
|
The access rules file name. This file name is relative to the directory where the ManagerAdapter configuration file exists. |
None (if not configured, no access rules will be applied) |
|
|
The number of worker threads in DIVAnet thread pools. Used for tuning large configurations. If you are unsure do not set this value. |
50 |
|
|
The folder where the log files will be produced. |
The |
|
|
The detail level at which trace file logging takes place (ERROR, WARN, INFO, DEBUG, TRACE). |
INFO |
Table 4-8 ManagerDatabase Parameters
| Parameter | Description | Default Value |
|---|---|---|
|
|
The IP Address of the DIVArchive Manager Database. |
localhost |
|
|
The port used to access the database. |
1521 |
|
|
The user name of the schema. |
None (required) |
|
|
The password of the schema. |
None (required) |
|
|
The Oracle SID |
lib5 |
|
|
The Oracle Service Name. Can be supplied instead of |
None (optional) |
|
|
A value of "1" enables SSL encryption of the database connection. |
None (optional) |
|
|
Contains the encrypted database credentials generated by DIVAnetAdmin. This parameter cannot appear when |
None (optional) |
An ObjFilter can be defined for each requesting sitename in the ManagerAdapter. The following table shows the valid parameters for the object filter:
Table 4-9 ObjectFilter Parameters
| Parameter | Description | Default Value |
|---|---|---|
|
|
The site name of the site requesting objects |
None (required) |
|
|
Objects with the category provided will be synced to the requesting sitename. Multiple categories may appear. |
None (optional if |
|
|
The prefix will be prepended to every request received through the ManagerAdapter. Only objects with the category prefix will be synced to the requesting sitename. |
None (optional if |
The DBSyncConfig.xml configuration file contains the configuration for the DbSync Service. Use the following steps along with the description of each parameter to configure the DbSync Service.
Insure that the DbSync service is running when using the ClientAdapter. If the DbSync service is not running, some requests that would ordinarily succeed may fail. For example, DIVAnet restores of newly archived objects may fail, even though new DIVAnet archive requests may succeed.
The following tables describe the parameters that can appear in a DbSync configuration file. The file is in XML format. The default value column indicates the value that the parameter will have if the parameter is not specified in the configuration file. The column also indicates whether the parameter is required or optional.
To create a new configuration file:
Navigate to the DIVAnet home directory (where DIVAnet is installed).
Navigate to the Program/conf/divanet/templates folder, copy the DBSyncConfig.xml.ini to the parent directory, but leave out the .ini extension (../DBSyncConfig.xml).
Using the following Parameter Description Tables as a reference, edit the parameters in the DBSyncConfig.xml file to configure DbSync.
A sample DbSync configuration file appears in Appendix A.
Table 4-10 DbSync Top Level Parameters
| Parameter | Description | Default Value |
|---|---|---|
|
|
The sitename of the local DIVAnet site (where DbSync is running). The sitename listed must match what was configured in the DIVAnet database and what is configured in both the |
None (required) |
|
|
The folder where the log files will be produced. |
The |
|
|
The detail level at which trace file logging takes place (ERROR, WARN, INFO, DEBUG, TRACE). |
INFO |
|
|
The base rate at which sites are polled for information. Change this parameter only if slow networks and (or) systems are encountered. |
2000 |
|
|
The port used to send management messages to DbSync. |
None (optional) |
|
|
True if SSL should be enforced on incoming web service connections. |
true |
|
|
The numer of records to query at once when syncing site metadata |
500 |
|
|
The name of the AutoCopy rules configuration file |
None (AutoCopy disabled) |
Inside of the DivaManagers tag, multiple DivaManager definitions can appear. Table 4-11 shows the parameters that can appear as part of a DivaManager section.
Table 4-11 DivaManagers Parameters for DbSync
| Parameter | Description | Default Value |
|---|---|---|
|
|
Url of the service on the DIVA Manager platform to use for syncing. By default, this corresponds to the network address of the remote ManagerAdapter, qualified by the WebServicePort used by the ManagerAdapter. |
None (optional) |
|
|
The official name of the site to sync object information from. The sitename listed must match what was configured in the DIVAnet database and what is configured in both the |
None (required) |
Configure the DIVAnet Database parameters as shown in Table 4-12.
Table 4-12 DIVAnetDatabase Parameters
| Parameter | Description | Default Value |
|---|---|---|
|
|
The IP Address of the database. |
localhost |
|
|
The port used to access the database. |
1521 |
|
|
The user name of the schema. |
None (required) |
|
|
The password of the schema. |
None (required) |
|
|
The Oracle SID (Site Identifier). |
lib5 |
|
|
The Oracle Service Name. Can be supplied instead of |
None (optional) |
|
|
A value of "1" enables SSL encryption of the database connection. |
None (optional) |
|
|
Contains the encrypted database credentials generated by DIVAnetAdmin. This parameter cannot appear when |
None (optional) |
In DIVAnet, you use Access Rules to control access that client applications and users have to DIVAnet operations and resources. Access rules can be run in three ways:
On DIVAnet requests within the ClientAdapter service (in MultiDiva Mode or sent via DIVAnet UI)
On DIVArchive requests within the ManagerAdapter service
On DIVArchive requests that enter the ClientAdapter through a Direct Mode port
To run Access Rules, you must define the AccessRulesFilename parameter in the ClientAdapter and (or) ManagerAdapter configuration file. You must supply the file name without the path - DIVAnet assumes that the file will be located in the same directory as the ClientAdapter configuration file.
Access rulesets defined in the ClientAdapter (MultiDiva Mode) enforce access control on DIVAnet requests (received locally). Access rulesets defined in the ManagerAdapter configuration enforce access control on DIVArchive requests (submitted to satisfy a DIVAnet request). Access control on each site is important for enforcing local rules about content. Access control at the service level is important for controlling which users can perform certain operations.
Access rulesets defined in the ClientAdapter (Direct Mode) enforce access control on either DIVAnet requests or DIVArchive requests, depending on whether the remote system is another DIVAnet instance, or a DIVArchive system. In this mode, additional operation types are available for use in rulesets. These operations correspond to DIVArchive-specific requests, and are detailed below.
Let's quickly jump into an example to get more familiar with the rules themselves. The following rule allows Archive operations for users connecting as admin or as operator from either Source/Destination DATA_EXP_PDAT1 or VID_FTP_3, and, archiving to a media of either HDFeatures or spm (you will see that the order of the attributes is not significant), and being named with a category containing the word POST.
<Include>
<Operation>Archive</Operation>
<Username>admin</Username>
<Username>operator</Username>
<ReqMedia>spm</ReqMedia>
<ReqObjectCategory>*POST*</ReqObjectCategory>
<ReqSourceDest>DATA_EXP_PDAT1</ReqSourceDest>
<ReqSourceDest>VID_FTP_3</ReqSourceDest>
<ReqMedia>HDFeatures</ReqMedia>
</Include>
In the following two rules, guest users from the GUI Workflow Profile are not allowed to copy from diva2 to diva3, or vice versa.
<Exclude>
<WorkflowProfile>GUI</WorkflowProfile>
<Username>guest</Username>
<Operation>Copy</Operation>
<SourceSitename>diva2</SourceSitename>
<TargetSitename>diva3</TargetSitename>
</Exclude>
<Exclude>
<Username>guest</Username>
<WorkflowProfile>GUI</WorkflowProfile>
<Operation>Copy</Operation>
<SourceSitename>diva3</SourceSitename>
<TargetSitename>diva2</TargetSitename>
</Exclude>
You used two rules here because you didn't want to explicitly restrict copy operations that occur within the same site. For instance, someone at site diva2 may want to copy an object (using DIVAnet) to a new tape - in this case the source and target sitename are both diva2! If you had a single rule that contained all of the SourceSitename and TargetSitename attributes, you would exclude copies from diva2 to diva2 and from diva3 to diva3!
You are still not done. The copy will not succeed unless you have at least one Include rule that matches.
<Include>
<Operation>Copy</Operation>
<WorkflowProfile>GUI</WorkflowProfile>
<Username>guest</Username>
<Operation>ApiConnect</Operation>
</Include>
In this case, a very general Include rule gives you what you want, the ability to copy everywhere except for diva2 to diva3 and vice versa. In fact, you didn't really need an Exclude rule at all. Sometimes, however, things are easier with Exclude rules. Keep in mind that if an Exclude rule matches an operation, that operation will be denied, even if one or more Include rules match.
To summarize, there are two types of rules, Include and Exclude. Access is denied for all requests unless at least one Include rule matches the operation about to be performed. However, if any Exclude rule matches, the operation is automatically rejected, regardless of any Include rules that match.
On requests such as Delete, Copy, Restore, Partial File Restore, Cancel, and Archive, DIVAnet runs the entire set of Access Rules set to see if the operation is permitted. It examines variables such as:
Originator attributes — the Workflow Profile of the connection, the user name that sent the message, the IP address of the originator.
Request attributes — the Source/Destination, the source/target sitenames, the requested media, comments, and so on. These are derived from the request itself. Many of these are prefixed with Req.
Object attributes - the media(s) the object is stored on, the storage plan, the object size, and so on. These are derived from the object being processed by an operation. Many of these are prefixed with Obj.
The following rule combines all three attribute types. It allows a user diva to perform a site delete on New York only when the object exists on Los Angeles.
<Include>
<Username>diva</Username>
<Operation>Delete</Operation>
<SubType>SiteDelete</SubType>
<TargetSitename>NewYork</TargetSitename>
<ObjOnSite>LosAngeles</ObjOnSite>
</Include>
DIVAnet requests are generated when requests are received in MultiDiva Mode. Access rules can be created against these DIVAnet operations. The following are details of some attributes specific to DIVAnet requests.
The ApiConnect and WebConnect operations are special operations that must be included to establish a connection to the ClientAdapter.
ApiConnect — This operation governs the ability to connect to the ClientAdapter through an API client socket connection. This is required for DIVA API connections.
WebConnect — This operation governs the ability for applications to connect through web connections (DIVAnetUI and DIVAnetAdmin). This is required for DIVAnetUI connections.
When these operations are matched against your rules, keep in mind that only originator attributes will be present to match against. For example, TargetSitename would not be matched when access rules are run during the ApiConnect operation, because the attribute is simply not present when a client connects.
The delete operation has a SubType field which represents a subtype of the operation. You can include the SubType field in rules along with the Delete operation, supplying multiple SubType parameters if you want. The values for Delete SubType are:
GlobalDelete — Matches if the delete operation being performed is a global delete of an object on all sites. This also matches a site delete operation that just happens to be deleting all remaining objects in DIVAnet.
SiteDelete — Matches if the delete operation is a delete of all instances on a particular site (the name of the site can be matched in rules using the TargetSitename parameter). In addition, an operation will have this SubType if the requester is deleting a single instance, but that is the last instance of the object on that site.
InstanceDelete — This delete operation deletes a single instance on a site, and there are other instances on the site.
Specifying this parameter in rules is useful for enforcing the scope of the permitted delete operations.
DIVAnet allows access rules to be run on DIVArchive requests as well. Access rules defined in the ManagerAdapter specify which DIVArchive operations (sent to satisfy DIVAnet requests) are permitted. Only the operations valid for DIVAnet requests can be specified in the rulesets. In ManagerAdapter rulesets, the WorkflowProfile, TargetSitename, and SubType attributes are invalid.
Similar to the ClientAdapter rulesets, the WebConnect Operation must be granted for connections to be established to the ManagerAdapter. This also extends to DbSync operations. The SourceSitename attribute corresponds to the specific site that is making a request. The ApiConnect operation is not available in ManagerAdapter Access Rules.
Matching a rule involves comparing attributes in the rule against the actual values in each request, in a matching object, or request originator. Wildcards are allowed (use an asterisk (*) for wildcards). Case is insensitive for the tag names, but most values are case sensitive. The Operation tag is required in each rule. You can provide an Operation tag containing an asterisk (*) to indicate that the rule applies for all operations. However, you should be careful when doing this because not all attributes are valid for all operations.
Distinct attributes in a rule (an Include or Exclude rule) are joined together using a logical AND in the matching process. However, a single attribute specified more than one time in a rule causes those attributes to be joined together using a logical OR in a single expression.
When matching a requested operation against an access rule, DIVAnet determines if the attribute in the rule is applicable for the operation being performed. If not, the attribute is not used in the comparison.
Rules can be grouped into Rulesets. Each Include-Exclude rule must be contained inside of Ruleset tags. Each incoming DIVAnet operation is matched against all rulesets. Rulesets are useful because they can have attributes that serve as defaults for all rules contained inside. In the matching process, each Ruleset default attribute is folded in to each child rule - as if the attribute were specified directly within the rule. It is common to use Workflow Profile as a default attribute for Rulesets, as Workflow Profile is populated on every requested DIVAnet operation.
The following attributes can be defaulted within a ruleset:
User Name
Net Address
WorkflowProfile (in ClientAdapter rules)
The following example allows users connected with a WorkflowProfile of GUI to view requests and assets, and to perform deletes of individual instances on site diva1. Remember that a SubType of InstanceDelete will deny any delete that would remove the last instance of a particular object on a site.
The second part of the example prohibits all connections, either web or API connections, that originate from the subnet 172.53. It will do this for any operation, regardless of its Workflow Profile.
<Ruleset>
<WorkflowProfile>GUI</WorkflowProfile>
<Include>
<Operation>WebConnect</Operation>
<Operation>Delete</Operation>
<SubType>InstanceDelete</SubType>
<TargetSitename>diva1</TargetSitename>
</Include>
</Ruleset>
<Ruleset>
<NetAddress>172.53*</NetAddress>
<Exclude>
<Operation>ApiConnect</Operation>
<Operation>WebConnect</Operation>
</Exclude>
</Ruleset>
Table 4-13 shows the parameters that can appear under the Ruleset section.
| Parameter | Description | Default Value |
|---|---|---|
|
|
This attribute, defined in the ClientAdapter configuration, is the name of a workgroup or set of applications that access DIVAnet. This attribute is made part of every rule in the ruleset. |
None (optional) |
|
|
The user name passed in the API or specified in the web request. This attribute is made part of every rule in the ruleset. |
None (optional) |
|
|
The network address (IP or internet name) of the remote connection. This may be the address of a gateway or router and not the address of the originator. This attribute is made part of every rule in the ruleset. |
None (optional) |
|
|
A rule that denies permission if it matches the DIVAnet operation. |
None (optional) |
|
|
A rule that allows permission if it matches the DIVAnet operation. |
None (optional) |
You can specify rule attributes that appear in requests. For example, ReqMedia will match the media and (or) storage plan specified in a request (operation).
Similarly, you can specify rule attributes that match against the archived object that the request is processing. For example, if a certain object is specified in a delete operation, ObjHasMedia will match any media that is currently part of that archived object regardless of media passed in the request.
Table 4-14 shows the parameters that can appear in an Include or Exclude rule section.
Table 4-14 Rule Operational Parameters (Include or Exclude)
| Parameter | Description | Default Value |
|---|---|---|
|
|
The name of the DIVAnet operation to match:
There are additional operations available for DIVArchive operations in Direct Mode:
|
None (optional) |
|
|
The user name of the connected API user and (or) service user. |
None (optional) |
|
|
The ClientAdapter profile name. |
None (optional) |
|
|
The IP address of the API application and (or) user. |
None (optional) |
|
|
The source sitename of the operation. Some operations do not have a source sitename (for example, Archive has a Source/Destination as the source). If the request is retried on another site, this value will change, and the entire rule will be reevaluated.When this attribute appears in ManagerAdapter rules, this matches the site that submitted the request. |
None (optional) |
|
|
The target sitename of the operation. Some operations do not have a target sitename (for example, Restore has a Source/Destination as the target, not a site). If the request is retried on another site, this value will change, and the entire rule will be reevaluated. |
None (optional) |
|
|
Multi DIVA Mode operation type (Delete command has GlobalDelete, SiteDelete, and InstanceDelete). |
None (optional) |
Table 4-15 Rule Request Parameters (Include or Exclude)
| Parameter | Description | Default Value |
|---|---|---|
|
|
The name of the object that is being processed. |
None (optional) |
|
|
The category of the object (in DIVArchive this is part of the formal name of the object). |
None (optional) |
|
|
The Source/Destination specified in the request. |
None (optional) |
|
|
The comments field in the request. |
None (optional) |
|
|
The media that was requested as part of the operation/request (sitename should not be appended). Keep in mind that Storage Plan can be passed as the requested media. |
None (optional) |
|
|
The options field in the request. |
None (optional) |
Table 4-16 Rule Object Parameters (Include or Exclude)
| Parameter | Description | Default Value |
|---|---|---|
|
|
Matches if the object exists on the specified site. |
None (optional) |
|
|
Matches if the object is NOT on the specified site. |
None (optional) |
|
|
Matches any media on any site. |
None (optional) |
|
|
Matches storage plan on any site ( |
None (optional) |
|
|
Restricts specified storage plan to a specific site. |
None (optional) |
|
|
Matches if total object size in fractional GBs is less than the specified value. |
None (optional) |
|
|
Matches if total object size in fractional GBs is greater than the specified value. |
None (optional) |
AutoCopy is a feature that can automatically create one or more copies of an asset after it is archived. AutoCopy detects new content at one site and then (based on a set of rules) creates copy tasks to copy the new asset to one or more remote sites.
AutoCopy rulesets control which new objects will be copied, and with what settings. You can define multiple rulesets in the AutoCopy configuration file (see "Creating a New AutoCopy Configuration File").
Each ruleset contains the following:
A set of Include rules — These act as "if" statements which describe the assets that should automatically be copied upon archive (for a list of valid parameters, see "Include Section Parameters").
A single Action section — This acts as a "then" statement which determines what site to copy to, and which archive media to use as storage (for a list of valid parameters, see "Action Section Parameters").
When any new asset matches an Include rule, DIVAnet uses the parameters in the corresponding Action section to generate a copy task. Note that AutoCopy rules can create tasks for assets originating from any DIVAnet site (not just the local site).
The format and behavior of AutoCopy Rules loosely match the behavior of Access Rules (see "Access Rules"). Like Access Rules, repeating the same attribute within a rule creates an ”OR” condition for the attribute. However, unlike Access Rules, a newly archived object can match multiple rulesets, and consequently create multiple copy tasks.
AutoCopy rules are evaluated:
On a new asset, when it is archived at a particular site.
On all existing assets, when you select the ”Run Rules on Existing Assets” option in the DIVAnetAdmin utility (see "Managing the AutoCopy Queue with DIVAnetAdmin").
Example 4-1 Basic AutoCopy Ruleset
This ruleset will copy object assets from NewYork that have a storage plan of "SP_MEDIA1" and are less than 300GB in total size. If a match occurs, DIVAnet will create a copy in the LosAngeles site with a media of "LTArch_DVT_M2" and a priority of 50.
<Ruleset>
<Include>
<SourceSitename>NewYork</SourceSitename>
<ObjHasStoragePlan>SP_MEDIA1</ObjHasStoragePlan>
<ObjHasSizeGbLessThan>300</ObjHasSizeGbLessThan>
</Include>
<Action>
<Sitename>LosAngeles</Sitename>
<Media>LTArch_DVT_M2</Media>
<Priority>50</Priority>
</Action>
</Ruleset>
Example 4-2 Complex AutoComplex Ruleset
This ruleset will copy assets from Dallas that have an ObjectCategory starting with "POST". Or, objects archived in NewYork that have the following:
An original source/dest of either "Interplay_001" or "Interplay_002", and
An object name starting with "AV_" and ending with "_DVT"
If either rule matches, DIVAnet will copy the new object (from either NewYork or Dallas) to the LosAngeles site one day after the copy task is created.
<Ruleset>
<Include>
<SourceSitename>Dallas</SourceSitename>
<ObjectCategory>POST*</ObjectCategory>
</Include>
<Include>
<SourceSitename>NewYork</SourceSitename>
<ObjSourceDest>Interplay_001</ObjSourceDest>
<ObjSourceDest>Interplay_002</ObjSourceDest>
<ObjectName>AV_*_DVT</ObjectName>
</Include>
<Action>
<Sitename>LosAngeles</Sitename>
<Media>LTArch_DVT_M1</Media>
<Priority>35</Priority>
<DelayMins>1440</DelayMins>
</Action>
</Ruleset>
The AutoCopy queue is a list of copy tasks waiting to be executed. The MaxRequests parameter limits the number of AutoCopy requests executing at one time. By default, DIVAnet uses a combination of task priority and the last retry date to determine which tasks to schedule next. For additional scheduling options, see "Scheduling AutoCopy Tasks".
What happens if the object is already present on the target site? If an AutoCopy task's object name and category matches an asset on the target site, and is stored on the target media, DIVAnet will not create a copy, and will mark the task as succeeded.
If the object already exists on the target site, but is not stored in the target media, DIVAnet, by default, performs a local copy to group operation at a local site. However, if the AutoCopy parameter AllowLocalCopy is set to false, DIVAnet will not generate a copy request, and instead will mark the task as succeeded.
When are tasks removed from the queue? After an AutoCopy task succeeds, DIVAnet removes the task from the queue. If an asset was copied to a site using AutoCopy, and the asset is subsequently deleted from the target site, there will be no action taken to re-copy the asset to the target site. If an asset is deleted from all sites, the corresponding entries in the AutoCopy queue are also deleted.
What happens when a request fails? If a scheduled copy request fails, DIVAnet creates new copy requests at regular intervals until one succeeds. You can define RetryTotalLimit and RetryDelayMins to control the retry attempts.
This retry is distinct from the retry options available in the Workflow Profile, which retry part or all of the request without terminating the request. The request ID always stays the same. When issues occur on the target DIVA site, the archive step of the transfer can be retried without repeating the download to the target site. In contrast, the AutoCopy retry creates a brand new copy request. You can combine the two types of retry to provide an effective and reliable method of transfer.
Viewing AutoCopy Assets — To view AutoCopy assets, set the ”Has AutoCopy Task” filter to ”True” in the asset search panel (see "Searching Assets"). This returns all assets that have an AutoCopy task either waiting to be scheduled or running. On the asset detail panel, you can see all of the copy tasks for an asset, and any running requests for the asset. You can also view any spawned copy requests on the DIVAnet UI requests screens.
Canceling AutoCopy Tasks — To cancel tasks, select all of the assets that have tasks you want to remove, and then select Cancel Tasks from the action menu. By default, this cancels all tasks associated with the assets. However, you can set parameters in the dialog to only cancel tasks from a certain site, and/or tasks having a specific target media. DIVAnet cancels a task by removing the task from the AutoCopy queue. Cancelling has no effect on any copy requests that may be currently running.
Pause/Unpause and Clear AutoCopy Tasks — Using DIVAnetAdmin, you can pause and unpause the scheduling of new requests. Pausing or unpausing will not effect requests that AutoCopy has already spawned. You can also use DIVAnetAdmin to clear all tasks in the AutoCopy queue. See "DIVAnetAdmin Options".
Evaluate Existing Assets Against AutoCopy Rules — You can select ”Run Rules on Existing Assets” option in the DIVAnetAdmin utility to generate copy tasks for any existing asset that matches the AutoCopy rulesets. See "DIVAnetAdmin Options".
Caution:
Running AutoCopy rules on existing assets can result in thousands of copy tasks added to the AutoCopy queue.Copy requests sent to DIVAnet (running in MultiDiva mode) via the DIVA API normally execute immediately. However, there is an option to route requests to the AutoCopy queue for scheduling. This allows an application to schedule thousands of copies at once, just by using the DIVA API.
To route a request to AutoCopy, provide the -autocopy flag in the options field of a Copy command sent to DIVAnet (requires DIVA API version 7.3 or greater). DIVAnet will use the sitename and media in the Copy request to generate the task. Another parameter -autodelaymins will delay the activation of the task for a specific number of minutes.
You can optionally route DIVAnet UI copy requests to the AutoCopy queue. This facilitates the scheduling of thousands of copies at one time. See "Copying an Object".
Below are a few features that can assist in the scheduling copy tasks that are in the AutoCopy queue, waiting to be processed. These features make the best use of available tape, disk, and cloud resources.
When making copies of large numbers of tape-based assets, tape library mounts, dismounts, and positioning can become significant. For items in the queue, the Schedule by Tape feature will group together assets that exist on the same tape, and use these groupings to schedule copies. This can help minimize the total time to restore tape-based assets.
To enable the feature, set the NumTapesToSchedule parameter to a value greater than zero.
The NumTapesToSchedule parameter indicates how many tapes to schedule concurrently (it does not indicate the number of tasks or assets to schedule). You should set this value to the maximum number of tape drives you wish to dedicate to copying. DIVAnet selects a list of tapes to copy, picks assets from each tape, and then schedules them in a round-robin fashion, until it reaches the MaxRequests limit. You can set the outbound request priority by setting the ScheduleByTapePriority parameter. Using Schedule By Tape will always override any priority specified in AutoCopy rules, as priority affects request ordering in DIVArchive.
In addition, you can set up Schedule by Tape to run only during off-peak hours, if desired. See below.
Using AutoCopy, you can define a daily ”off-peak” time window during which DIVAnet can execute more requests at one time (or less requests, if desired).
The daily start time (OffPeakStartTime) and stop time (OffPeakStopTime) define the off-peak window. If either values are omitted (or they are the same), no off-peak period will occur.
By configuring OffPeakNumTapesToSchedule you can run the Schedule by Tape feature during off-peak hours. See above for more information.
The AutoCopy configuration file (AutoCopyRules.xml) contains:
If you modify the AutoCopy configuration file while the system is running, select the ”Reload Workflow Profile / Rules” option in DIVAnetAdmin to inform DIVAnet of your changes without restarting services (see "DIVAnetAdmin Options").
Navigate to the DIVAnet home directory (where DIVAnet is installed).
Navigate to the Program/conf/divanet/templates folder.
Copy the AutoCopyRules.xml.ini to the parent directory, but leave out the .ini extension (../AutoCopyRules.xml).
Using the tables below as a reference, edit the parameters in the AutoCopyRules.xml file to configure the AutoCopy feature.
To activate AutoCopy, you must add a reference to the AutoCopy config file in both the ClientAdapter and DbSync configuration files. The AutoSyncFilename parameter indicates the name of the AutoCopy file. The services assume the AutoCopy file is in the same directory as the other service configuration files.
The following table contains the configuration file top-level parameters used to customize scheduling behavior. The default value in the "Data Type/Default" column indicates the value that the parameter will have if it is not specified in the configuration file.
Table 4-17 Configuration Parameters
| Parameter | Description | Data Type/Default |
|---|---|---|
|
|
Maximum simultaneous AutoCopy requests to schedule at one time (during normal processing) |
Integer (default: 10) |
|
|
Schedule this number of tapes at a time |
Integer (default: 0=disable scheduling by tape) |
|
|
Allows local copies using AutoCopy. If true, and the asset already exists at the target site, a local copy to the target media will be scheduled (provided the object is not already stored on that media). |
Boolean (default: true) |
|
|
The DIVANet Workflow Profile to use when submitting copy requests |
String (default: ”default”) |
|
|
Copy request priority to use when Schedule by Tape is enabled. Schedule by Tape overrides the priority specified in AutoCopy rules. |
Integer (default: 40) |
|
|
Maximum number of retries for an AutoCopy task |
Integer (default: 3000) |
|
|
After an AutoCopy request fails, the minimum delay before another attempt |
Integer (default: 15 minutes) |
|
|
How many requests of the total to be reserved for disk-based assets, when scheduling by tape |
Integer (default: 1) |
|
|
Time to start the off-peak period |
Time of day (HH:MM, local 24hr) (default: none: no off-peak period) |
|
|
Time to end the off-peak period |
Time of day (HH:MM, local 24hr) (default: none: no off-peak period) |
|
|
Maximum simultaneous AutoCopy requests to schedule during the off-peak period |
Integer (default: 40) |
|
|
Number of tapes to schedule during off-peak hours |
Integer (default: 0=no scheduling by tape) |
AutoCopy rulesets determine which assets DIVAnet should replicate to other sites. See "AutoCopy Rulesets" for more information and sample rulesets.
Table 4-18 Include Section Parameters
| Parameter | Description | Data Type/Default |
|---|---|---|
|
|
Matches the sitename where the asset was archived |
String |
|
|
Matches if asset was archived more than this many days ago |
Integer (number of days) |
|
|
Matches if asset was archived less than this many days ago; useful if a DIVAnet database resync occurs |
Integer (number of days) |
|
|
The name of the asset |
String |
|
|
The category of the asset (part of the formal name of the asset) |
String |
|
|
The comments field in the new asset |
String |
|
|
Matches the media to which the asset has been archived |
String |
|
|
Matches the source destination where the object was archived from |
String |
|
|
Matches storage plan of new asset |
String |
|
|
Matches if the asset size is greater than this number (in fractional GBs) |
Decimal (in GBs) |
|
|
Matches if the asset size is less than this number (in fractional GBs) |
Decimal (in GBs) |
Table 4-19 Action Section Parameters
| Parameter | Description | Data Type/Default |
|---|---|---|
|
|
The name of the DIVAnet site to copy to |
String (required) |
|
|
The target archive media to copy to |
String |
|
|
The priority of the request |
Integer (1-100; default: 50) |
|
|
The time to wait in minutes before scheduling the task |
Integer (default: 0) |
DIVAnet allows variable substitution in configuration files to make configuring multiple script files easier. When the pattern ${variable_name} is encountered in an XML Value (variables are not valid in Tag Names), the value of the variable is substituted when the DIVAnet reads the script. The value can be taken from an environment variable or assigned directly within the script.
If the Variable Name in the script is named the same as an Environment Variable, the value of that variable will be substituted in the script. Alternatively, you can define variable values at the top of each script using the Variable tag. The syntax is: <Variable name="LocalSitename" value="diva1"/>. When DIVAnet reads a configuration script, it checks to see if any variables that are used within the script have been set at the top. If not, it then looks for an Environment Variable with the same name as the variable.
For ease of use, a script file named divanetEnv.conf has been created within the DIVAnet home directory, in the Program\conf\divanet\wrapper subfolder. Variables can be centrally defined in this configuration file and will be available to all of the DIVAnet services. If the values are changed and the service is restarted, the changes will be reread. Refer to the divanetEnv.conf file for sample variables.