2 Installation Planning

DIVAnet is commonly configured at multiple DIVA sites. This chapter describes how to determine which DIVAnet services to install and where. The major steps are:

1. Understand which sites to connect to achieve the desired workflows. See Understanding Site Connectivity.

2. Enable remote access for each site in the system (or local access). See Enabling Sites for Remote Access.

3. Configure client access for sites that have applications connected them. See Configuring Client Access.

4. Configure the access control and asset replication policies for the DIVAnet network. See Configuring DIVAnet Policies.

Understanding Site Connectivity

A DIVAnet site is defined as exactly one DIVArchive installation (which could exist in the cloud) and one or more DIVAnet services. Each site has a unique sitename. Each DIVAnet service belongs to a particular site, indicated by the LocalSitename parameter in the DIVAnet configuration files. A DIVAnet site uses the sitename to refer to other sites in the network.

The most basic DIVAnet connectivity uses DIVAnet as a DIVArchive proxy for a single DIVArchive system. In this configuration, you would use DIVAnet Direct Mode. This mode does not provide a view of multiple sites, and cannot be used (for example) to copy between sites. For more information on setting up DIVAnet Direct Mode, see "Configuring Client API Ports".

To have multiple DIVA sites act as one large archive system, DIVAnet sites must be connected together using multiple DIVAnet services.

DIVAnet can connect to remote sites to retrieve asset information, monitor the remote site's status, and send requests to the site (for example, a restore request), to satisfy DIVAnet level requests. You can use DIVAnetUI to view assets that are stored on multiple sites, copy assets from one site to another, and view DIVAnet requests. You can use the DIVArchive API to connect to DIVAnet and perform many of the same operations, and more.

Note:

Some DIVAnet deployments will not require each site to be connected to all other sites in the network.

Sample DIVAnet Deployment

The following figure shows an example of a typical DIVAnet deployment with three sites: New York, Los Angeles, and Dallas. In this example, applications in New York can see and copy assets from Los Angeles and Dallas, as well as locally in New York. In addition, applications in Los Angeles can see and copy assets from New York and Dallas. No customer applications are running at the Dallas site.

DIVAnet Services

A DIVAnet service is either a Windows or Linux Service installed on a server responsible for carrying out computing tasks in a DIVAnet deployment. Table 2-1 shows a summary of the available DIVAnet services.

Table 2-1 DIVAnet Services

Service	Description
ClientAdapter	Accepts requests from the DIVA API and web clients, and interacts with DIVArchive sites and the DIVAnet database to satisfy those requests. You configure this service when implementing client application access. You can also use this in a minimal proxy-only DIVAnet deployment (DIVAnet Direct Mode, described in Configuring Client API Ports). For more information, see DIVAnet ClientAdapter Service.
ManagerAdapter	Serves as a bridge between DIVAnet and the Oracle DIVArchive Manager. This service provides remote access for a DIVA site. You must configure this service for all DIVAnet sites that will be accessed by other sites remotely, especially those that will have asset information synchronized. For more information, see DIVAnet ManagerAdapter Service.
DbSync	Responsible for synchronizing asset information from multiple DIVArchive sites, and storing the information in the DIVAnet database. You configure this service when implementing client (application) access. For more information, see DIVAnet DbSync Service.

Enabling Sites for Remote Access

To enable a DIVArchive site for remote access by other DIVAnet systems, you must set up a ManagerAdapter service on the site and configure DIVArchive for remote access.

The following figure shows an example of two sites: a New York site with a full DIVAnet configuration (remote access and client access) and a Dallas site that is configured just for remote access. The Dallas site only has one DIVAnet service running: the ManagerAdapter service. DIVArchive has been configured so it can interface with other sites.

DIVAnet ManagerAdapter Service

The ManagerAdapter service serves as a bridge between DIVAnet and the DIVArchive Manager. It must be configured to provide remote access by other DIVAnet systems.For security and performance reasons, Oracle recommends that the ManagerAdapter be installed on the same system as the DIVArchive Manager. Likewise, it is often the case that the ClientAdapter and DIVAnet database run together on a different server entirely.The ManagerAdapter is configured using a simple configuration file. For more information, see Chapter 4.

DIVArchive

To achieve DIVAnet workflows, you perform most of the configuration at each DIVArchive site. This section details some concepts needed to understand how DIVAnet interacts with DIVArchive, and the importance of the DIVA configuration. For the details on how to configure DIVArchive, refer to the Oracle DIVArchive Installation and Configuration Guide.

Objects and Instances

In a DIVArchive system, archived objects are uniquely identified by two parameters: an Object Name and an Object Category. The Category is part of the formal name of the object, a kind of namespace. For example, an object with a name of CLIP01 and category of MOVIES is a different object than one with a name of CLIP01 and a category of COMMERCIALS.

