2 Installation Planning

DIVAnet is a distributed application that is commonly configured at multiple DIVA sites. This chapter describes the concepts necessary to determine which DIVAnet services to install, and where. There are three major steps:

1. You must understand which sites must be connected to realize the desired workflows for a specific site. See Understanding Site Connectivity.

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

3. You must configure local client access on sites that have client applications that will connect to and use DIVAnet workflows locally. See Configuring Local Client Access.

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 is assigned a unique sitename. Each DIVAnet service belongs to a particular site, indicated by the LocalSitename parameter in the DIVAnet configuration files. You can configure Multiple DIVAnet sites each with or without local client access. DIVAnet sites can communicate with each other and replicate each other's information.

The most basic type of DIVAnet connectivity is the use of DIVAnet as a simple DIVArchive proxy for a single DIVArchive system. In this configuration DIVAnet Direct Mode is used. You can configure Access Rules to permit or reject operations on a DIVA API connection. This mode does not provide a federated 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 truly address multiple DIVA sites as one large archive system, DIVAnet sites must be connected together using DIVAnet services. The remaining sections of this chapter describe how to configure DIVAnet to achieve a federated view of archived content.

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. This rich interaction allows DIVAnet to operate as one large archive system.

Note:

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

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 (and those existing 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.

To realize this deployment, you will first configure a site for remote access. Dallas is perfect to demonstrate this scenario, as it does not have local clients to serve. You will then look at how to configure a site for client access, examining New York and Los Angeles, and how they interact.

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
Client Adapter	The DIVAnet ClientAdapter service accepts requests from the DIVA API and web clients, and interacts with DIVArchive sites and the DIVAnet database to satisfy those requests. Configured when implementing local client (application) access. This can also be used in a minimal proxy-only DIVAnet deployment (DIVAnet Direct Mode, described in Configuring Client API Ports). For more information, see DIVAnet ClientAdapter Service.
Manager Adapter	The ManagerAdapter service serves as a bridge between DIVAnet and the Oracle DIVArchive Manager. Provides remote access for a DIVA site. Configured for all DIVAnet sites, especially those that will have asset information synchronized. For more information, see DIVAnet ManagerAdapter Service.
DB Sync	The DbSync service is responsible for synchronizing asset information from multiple DIVArchive sites, and storing the information in the DIVAnet database. Configured when implementing local client (application) access. For more information, see DIVAnet DbSync Service.

Enabling Sites for Remote Access

Enabling a DIVArchive site for remote access by other DIVAnet systems involves setting up a ManagerAdapter service on the site and configuring 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 local 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 well 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

Much of the configuration necessary to realize DIVAnet workflows is performed at each DIVArchive site. This section details some concepts needed to understand how DIVAnet interacts with DIVA, 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 instance, 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 assets are archived using DIVAnet, DIVAnet 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. This in turn 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 instance 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.

DIVAnet has an important convention concerning Source/Destination names.

Note:

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. This common Source/Destination will be used by DIVAnet 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 intersite 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 content to be deleted 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 intersite 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, care must be taken in 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 Local Client Access

Configuring for local 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.

The ClientAdapter service is configured 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.

The DbSync service is configured 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. You 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 will also possibly need to occur on a DIVA site configured for DIVAnet remote access only.

DIVAnet Version Compatibility

DIVAnet 2.2 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.2 ClientAdapter and DbSync services will interoperate with a DIVAnet 2.1 ManagerAdapter. However, a 2.1 DIVAnet UI instance will not interoperate with DIVAnet 2.2.