DIVAnet uses the object name and category to associate objects on various sites.

Note:

If an object on one site has the same object name and category as on another site, DIVAnet will consider both to be the same object.

When you archive assets using DIVAnet, it will (by default) reject new assets that have the same name (and category) as assets already archived on other sites. However, archives issued directly to a DIVArchive system are not checked this way. Archiving without using DIVAnet may result in an object on site B that has different content than the corresponding object on site A, event though the two objects have the same name and category. This can lead to DIVAnet restoring the wrong content.

In DIVArchive, each archived object can contain many instances: one instance for each physical copy of the object on tape or on disk. There is an order number for each instance. The numbering starts with zero and increments by one for each instance in the object. So, you can uniquely refer to an instance on a DIVA system by providing the object name, category, and instance order number.

DIVAnet assigns its own set of instance order numbers that are derived from the DIVArchive instance order number. It does this so that for each object, the DIVAnet instance order numbers are unique across all DIVAnet sites.

Source and Destinations

A DIVArchive Source/Destination contains information necessary to communicate with a customer server or disk external to DIVArchive. Customers transfer content to and from DIVArchive through these servers and disks.

If a Source/Destination on one site has the same name as one on another site, DIVAnet concludes that they refer to the same physical server and (or) disk. This convention is important in setting up a DIVAnet system (see Restore Workflow for more information). If the Source/Destinations are addressable through the API, and they point to the same physical server, disk, and path, you should give them the same name.

Setting Up Transfer Source/Destinations

To use DIVAnet to transfer content from one site to another, configure at least one Source/Destination to be accessible from both sites. DIVAnet will use this common Source/Destination to copy objects from one site to the other. The Source/Destination configurations on both sites should have the following characteristics:

• Same Name — On all sites, you should configure the same name for Source/Destinations that refer to the same physical server, disk, and directory.

  DIVAnet's Site-To-Site Mappings can handle Source/Destinations that point to the same place but are not necessarily named the same. See Site-to-Site Mappings for more information.

• Same Place — The two Source/Destination entries must point to the exact same location (path) on the disk on a server. The types of transfer (for example, FTP_STANDARD, DISK) may differ on each site, and may even have different root paths in the configuration. For example, a Source/Destination named NY_SHOWS might be of type DISK on the New York site, but of type FTP on the Los Angeles site.

• No Transcode or Renaming — For Source/Destinations used in inter-site copies, do not configure the Source/Destination for transcoding upon restore. This will lead to incorrect content being archived to DIVA sites.

• Delete on Source — For each Source/Destination that will be used in copy commands, set the -allow_delete_on_source option in the DIVArchive Source/Destination configuration. This allows you to delete content from the site after it has been transferred to DIVA. You provide this option in the options field of DIVA's Source/Destination configuration panel.

• AXF and Checksums — You can enable end-to-end checksum comparisons on inter-site copies (copy operations from one site to another) by enabling AXF Genuine Checksums in DIVArchive. In the DIVArchive Configuration Utility, select the Source/Destination that you use for copies, and then select the AXF Genuine Checksum option. After this is performed, you can set the -axf option in the DIVAnet Site-To-Site mapping AdditionalOptions parameter. This allows checksum information to be embedded in the AXF wrapper on the source site, and checked again at the target site.

Do not be confused by the Site parameter in the DIVArchive Configuration Utility's Source/Destination panel. The sitename here is used only by DIVA, and does not correspond to a DIVAnet site (see the Oracle DIVArchive Installation and Configuration Guide for more information).

Caution:

Modifying the names of DIVArchive configuration parameters (such as Source/Destinations, Media Names, and Storage Plans) when connected to DIVAnet can cause errors.

Media (Storage Mediums) and Storage Plans

When DIVAnet copies objects from one DIVA system to another, take care when assigning the archive Media Name and Storage Plan Name of the copy on the target site. Use a good naming policy regarding media values on each DIVA system.

DIVAnet records the DIVA Media Names when it synchronizes each object instance. You can configure DIVAnet to automatically assign the Media/Storage Plan on a Copy operation. See Selected By DIVAnet (media of any) for more information. One of the ways to configure this feature is to archive to the target site with the same Storage Plan Name as the source object. For this to work, the proper storage plans need to be configured in the target DIVA. Alternatively, you can use DIVA Media Mappings to transform the Storage Plan Name into a media or another storage plan, all at the target DIVA site.

Drop Folder Monitor (DFM)

DFM monitors folders for new content, and then archive the new content into DIVArchive. By restoring to a particular drop folder, DFM can pick up the content and archive it to a different DIVA system.

DIVAnet can implement copy workflows without DFM, but in some cases, it is needed or desirable. To copy without DFM in the mix, the DIVAnet RestoreAndArchive Transfer Method can be used. However, there are some situations where it is appropriate to use DFM. Good candidates for using DFM might include autonomous sites that want to perform their own cleanup of unsuccessfully transferred content, or systems where third party WAN accelerators are used. To use DFM for transfers, use the DIVAnet RestoreAndMonitor Site-To-Site Transfer Method. See Site-to-Site Transfer Mappings (Workflow Profile) for more information.

Configuring Client Access

Configuring for Client Access involves configuring:

• The local DIVArchive for remote access (see Enabling Sites for Remote Access)

• The ClientAdapter service

• A DbSync service

• A DIVAnet database

Configuring all DIVAnet services enables the site for full DIVAnet workflow processing.

In the following figure, both the New York and Los Angeles sites are configured for full DIVAnet workflow processing. Applications in Los Angeles connect directly to the ClientAdapter in LA. By doing so, they can retrieve content from New York if needed. The local DIVAnet database provides a global view of assets across sites, even if connectivity is lost from one site to another. If sufficient permissions are granted, DIVAnetUI users in LA can copy content from New York to LA, and even delete content in New York.

Though it is technically possible to configure Customer App 2 to remotely connect to New York's ClientAdapter, this configuration often provides better availability, security, and auditing. Performance and scalability is often increased as well, especially with unreliable or slow WAN links.

DIVAnet ClientAdapter Service

Application clients that want to use the DIVA API, or want to use the DIVAnet GUI, connect to the DIVAnet ClientAdapter service. This DIVAnet service accepts web and socket connections from applications and processes the requests. A ClientAdapter is configured on each site that has applications that are local to the site where DIVArchive and DIVAnet are installed. The ClientAdapter communicates with local and remote sites through the ManagerAdapter service. ClientAdapters can also connect directly to DIVArchive Managers using Socket Mode.

You configure the ClientAdapter service using one (or two) configuration files (see Chapter 4 for more information).

DIVAnet DbSync Service

The DbSync service is responsible for synchronizing asset information from multiple DIVArchive sites, and storing the information in the DIVAnet database. DbSync communicates remotely with ManagerAdapter services on multiple sites to synchronize archived object information. DbSync is typically deployed along with the ClientAdapter. Both the DbSync service and ClientAdapter require direct access to the DIVAnet database.

You configure the DbSync service using a simple configuration file (see Chapter 4 for more information).

Display-Only Sites

You can configure a site as display-only, meaning that asset information from that site will be synchronized, but no requests (or any other messaging) will be sent to the site. Configure the site (for example, site diva4) in the DbSync configuration file, but not in the ClientAdapter configuration. Site diva4 will be effectively display-only. Asset information from this site will be queryable in the UI and in informational API calls, but requests sent to the site (using DIVAnet) will be rejected.

DIVAnet Database

Configuring DIVAnet local client access also involves setting up a DIVAnet database.

Object Cleanup

DIVAnet will sometimes satisfy a restore operation by temporarily copying an object from a remote site to the local site before restoring. This way, future restores of the content will be much faster. DIVAnet does not automatically delete the disk instance after the restore. Instead, it leaves the content in case others will want to restore it.

DIVArchive contains two tools that can automatically clean up content when a given disk/array becomes full:

• Oracle DIVArchive Storage Plan Manager (SPM) has a feature that can automatically clean up disk instances for an individual DIVA site.

• DIVArchive Local Delete can perform a similar function, but can optionally verify that an object also exists on other DIVA sites.

Because DIVArchive is configured to create a nearline disk instance by default, object cleanup also may need to occur on a DIVA site configured for DIVAnet remote access only.

DIVAnet Version Compatibility

DIVAnet 2.3.0 will interoperate with DIVArchive 7.3.1 or later. Some features incorporated into future releases of DIVArchive may not be accessible to DIVAnet without upgrading DIVAnet to a later release.

The DIVAnet 2.3.0 ClientAdapter and DbSync services will interoperate with a DIVAnet 2.3.0 ManagerAdapter only.

Configuring DIVAnet Policies

DIVAnet policies can be configured to enforce access control, automatically replicate assets, and delete assets over time. These policies stretch across sites, effecting how one site will access services or process information from other sites.

DIVAnet allows rules to be defined that restrict certain operations in the API as well as in DIVAnet UI. To configure access rules, see "Access Rules". To set up users for authentication in DIVAnet UI, see Adding Users in "DIVAnetAdmin Options".

DIVAnet supports the ability to automatically replicate new assets to other sites. To define rules to automatically replicate assets to multiple sites, see "AutoCopy". To defines policies governing how queued copy tasks will be scheduled and processed, see "Scheduling AutoCopy Tasks".

The Oracle DIVArchive Local Delete application can remove assets from a site that are no longer needed. This service is installed separately from the DIVAnet application, and has it's own configuration file. For more information, review the documentation for the Oracle DIVArchive Local Delete application.